Why simple is better

by Geoff Hart

Previously published as: Hart, G. 2010. Why simple is better. Intercom May 2010:30–31.

The concept of "working memory", also called short-term memory, is important because it's a limited resource: The human brain can only handle so much information simultaneously, and when there's no more room, something must be dropped to make room for new details. The information design goal of simplicity reminds us to seek ways to avoid overwhelming our audience's working memory.

A simple example

If you think of working memory as analogous to physical space on your desk, and long-term memory as analogous to your bookshelves, it's easy to understand how the two forms of memory cooperate. Let's say you've planning a vacation, and get out your reference books to start researching details:

An atlas that provides maps of the area.
A short history to help you appreciate the culture of your destination.
Your Lonely Planet guidebook.
Your Rough Guide guidebook, to fill gaps in Lonely Planet.
Your checkbook, because (alas!) you must consider your budget.
A travel writer's exposé that provides the dirt that most guidebooks miss.
Your laptop. Every destination has a Web site, and books are so 20th century.

You'd love to put more things on the desk, like a notepad for note-taking, but there isn't room. If you want more resources, you must remove something from the desk to make room for another book from the shelves.

It's not a coincidence that I listed seven items. George Miller's famous "magical number seven" is much abused, but it's a useful way to think about working memory. Don't get hung up on the number: the important point is that the more things you ask someone to deal with simultaneously, the less space remains in working memory. Each addition removes a space... until there are none left. At that point, old things must disappear to make room for new ones.

A technical communication example

How might this relate to technical communication? Consider the task of helping readers to follow a procedure. The items on their mental desktop probably include:

Their overall goal, of which the current procedure is only a small part.
The current procedure's goal, which constrains how they will perform the procedure.
The overall characteristics of the software interface they'll use. (This is "orientation" information: we must know where something is before we can act upon it.)
The number of the step they're about to perform, so they can return to that step, move down a line, and continue with the next step.
The names of any menu items or buttons you've told them to look for.
Their locations within the overall interface (e.g., which menus or toolbars).
Details of what to do with or to each menu item or button.

We're already up to seven items, and we haven't yet accounted for distractions (that fascinating conversation in the next cubicle, the ominous dentist appointment that afternoon), watching the software or hardware for feedback that something good or bad is happening, wondering whether we're about to make an irreversible error, and many other possibilities. No wonder so many people ignore our documentation and go straight to the local expert.

Implications

Clearly, people learn to cope with this complexity, otherwise nobody would ever get anything done. Coping strategies abound, such as learning the hardware (keyboard and mouse) and software (menus and toolbars) so well that they become subconscious parts of how we work, and no longer need to be numbered among the seven items we can juggle simultaneously. Again, the important point is not the number seven, nor is it the things we can't control (such as distractions): it's the fact that even seemingly simple situations are far more complex than they appear at first glance.

Understanding that this complexity exists gives us tools to solve it, starting with creating lists such as the two I've presented in this article. By understanding the size of the list that must be held in working memory, we can seek ways to minimize the burden. For example:

Use the same mental model: To facilitate locating part of an interface, provide a screenshot with that part highlighted. This lets readers move a visual image of what they're seeking into working memory; when they turn to the software, they don't have to translate a verbal description into a visual target, thereby freeing up the memory space that would hold that translation. The more visual the thing they're seeking, the more important it is to provide a visual image. For example, icons should always be presented as graphics, not described.

Juxtapose related things: When readers must look back and forth between software and documentation, working memory is consumed by the positions of the current step in the documentation and the location of the interface parts used to accomplish that step. (This is why you'll often see people hold a finger on the page while trying to operate the software with their free hand.) Making it easier to glance back and forth would free up some working memory. For example, adding affordances in the interface, such as clear button names or tooltips, reduces the number of times readers must return to the documentation for basic information on how to use the interface. Providing documentation as context-sensitive online help eliminates the need to navigate through the help just to find the correct topic; moving the help window beside the software makes it even easier to consult the documentation without becoming disoriented. If we use embedded help, for example by organizing the interface from left to right and top to bottom in the same order as the procedure's steps, we further reduce the need to consult the documentation (here, to learn the sequence).

Reorganize the interface: Understanding how people progress through the steps in a procedure gives us knowledge a product's designers often lack. Programmers and engineers most often focus on details of implementing features, not on integrating them within a workflow. Moreover, most either never use the products they produce or never ask anyone outside the design team to use the products, so they don't understand why an interface is unusable. By providing them with that knowledge, we help them stitch the feature list together into something that supports the product's users. This may involve simple things, such as eliminating irrelevant or rarely used options from a dialog box (place them behind an Options button instead) or grouping related tasks into a single tab of a dialog box. It can also involve more complex things, such as reconsidering the overall workflow.

Simplify!

This article can be boiled down into a single rule: Before you begin writing or designing, think about how your audience will use what you create. In the context of working memory, this means we should count the number of things users must keep in their head while they work, then look for ways to minimize that number. We won't always have the luxury of redesigning a product to reduce the burden on its users, but we can at least lighten that burden. For example, instead of using a single step to tell readers to find a menu, open it, select an option, select a tab in a dialog box, navigate to a heading in that tab, then select three options, we can break this into at least two separate steps: first, opening the dialog box and selecting the correct tab; second, finding the relevant options and setting them. For any option that requires elaboration (when there are multiple alternatives that must be explained), treat that as an additional step.