Equipping Writers for Success
The Writing Life
The Writing Life
This free script provided by
by Geoff Hart
Return to Business & Technical Writing · Print/Mobile-Friendly Version
Isn't that something every technical communicator should keep in mind when we try to put ourselves into the heads of the stupid, illogical, frustrating users of our documentation? Perhaps we wouldn't use any of those three adjectives if we heeded that advice.
But Miller is best-known to technical writers for his "magical number 7, plus or minus two." In a famous (some might say infamous) 1956 paper, Miller summarized the results of his research and that of other psychologists on "working" (short-term) memory as follows: the average person can simultaneously hold around seven items (chunks of information) in working memory.
The "plus or minus two" part refers to the fact that some people can hold onto fewer items whereas others can hold more. With a good night's sleep, fewer distractions, or familiar information, the number increases; with fatigue, distractions, and unfamiliar information, the number decreases.
Think of working memory as the space available to hold chunks of raw data while we try to manipulate that data and turn it into information - that which informs us. If the information is sufficiently important, we can transfer it into long-term ("permanent") memory by fitting the new information into the structure of existing memories.
For something truly new, we must create that memory structure first, a considerably more difficult task. Of course, we can also choose not to remember specific data, but instead to write it down. Think of how we might take notes on a lecture: as we listen, we assemble the individual words and phrases into discrete chunks of meaning, after which we record those chunks as notes. If the speaker moves too fast, we lose information. (In technical terms, they have exceeded our channel capacity.)
All communication experts (and most editors) recommend that we make our writing as simple as possible. Miller provided a sound scientific basis for determining how simple: as soon as we start pushing beyond "seven plus or minus two" chunks, our audience has increasing difficulty assembling those chunks.
The Mythical 7
Unfortunately, few people have actually read Miller's article. As a result, many myths have arisen from partial and incorrect understanding of second-hand accounts of what Miller tried to say. I've heard many otherwise intelligent people claim that sentences should be no longer than seven words, that procedures should have no more than seven steps, or that chapters should have no more than seven sections - even that menus (software or otherwise) should contain no more than seven choices.
I call these myths because they're incorrect and misleading - yet like all myths, each has a grain of truth. Effective sentences can certainly exceed seven words in length; if not, English would be a stultifying language. Procedures can certainly exceed seven steps, otherwise we could never build rockets or Web pages. If chapters were limited to seven topics, we could never write about any complex topic, and if menus could only contain seven choices, we'd need many more restaurants to offer all the foods we love.
So: Where is the truth in the myths, and how can we use that truth to communicate more effectively?
The Magical 7
Let's consider each of the examples in the previous section. Sentences longer than seven words work best if we understand that each clause or interruption counts towards the seven chunks of information our readers must hold in working memory. Some chunks are "free." For example, advance organizers such as the "for example" at the start of this sentence evoke a mental context (the following is an example) that readers don't have to remember once it's been invoked; thus, they don't count towards the total of seven.
In contrast, the parenthetical example in the previous sentence interrupts the flow and forces readers to hold all preceding chunks in working memory, figure out how the example relates to what was said, then continue onwards. A less-intrusive and less memory-intensive way to say the same thing might be the following: "...evoke a mental context that readers don't have to remember once it's evoked. That context is the following is an example."
Other types of clauses each count towards the limit of seven chunks before we even begin to think about subjects, objects, and their relationships:
Of course, each of these approaches can be used effectively, but the more such gimmicks we include in a sentence, the fewer memory slots remain open. At some point, our poor reader must resort to writing notes that summarize what they've already read before they can complete the sentence. We can also use more chunks in print than in speech, since readers can always reread a difficult sentence, but lack this luxury in speech.
Similarly, procedures can be long and complex if each individual step in the procedure is simple. Because readers need only hold one step at a time in working memory, our information design goal is to ensure that each step is no more complex than necessary. This is the source of the common recommendation that each step in a procedure should be limited to a single task.
Similarly, chapters and procedures can be can be as long as we like - if we break them into logical sections at points where readers might logically pause to catch their breath and assemble meaning.
Once readers understand a procedural step and act upon it, they can immediately free up their working memory to begin assembling the next step. Once a reader understands where a section fits within the larger chapter, they can ignore the rest of the chapter and use working memory to concentrate on that specific section.
Restaurant menus provide a more savory illustration of how this process works and an example of how to apply this thought process in information design. For most restaurant meals, we have an opportunity to choose only a few things at a time. For example, we often order drinks and appetizers before choosing a main course, and don't have to worry about dessert until we've finished eating. That lets us focus on the task of choosing among categories of main courses while the waiter fetches our drinks and finger foods.
Menus are organized into categories rather than presented in alphabetical order so we can compare the categories and choose which one to focus on. For example, we may consider the categories of seafood, beef, chicken, pork, vegetarian, pasta, and "breakfast" dishes (seven categories) before deciding that we really want pasta. Having decided on pasta, we can ignore the other six categories and focus on the possibilities in that one category.
Few menus offer more than about seven choices in a given category, so it's easy to hold those few options in working memory while we compare them. But if there were many more than seven choices, an effective menu design would help narrow our focus by grouping the options into subcategories, such as types of pasta (e.g., thin vs. thick noodles) or types of protein (beef vs. seafood). We could, of course, apply the same design logic to the less-appetizing software menus we confront in our daily work. Those menus might not become any tastier, but they'd be easier to work with.
Magical, not Mythical
The message I want you to take away from this article is that "the magic number seven" represents a useful tool for understanding how people think - not that it's a fixed, immutable limit. Our goal as information designers should be to understand that our designs place a burden on the reader's working memory, and that we should strive to reduce that burden. We can do this by analyzing the sources of complexity and choosing strategies (such as grouping the contents of large menus into categories) that minimize the complexity our audience must face.
Miller, G.A. 1956. "The magical number seven, plus or minus two: Some limits on our capacity for processing information." The Psychological Review 63:81–97.
Previously published as: Hart, G. 2006. The mythical, magical number 7. Intercom April 2006:38–39.
This article is not available for reprint without the author's written permission.
Geoff Hart has been working a technical communicator (primarily as an editor, but also as a translator and technical writer) since 1987. He has written hundreds of articles aimed at technical writers, many of which can be found on his website: http://www.geoff-hart.com/.