Jakob Nielsen‘s Alertbox, April 26, 2011
http://www.useit.com/alertbox/workflow.html
When we designed our 2-day seminar on application design, we partitioned the topic into 2 parts: workflow and screen components.
The second topic is easy to understand: it covers everything from individual controls, such asradio buttons and checkboxes, to more complex composites of widgets, such as forms design, to the layout of these controls. All very tangible.
Workflow is much more abstract, but actually more important for the application’s ultimate success. We’re no longer talking about visible stuff on the screen, but rather about user movements among various features. Workflow theory ranges from simple concepts, such asprogressive disclosure, to thorny ideas, such as inductive vs. deductive interfaces.
To illustrate the importance of workflow design, I’ll offer several concrete examples from recent user testing in varied domains. As the examples illustrate, effective workflow design builds on a simple principle: Have things happen when users expect them — either because of theirexisting expectations or because you’ve clearly communicated what to expect. (The former is obviously better; instructions automatically degrade the user experience by diverting users’ attention from their main task.)
Premature Requests: Asking Users Before They’re Ready
Lately, I’ve been sitting through many usability tests of iPad apps. After installing a new app, the first thing users typically see is a message in a dialog box: [This App] would like to send you push notifications. This message followed by two buttons: Don’t Allow and OK.
Uniformly, users press Don’t Allow.
People get enough junk already. After years of Web usage, people are extraordinarily weary of companies spamming them with “selected offers.”
In addition to engendering dramatically stronger customer loyalty by reminding them to use the iPad app, push notifications often provide helpful information that users might appreciate. So why would they refuse good stuff that could enhance the value of having a tablet?
Because the opt-in prompt appeared at the wrong stage of the workflow: it was grosslypremature.
The prompt appears when users open the newly installed app — which is, by definition, beforethey’ve actually experienced the application and understood its value. At this early stage, users have a very low level of commitment to the app. You can’t ask them for much, because they don’t think much of you yet.
Our user research with mobile apps has shown that they’re often intermittent-use applications. People download many more apps than they actually use with any frequency. And users know this; they’re not going to let an app impose an eternal burden on them when an a prioriassessment shows that it’ll likely be one of the many apps that they don’t really use.
(Yes, it’s possible to turn off push notifications later, but most users either don’t know how to change system settings or don’t want to bother.)
So, a much more fruitful approach is to first build up some credibility capital with users by offering a useful service. Once users have grown to really like you and know they’d actually benefit from updates, you can ask them to opt-in for push notifications.
Another example along these same lines: For many years, it’s been a key guideline for e-commerce checkout to let customers make purchases as “guests” rather than requiring them to become registered users of the site. When making an initial purchase, people aren’t yet sufficiently committed to a company to accept the hassle of registering. (Later, after a few purchases, they’ll probably register if appropriately prompted to do so.)
Final example: in our testing of B2B sites, business professionals usually rebel when a site attempts to collect lead information too early in the sales process — before the (prospective) customer has decided to admit the vendor to the shortlist. Premature request = no leads at all, as users proceed to more welcoming sites.
Questions That Only Make Sense Later
In testing social media features, we frequently see sites asking new users for personal information without explaining how it will be used. For example, people are asked to create a screen name when they register. Some users don’t realize that this name will be shown next to all of their future postings. Even worse, many sites make it impossible to edit screen names at a later date, when the user’s approach to the site has changed.
Knowing that the name would be widely displayed and not just used as a login credential would prevent people from being stuck with unfortunate names like SuperStud on a professional site.
There’s a fairly easy fix here: simply explain to users how each piece of information will be used. You might, for example, show them a sample of how their profile and postings will look, and let users edit their entries before committing to register. (Of course, any such instructional text should be concise and thoroughly tested, as we know users allocate minimal attention to instructions.)
Many Web-based applications are ephemeral applications, meaning that users view them as low-commitment transient encounters: a quick in/quick out of something they’ve never seen before and might never see again.
In this environment, we frequently observe usability problems caused by users’ weak mental models of the application workflow. People don’t know what’s coming later, and they often don’t even understand the application’s purpose. It’s thus hard for them to correctly answer early questions and they have little motivation to slog through set-up features.
One obvious answer to these problems is to reduce the set-up burden and enhance the usability of the early-use phase. Think of a gently sloping on-ramp rather than a wall that users have to climb.
Even the best designs can’t create perfect usability where everybody understands everything without any effort whatsoever. The goal is to set the stage for users to understand the workflow, without slowing them down. Clearly, this is one of the toughest challenges in online communications.
Better Workflow = More Use
As the examples here illustrate, the user experience is strongly impacted not just by what’s on the screen at any given time, but also by how the current screen relates to future states. It’s also impacted by how the current screen relates to past screens; here, the general guideline is to reduce the need for users to rely on their fallible memories.
Thus, one reason to care about workflow is simply that usability is enhanced when you consider the totality of the user experience and not just stand-alone screens.
But there’s also a more business-oriented argument for improving workflow usability: users can often overcome isolated usability problems, but a broken workflow is much harder for them to fix. Among the typical consequences of bad workflow design are
- undiscovered errors that occur when users don’t relate what happened on screen A with a (much-later) screen B;
- abandonment, where users simply give up on something they don’t understand; and
- frustration, which arises when an awkward process takes much more time than it should. (Individual design elements can also delay users, but a poor workflow takes considerably longer to complete.)
The bottom-line outcome of all three? People stop using your application. Conversely, if the process flows smoothly and users feel in control through all the steps, they’re much more likely to come back.