Our Approach In Designing Apps for Mobile

12 September 2012 by Coleman McCormick

In our few years of high-tempo, agile software development, we’ve built up a wide library of “lessons learned”, particularly in the arena of mapping and mobile apps. So last week in Washington, DC, I attended the Geo DC meetup to present some of our findings on how we approach software design. The talk seemed to be well-received, and I thought the topic was worthy of some space on the blog to flesh it out further in writing.

Designing apps for mobile at GeoDC

As a business with a partial focus in the domain of geospatial field data collection, the process of designing effective solutions to the mobile worker’s “pain and suffering” is one close to our hearts. The genesis of Fulcrum lies in scratching our own itch for our own project work. Through years of trial and error (and boy is that “error” important to the process), I’ve boiled the major hurdles in building mobile apps into three core challenges:

  1. You can’t have everything in a mobile app. - While you can, with elegant design, compose a solution to dozens of needs at once, there’s a slippery slope between a simple, powerful set of features, and the toolbar-laden clickfest of bloatware like Photoshop or Microsoft Office. These, naturally, are extremely powerful apps, but often at the expense of end-user sanity.

  2. Your design space is severely constrained. - Fitting a host of awesome stuff into a 3–4“ screen (or 10” if you’re lucky on tablets) is a major challenge, and one that takes a lot of planning, tweaking, and customization to plane your way down to a slick presentation easy for regular people to grasp.

  3. It’s tempting to build in cool stuff that requires internet access, but devices are frequently disconnected. - Even in urban areas, connectivity can be spotty, sometimes intermittently slipping in and out of cellular data coverage. Though powerful features might rely on server-side resources, it can be incredibly annoying to have your app lose major functionality when offline.

In Fulcrum we’ve tried to approach the development process keeping these challenges in the front of our minds. These reminders keep the software from sliding into a place where we lose the power of a solid solution to the set of universal pain points for fieldwork, particularly as it applies to mapping.

So to keep ourselves in line with these strict development guidelines, our team hews to a set of “tenets” as we work through the development cycle with Fulcrum.

The Core Focus

Always focus on the mobile experience first.

As a platform solution, with native mobile apps and a web-based application, we have several moving parts to juggle, but the core value of Fulcrum lies in its power as a mobile solution. Most Fulcrum users will spend the majority of their time with the app in the field, so the true payoff for end-users exists in time, effort, and heartburn saved with more efficient field work processes.

What does that end-user actually need in his or her hand in the field?

With each new feature idea or bit of functionality we discuss as a design team, we’re constantly asking this question of ourselves. Ultimately, “less is more” in so many ways when doing work out on the go, on the edge of the network. We don’t want to clutter the user’s life with 35 buttons and functions they might use one day, but end up having to navigate around most of the time.

We will reduce the end-user’s learning space.

Field data is often collected by users that are not database administrators, software developers, or GIS analysts. Presenting the user with database schemas, technical jargon, or dozens of screens is rarely helpful. If we can lower the bar for learning the app (without boiling it down too far), users will spend less time and money training, get higher-quality data, and have happier users.

Stick to the conventions.

The Android and iOS mobile platforms have had a few years to mature at this point, and therefore have evolved sets of design patterns and conventions. Sticking to these as much as possible is beneficial; we can piggyback on user exposure to basic app usage in navigating things like the built in email apps, music, maps, etc.

How has our focus manifest itself in features?

We do tons of our own field testing, in addition to using Fulcrum on our mapping projects. The screenshot below shows data I collected in downtown St. Petersburg, out on the street with both the Android and iOS apps, trying to see what works well or doesn’t, and to look for cracks in the experience to patch up during the dev cycle. This sort of rigorous testing helps us to harden it as much as possible to end-user demands.

St Pete mobile data

Focusing on mobile, we knew we needed the core functionality to work completely offline (with access to GPS signal at a minimum). So Fulcrum uses a two-way syncing feature, allowing for collection with no cellular signal. To complement this, we made it possible to upload your own basemaps to use as background reference, even offline. Tons of careful planning, diagramming, and wireframing come before all changes to the mobile app interfaces. Without thinking through the action flow for each screen (how does the user get to this action, how do they get back, etc), the usage patterns can become cluttered and sometimes create duplicate functionality or end up hiding features in places that are confusing.

The continuous thread through all of our engineering efforts, though, is that there’s no replacement for putting yourself (as a designer or engineer) in the shoes of your customer to experience first-hand their pain points when doing their work. This sort of hands-on approach can enlighten you on what you need to do to improve, but also what you don’t need to do to make the end-user experience better.

Coleman McCormick

About the author

Coleman is a geographer and VP at Spatial Networks, working with users to bring Fulcrum’s field data capability into their organizations.