As part of Salesforce’s “Summer of Mobile” webinar series, I presented a session on user experience design for mobile. This post is adapted from that webinar.

Mobile device use is exploding, but people can only make time for about 5 new apps every month. So as a business that wants to jump on this trend, how do you build a great product that sticks with users?

In our work at Appiphony, we use a four step process:

1. Get Out of the Building
2. Define Success by Writing the Script
3. Build the First Prototype
4. Iterate Until It’s Great

This post describes the use of this process on a real project we executed for a particular Salesforce ISV.

Project Overview

Our client provides physician staffing services to emergency departments across the United States, and wanted to dramatically increase the quality and quantity of feedback they received on physician performance. (Their baseline was a paper form in the mail with a single-digit response rate.) They had a vision to deploy iPads to the emergency departments (EDs) and get feedback in real-time.

Get Out of the Building: Customer Research

As soon as you reach an initial consensus on the product concept, perform a site visit to a location where the app will be used. You need to build an understanding of a setting to gauge how the app will fit within that setting. And based on the questions they will later ask, the rest of your team wants to understand this fit, too!

We visited two separate hospitals and observed the flow of patients in the ED. Seeing the physical location helped us understand how the patients would be able to give the desired feedback. (More on that later.)

If you want to get out of the building but don’t quite know how, check out the book Rapid Contextual Design. It’s a detailed playbook for site visits that also provides process options for small, medium and large budgets.

Define Success by “Writing the Script”

Once you have a handle on the setting, write a plausible story starring your customer succeeding at something with your app. Ideally, this story will take place in the setting you studied. (It will be much more realistic that way.)

In contrast, don’t ship features that don’t connect in a coherent way for the user. “Stick to the script” and leave out what doesn’t fit. And if you’re worried about leaving things out, don’t forget you’ve got 80% less screen real estate on mobile.

Our script is shown below in the form of a storyboard. It turns out patients have down time in the treatment room after they’ve been helped but before their prescription is ready and they can leave. And here’s the key detail that drove this home for our team: there are TVs in the treatment room to kill this extra time. We never would have learned this without the initial site visit. With that, the dev team truly “got” the concept and was 100% on board.

Start by writing your own story in words, and if you’re unsure how, About Face by Alan Cooper will lead you through the process. I recommend you make the story visual with a storyboard or comic, and for that you should read See What I Mean by Kevin Cheng.

Build the First Prototype

Now that you have a vision of success, it’s time to build your first prototype. Do this as quickly as possible, since you will change the UI, probably in a significant way. If you’re developing on the Salesforce platform, you can use the Mobile Packs to deliver something clickable quickly.

Prototyping is absolutely critical on mobile; one poor interaction detail can kill your whole experience. In our case, we ran a quick-and-dirty usability test with an elderly relative and saw him get stuck with part of the interface that required scrolling. We took it out and reworked the core navigation mechanism.

If you’ve got a sense for what the app needs to do, but aren’t sure how to lay out the screens, consult a pattern library reference such as Designing Mobile Interfaces. A resource like this lets you flip through well-documented solutions to many common design problems.

Iterate Until It’s Great

The last step is really a beginning of sorts: once you have something clickable that can stand on its own two feet, you can begin iterating with representative or actual users. And yes, you will need to iterate. It’s like preparing for the SATs:

• You don’t want to “walk in cold.” (Some kind of practice is critical.)
• Feedback will improve performance, but only if it’s specific. (Should I work on my essay writing or reading comprehension?)
• Many external resources are available to drive improvements; the key is realizing “better” is possible and planning for it.

Allow for room in your project schedule to polish the interactions and flow from screen to screen. This is critical, so I’ll repeat it: make time up front to revisit the same functionality across multiple sprints to account for the tweaks you’ll need to make. On our project, we made nine (!) prototypes of the key flow before we reached the shipping version.

The New York Times bestseller The Lean Startup has popularized iteration, so many people will be familiar with this. Take a look at a related book called Lean UX to learn more about how to rework your team’s processes to account for iterative cycles.

If you’re curious about how exactly to apply polish to a user interface feature, a book called Microinteractions describes a framework for approaching this and shows many successful examples.