|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2007 --> Mental models: laying foundations to support readers
Vous êtes ici : Essais --> 2007 --> Mental models: laying foundations to support readers
by Geoffrey Hart, Fellow
Previously published as: Hart, G. 2007. Mental models: laying foundations to support readers. Intercom July/August 2007:50–51.
During a recent trip to India, I found myself contemplating the shower arrangements. I knew that many Indian hotels offer hot water only at certain times of day, and that I'd have to ask when hot water would be available or face the prospect of a chilling shower. This particular hotel told me hot water was available 24/7, so I was dismayed when 5 minutes with the hot tap fully open produced no trace of warmth. This obstacle didn't stop me (I really needed a shower!), and inspecting the washroom revealed a small green tank high on the wall, something I'd previously seen and ignored: it simply wasn't part of my mental model of a bathroom. Closer inspection revealed a red indicator light labeled Heating. "Aha! Clearly, I must flip a switch somewhere to heat the water." Yet flipping all switches in the bathroom produced no results: the red light remained adamantly off. Eventually, perseverance revealed the unlabeled switch that controlled the heater, and that it took a couple minutes for the light to turn on: apparently, Heating actually meant Heated. The secret now revealed, I enjoyed my hot shower.
This anecdote reveals much about how we humans approach new situations. Unless we have a compelling reason to do otherwise, we start from a pre-existing mental model—here, my North American model that hot water is available simply by turning the tap. When that model fails, we try another mental model—in this case, one I'd learned in the U.K., where on-demand water heaters are common. When that model also fails, we try to build a new model that conforms with reality. Such models, referred to as schemata (singular: schema), are a powerful tool for understanding how people approach situations—and how we can help them to do so. Let's see how this might work in practice.
Consider a Web page that presents a single topic. Readers who reach the page examine it following a certain schema: they expect a title that will clearly identify the page's contents, and if it's still not clear whether they've found the right topic, they expect that additional clues will be present to help them decide. These clues include an introductory paragraph that expands on the title, and subheadings or graphics revealed by skimming the page. If the topic still doesn't seem right, they look for different clues on where to go next. Understanding that schema lets us design a page that supports their use of the page.
To confirm that readers have reached the correct page, we start with a clear title that distinguishes the topic from other, related topics. Where appropriate, we then provide a concise introduction that supplements the limited amount of text a title can contain. We also highlight part of the navigation bar to show which part of the larger site the reader has found. Headings that stand out from their background let readers skim the page to find the most relevant parts of the topic, and provide an overview of its structure. Their pre-existing schema for a Web page defines what these elements look like, where to seek them, and what information they will provide.
Readers also expect to learn where to go next if they've found the wrong topic, or have read the topic and want to learn more. Their schema for a topic thus includes the existence of cross-references, which suggest other relevant bits of information they might have been seeking when they mistakenly arrived at the current topic or other places to go to learn more details. In online information, we can provide what are commonly referred to as breadcrumbs (after the tale of Hansel and Gretel marking their path through the woods using a trail of breadcrumbs). For example (with each item except the last one a clickable link):
Table of contents --> Typography --> Fonts --> Selecting a font
Note two important aspects of this approach: First, the text is underlined to indicate that it is a hyperlink, which builds on a schema familiar to anyone who uses a Web browser. Second, the sequence expands as the reader navigates progressively deeper into the information, growing from left to right. This is emphasized by the arrows, which show the direction of the relationship between the links and convey the sense of a hierarchical connection that is absent from (for example) the navigation bar at the top of the page. This tells readers where the current topic fits within the overall hierarchy of information and where they can go if they want to be elsewhere: if they don't want to learn about choosing fonts, they can click the Fonts link to display other font-related topics. Other familiar forms of cross-reference include the see, see also, and compare used in glossaries and indexes.
An additional feature of some Web pages are Previous and Next links that build on schemata invoked by the two words: that moving to the previous screen will provide information necessary to understand the current topic, whereas moving to the next screen will provide new information that builds on the current information.
Once readers have found the correct topic, we help readers determine what schema they should adopt to help them understand the topic. If we have chosen an unfamiliar schema, we must clearly reveal that schema and help readers learn it instead of forcing them to waste time developing and testing new schemata until they find one that fits. As my washroom anecdote illustrates, we tend to ignore things that don't fit our search pattern, and only reluctantly try to develop a new model of our situation. Sufficiently motivated readers will do this, but others will instead abandon their efforts and give up trying to accomplish the task (or will look elsewhere for assistance if they can). For the shower, a simple label beside the correct switch would have provided the necessary schema: "Flick this switch and wait until the red light turns on."
Let's apply this insight to Web pages that contain long or complex topics. A motivated reader will discover the contents of the page through trial or error (i.e., by scrolling and skimming) and will eventually develop a schema for what the page contains. Why not spare them this effort by providing a miniature table of contents (TOCs) containing hyperlinks to each section? Those who need only an overview of the topic to refresh their memory obtain that overview immediately from the list of headings; those who need more detail can click a link to jump to the part of that page containing the details. (An introductory paragraph can provide this information too, but it displays the structure of the page less obviously because it does not resemble a list of headings.) Some authorities dismiss these mini-TOCs as redundant, but they take up little space, concisely summarize the topic, and are thus too useful to dismiss out of hand.
A similar approach can provide even stronger support for building a mental model. In one online help project, I lacked the resources to create a "wizard" that would guide readers through a complex multi-step process. Instead, I created a help topic that listed the overall series of steps, linked each step to a topic that described that step in detail, opened that topic in a second window, and added the instruction that readers should close that window to return to the overall list of steps and continue working through the overall process. Readers could figure this out with a little effort, but making it explicit spared them this effort.
Technical communication is often no more complicated than clearly describing the steps in a procedure, but sometimes we must repeat the thought process I've just described to create new schemata for each key part of a complex procedure. To succeed, we must first understand what readers must know to understand a current topic. If we can safely assume that they possess this knowledge, we can dive right into our description. If we suspect that some readers lack this knowledge, we can either provide it in the current topic or provide a link to the "what you must know before proceeding" topic. And if we know that most readers lack this knowledge, we must make it integral to the present topic so nobody must go searching through the rest of our body of information to find what they need.
You can see how this works through the metaphor of building a wall: the task is easier if you lay the foundation first rather than starting in mid-air and supporting the bricks until you reach the ground. Similarly, we communicate more effectively if we build schemata step by step instead of simply scattering the necessary concepts and forcing readers to figure out how to assemble them into a coherent whole. Assembly instructions often start by listing the components and tools we require before beginning, then portray the goal (the assembled product). This provides context by showing the start and end points of the process, and the instructions then show how to create a foundation and build progressively upon it until the assembly is complete. Similarly, descriptions of complex processes begin with basic concepts and build on them to produce increasingly complex knowledge. This approach links directly to general knowledge readers already possess or provides that knowledge, thereby providing a sound foundation on which they can build.
This article illustrated how mental models shape what we accomplish and support how we accomplish it. Schemata thus offer a powerful tool for supporting our readers because they take advantage of how the human mind works. Understanding the schemata that readers are likely to apply to a situation tells us what we can do to support those schemata, reveals whether it's necessary to help them create new schemata, and illuminates how we can build on existing knowledge to create those new schemata.
©2004–2024 Geoffrey Hart. All rights reserved.