UI Tip: The User Is Busy

I’m passionate about user-interfaces. And so I thought it would be worthwhile to expand on a UI discussion I was in on Slack today.

You should never call a user dumb. I prefer to use the phrase busy, one of the great suggestions from Al Cooper’s About Face. I prefer that phrase because nearly all users are not dumb: The bell curve and a whole heap of population statistics say otherwise.

The real issue is that most users are just too busy and too harried to really think about your software or to spend any time with it or to spend any time learning it. They only use it because they have to use it, most likely because some manager at their company bought it and said, “This is your new [X] now.”

Anything in your software that forces your users to slow down and think about it just makes them angry because they have so many other things to do. Your software isn’t their job; it’s in the way of their job. They won’t look closely; they won’t read closely; they won’t be paying full attention; and they don’t have enough energy to really care about your software beyond what they absolutely need from it.

So you should design not for somebody who’s dumb, but for somebody who’s smart — and very distracted. And that means you should be following rules like these:

  • Organize the layout very carefully; group and separate everything so that the user only needs to focus on the one or two areas of the screen he wants to care about. And remember that he reads top-to-bottom, left-to-right:  If something logically comes before something else, put it above or left of the thing that logically follows it.  Don’t make her eyeballs zigzag up-and-down the screen trying to follow the order of your content.
  • Don’t make your user search for what he most-frequently needs out of your software. Writing a music player? The “play” and “pause” buttons had better be front-and-center at all times. Writing a time-tracking program? You’d better be displaying the correct page with the hour-entry fields the moment the user is logged in.
  • Don’t promote. (This is an incredibly hard one for Product and Sales people!) The user knows what he wants to use your software for; that blinking advertisement for your shiny new feature just annoys her. The only button on it that she wants to click is the one that makes it go away so she can get her job done.
  • Don’t display error messages. Seriously, just don’t. The user doesn’t care. Find a way to either automatically fix the issue, or better yet, design the UI so that the user can’t make the problem happen in the first place. “Please do not put hyphens or dashes in your credit card number” is a message no user should ever see. The only error message you’re ever allowed to display to a user had better start with the phrase, “We apologize that [something we did] has failed.”
  • Explanations and “help” are useful, but write them for people who already know the software, and write them so they can be skimmed. They’ll only be used when a user doesn’t remember how the pieces of the system fit together. Don’t bother targeting them to beginners, because a beginner won’t know the context for them anyway.
  • Nearly everybody who will ever use your software is an intermediate user. Beginners will put in the effort to learn the basic concepts, using whatever training facilities are available to them, and either quickly become intermediate users or give up. Power users are vocal but actually very rare. Everybody else spends their time at middle of the big bell curve: They sort-of know what your software does and sort-of remember how it works, but they don’t always remember exactly how to get from point A to point B in it. You don’t have to spell out the path for them in detail, but there should always at least be enough road signs that they can figure it out.
  • A blank screen is the biggest enemy of a busy user. She doesn’t want to fill in all the data. She wants a basis, something she can start with, and that she can alter to meet her needs.
  • No matter how required you think a piece of data is, users will disagree. Your business people may insist that every user choose between “Mr.” and “Mrs.” and “Ms.” and “Dr.”, but the user doesn’t even want to bother filling in his name, much less his job title and the name of his college. Don’t ever mark anything as a required field unless a part of your office building will literally catch on fire if it isn’t provided.
  • It’s better to offer more information on a screen rather than less, as long as it’s organized well. If you’re busy, there’s nothing worse than having to go somewhere else (a popup, a dialog, another screen) to get information that’s just one level deeper that what was presented to you.
  • By the same measure, try to put as much functionality on the screen as is reasonable. Don’t make a user click to access the options and tools he needs; put them upfront where they belong. (Good example of a terrible UI: Having to click to “put it in edit mode,” and then click again to “save and turn it back.” If they have rights to edit the data at all, just let them edit it — don’t make them ask the UI for permission every time they want to make a change.)
  • Remember Fitts’ Law: Putting related UI components farther apart slows people down, because it takes time to get between them. But if you have to put them far apart, make them bigger so they’re easier to target with a mouse. And, also: If his hand is on the mouse, find ways to keep it there; if his hand is on the keyboard, find ways to keep it there. Don’t make him waste time switching back and forth between input devices.
  • Keep your colors bland and non-distracting. That’s pastels, greys, black, white, off-whites, browns, dull blues. She’s not using your software because of how pretty it is; she’s using it because she’s trying to get a job done. But if there’s something truly critical that absolutely demands her attention, use colors and shading to make it stand out. Just remember that every time you do this, she’ll get extremely annoyed if it’s not critical to her.
  • Only use icons when they’re obvious. The user doesn’t have time to guess (or read) what your weird half-moon-with-a-frog-on-a-tractor symbol is supposed to mean. And keep your icons simple: Your graphic designers may love how much detail and texture they crammed into that checkmark icon, but the fancier it is, the more distracting it is.

This also goes a long way to explain why Clippy was so reviled: When you’re busy and trying to get things done, the last thing you need is a childish cartoon character popping up in your face every two minutes. No matter how helpful Clippy was intended to be, for the busy people who use Word and Excel every day, it was in exactly the same category as Homer’s Everything’s Okay Alarm.