Have you ever tried to use a kitchen stove and ended up turning the wrong burner on by mistake? Yeah, us too. Just about everyone who cooks has run into this minor annoyance at some point in their life, if not repeatedly. So what do naughty stoves have to do with software? You may be surprised to learn that your digital products may suffer from the same fundamental problem that makes these stoves annoying and counterintuitive.
The problem with these stoves is poor or unnatural mapping. The term mapping describes the relationship between a control, the thing it affects, and the intended result. Poor mapping is evident when a control does not relate visually or symbolically with the object it affects, requiring the user to stop and think, "what’s going to happen when I turn this knob?"
To understand how mapping works, it’s helpful to dig a little deeper into the problem with stove cooktop controls. The typical cooktop, such as the one shown below, features four burners arranged in a flat square, with a burner in each corner. However, the knobs that operate those burners are laid out in a straight line on the front of the unit.
In this case, the result of using the control is reasonably clear: A burner will heat up when you turn a knob. However, the target of the control—which burner will get warm—is unclear. Does twisting the left-most knob turn on the left/front burner, or does it turn on the left/rear burner? The answer to this question is usually found by trial and error, or by referring to the tiny icons next to the knobs, even when the person has used the oven before.
So what are the consequences of this bad mapping? In the best case scenario, the user just feels a little silly that they twisted the "wrong" knob, or the food simply doesn’t get hot until they notice their error. In the worst case scenario, they could accidentally burn themselves or something else. (I’ve done this: I torched a pot-holder once by accidentally turning on the burner underneath it when I thought I was turning on a different burner.) Clearly, this is an undesirable behavior of the product that doesn’t contribute to customer satisfaction.
A simple solution is to change the physical locations of the cooktop knobs to suggest which burners they affect. The knobs don’t have to be laid out in exactly the same pattern as the burners, just positioned so that the target of each knob is clear. This cooktop is a good example of an effective mapping of controls:
In this layout, it’s clear that the upper-left knob controls the upper-left burner. The placement of each knob visually suggests which burner it will turn on. There’s no confusion: The food gets hot, and nothing gets burned. (Well, except maybe when I’m cooking.) Donald Norman calls this more intuitive layout "natural mapping" in his book The Design of Everyday Things.
Unfortunately, poor mapping isn’t limited to major appliances. I frequently run into a similar problem when changing the background color of a table cell in Microsoft Word. In this case, I have a simple three-column, three-row table. I select the first cell, then bring up the "Borders & Shading" dialog to change the background color of that cell.
When the dialog appears, I select the color I want and hit the OK button. I expect the selected cell to turn blue, but surprisingly, the entire table turns blue instead.
To be fair, if you read the fine print in the dialog, you’ll see that all the clues are there. The dialog has a labeled list control that defaults to, "Apply to: Table." One of the other options is "Apply to: Cell." However, this is much like the little icons on the stovetop. If people actually stopped and read these things there would be no problem, but that’s not how people work. The good news is that nothing gets burned in this example, but this behavior is annoying and requires the user to undo the last operation and start over. It wastes the user’s time and erodes confidence that the next feature will work as expected.
Interestingly enough, the solution to this problem is also in Microsoft Word. If I do the same exact thing, but use Word’s "Tables and Borders" floating toolbar instead, I get the result I want. I select a single cell, then select a color on the toolbar…
…and the selected cell turns blue, not the entire table.
Why a dialog and a floating tool bar that perform the exact same operation use two different defaults is unclear. What is clear is that the toolbar does what I expect by operating on my selection by default—like just about everything else in Word—while the dialog operates on the entire table by default. No time is wasted and the user is given no reason to question the behavior of the software.
Another example of poor mapping—of a slightly different flavor—is pictured below. In this case, it is the mapping of concepts to each other that is unclear.
This is from a website that uses a pair of drop-down menus to sort a list of search results by date. The selection in the first drop-down determines the choices present in the second. In this case, when "Re-sort results by: Date Placed" is selected in the first menu, the second drop-down presents the options "Ascending" and "Descending."
The problem lies in the terms chosen to communicate the date sorting options: "Ascending" and "Descending." An informal poll found that people were generally unsure which option they should choose if they wished to see the most recent items first in the list—it was evenly split between "Ascending" and "Descending." All of them had to think about it for a little bit. One person was especially frank, stating that in his experience the option he selected always did the opposite of what he expected.
Unlike the poorly mapped cooktop knobs, the target of this control is clear—the drop-down menu selections will affect the list below them. However, the result of using the control is unclear: Which sort order am I going to get? This ambiguity is confusing and interrupts the flow of the task at hand.
The primary issue is that the terms "Ascending" and "Descending" are non sequiturs in this context—they don’t map conceptually to dates or time. People don’t generally think of dates as "ascending" or "descending;" rather, it is more common to think of dates and events as being "recent," or "ancient," or "about five months ago." A quick fix to this problem would be to change the wording of the options to "Most recent first" and "Oldest first."
Given more time, you might think of better words to use than these, or better yet, a more elegant mechanism for sorting items by date. But with this simple change, the formerly confusing control addresses the concept of dates in terms relating to time. This clearer mapping makes it easy to understand what the resulting sort will be, allowing the user to focus on the task at hand rather than the interface of the website.
Whether you make appliances, desktop applications, or websites, your product may have mapping problems similar to those discussed here. The good news is that mapping is an area where attention to detail pays off—you can measurably improve a product by seeking out and fixing mapping problems, even if you have very little time to make changes. The result? A product that is easier to understand and more pleasurable to use.