Skip to content

NEW RESEARCH COURSES: Qualitative Methods, Heatmaps | Learn More

Disruptive Workflow Design

Jakob Nielsen

March 11, 2012

Summary: Smooth-flow task performance makes application use pleasurable. But disruptions are all too common due to crinkly design or creaking implementation.

Workflow is one of the most important elements of application design. Can users proceed through their tasks with ease or are they subjected to irritating detours and burdensome extra steps?

A workflow's usability can be lowered in many ways, such as when you require users to remember anything from one step to the next. (Lower the burden on short-term memory — there's a useful guideline to remember :-)

Here, I want to focus on a common problem: users being disrupted from proceeding with their natural task flow. This can happen in two ways: a poor user interface design can deliberately sidetrack users, or a system problem can divert users' attention to fixing the system instead of doing their work.

To see the difference between bad user interface design and a bad system, let's consider two examples of user-unfriendly account updating.

Bad Workflow: Apple iTunes Application

Apple's iTunes application for Windows is riddled with lousy user interface design, but my current example relates to updating the user agreement. Users, of course, don't care about "agreements" so it's always an intrusion when a site or app must ask them to "accept" the changes. (I put "agreement" and "accept" in scare quotes because users don't really agree to or accept these unreadable piles of legalese.)

Because virtually no user voluntarily seeks out the user agreement, it's displayed as a disrupting interstitial. Interstitials are almost always bad for usability, but I can understand why the lawyers might force user interface designers to impose this nasty design on customers. Of course, the agreement's design can be carried out with reasonable or miserable workflow consequences — and Apple chose user misery.

To take a typical case, suppose a user wants to update the installed apps on her iPhone. The workflow is as follows:

  1. Select "Apps" in menu of data types.
  2. Click "Check for Updates" in the very opposite corner of the screen (an example of poor design, because of Fitts's Law, but I'm frying bigger fish here).
  3. See the list of apps that has changed. A chore.
  4. Click "Download All Free Updates." (In a third corner of the screen, just to make sure we get our daily exercise moving the mouse around.)
  5. GET INTERRRUPTED by the user agreement interstitial.
  6. "Agree."
  7. Read a nicely worded — but stupid — message to "please attempt your purchase again."
  8. Start over from step #1. Arrgh.

Of course, any beginning designer knows that step #7 ought to be a return to the disrupted workflow. Computers are actually pretty good at this memory thing, so the system easily could have remembered what the user wanted to do before the interstitial. In other words, step #7 should have been to commence the download that was requested in step #4.

Yes, it's a bit of extra coding to make the computer remember additional information. But you'd think that the stock market's highest-capitalized company might have an extra programmer sitting around who could make this bit of improved user experience happen.

Terrible Workflow: Switching to New Mail-Order Pharmacy

My second example comes from my health insurance company's switch to a new mail-order pharmacy website. The company sent out all kinds of messages (physical and electronic) to warn users about the upcoming switch, and it even promised that patients' current prescriptions would automatically be transferred from the old pharmacy to the new one. So far, so good, even though users hate change and it would have been even better to have avoided the changeover in the first place.

Problem: When I went to log in at the new site, it didn't recognize me.

What could be more fundamental than the ability to get in? Failing on this step means that everything else is irrelevant.

A week or two later, the company finally got its act together and its customers were able to access the new site. Since then, it's worked okay at the expected level of mediocrity.

Bugs vs. Bad Design

Why am I more upset about iTunes than the pharmacy website, given that the latter was much worse, and completely destroyed the workflow instead of purely aggravating it?

Because the pharmacy website suffered under a one-time software bug, whereas iTunes suffers under a sustained case of bad interaction design.

Bugs can happen to anybody. They certainly happen to me from time to time. Big, complex mission-critical software is particularly susceptible to coding errors, and it's definitely prudent to allocate plenty of time in the schedule for debugging before imposing the software on customers. As long as the bugs are fixed, I don't view them as egregious.

Of course, to users, anything that prevents the site from working is bad. Whether people use the wrong feature or a proper feature that happens not to work doesn't matter. Result = failure in either case.

This is a good time to remember the distinction between user interface and user experience. We design the user interface: screens, error messages, forms, commands, etc. But users experience the system as a whole, comprised of both the design and the implementation (as well as many other components, such as network delays, which can ruin response times and degrade user experience as much as bad design can).

By definition, usability is a quality attribute of the total user experience. As such, it's determined by both design and implementation — and even by system administration-style issues such as the choice of hosting provider.

Any bug is therefore worth criticizing, and debugging is a wise investment in higher quality. Robust code is typically better for usability than chasing the latest flashy features with their associated risk of failing.

Ultimately, bad user experience that results from bad user interface design still annoys me more than bugs. In the case of iTunes, somebody sat down and wrote that page that directs users to try again after the system interrupted them. Thus, it's known that the workflow design imposes an extra burden on users. That this poor design has been in the software for years makes it truly worth criticizing.

Learn More:

AltStyle によって変換されたページ (->オリジナル) /