The interaction between humans and technical artifacts has been a scientific discipline for several decades now. Nevertheless, we are regularly confronted with devices whose poor designs make them difficult, inefficient, and unpleasant to use. How do designers and manufacturers get away with this?
It appears that, when it comes to purchasing new technical devices like a phone, a stove, a DVD player, etc., very few of us take usability into consideration and, instead, rather focus on feature lists and price tags.
In his groundbreaking book, The Design of Everyday Things
, Donald A. Norman wrote back in 1988:
“Usability is not often thought of as a criterion during the purchasing process. Moreover, unless you actually test a number of units in a realistic environment during typical tasks, you are not likely to notice the ease or difficulty of use. If you just look at something, it appears straightforward enough, and the array of wonderful features seems to be a virtue. You may not realize that you won’t be able to figure out how to use those features. I urge you to test products before you buy them. Pretending to cook a meal, or setting the channels on a video set, or attempting to program a VCR will do. Do it right there in the store. Do not be afraid to make mistakes or ask stupid questions. Remember, any problems you have are probably the design’s fault, not yours.”
Even though this was written more than twenty years ago, the value of good usability still does not enjoy the public awareness that it deserves, and the vast majority of customers still have not made it a habit to test a device before making a purchasing decision.
Unfortunately, there’s a serious problem with Norman’s advice: with technical devices becoming ever-more complex, how can you reliably predict whether a specific product will provide you with an enjoyable user experience in the long run, if you don’t know what characterizes good usability in the first place?
Let me illustrate this with a personal example.
Mom goes online
My Mom has been using an iPhone for about two years now. When she got the device, she was beyond sixty years of age, and the closest she had ever gotten to using a computer was writing letters on an LCD-equipped electric typewriter. Despite her lack of computing experience, she very quickly learned how to send and receive emails, visit websites, take photos, jot down notes, check the weather, map routes, etc., and she often rhapsodizes about the ease with which she can perform these tasks.
Seeing her use so many features of her iPhone is quite remarkable, because on her previous mobile phone — a plain-jane, “non-smart” Nokia 6310i — she would not even use the built-in address book, because she found it too cumbersome to access and navigate. Whenever I ask her why she finds the iPhone so easy to use, however, she’s lost for words: she cannot explain what it is about the respective user interfaces, that makes the iPhone a much easier-to-use device than the Nokia. Consequently, if she were to buy another mobile phone in the future, she would hardly know what user interface details to look for to ensure that the new phone would be as user-friendly as her current one.
Evangelizing usability “to the masses”, then, obviously is not enough; educating customers about what defines good usability, and how to gauge it is at least as important.
Educating customers about usability
This is where a talk comes in that Professor Jan Borchers, head of RWTH Aachen University’s Media Computing Group, gave on occasion of the World Usability Day 2009 last November. Under the heading “Pleasure and Pain: User-friendly Technology in Everyday Life”, Borchers explained his “10 Rules for Usable Technology”, which are intended to help non-technical people understand which factors influence a device’s usability, and, based on these factors, support them in selecting a user-friendly product when buying technical devices.
Here’s my take on Borchers’ list.
1. Simplicity
“The device should offer the functions you really need, and not too many more.”
The more functions a device offers, the more controls are required to access those functions, and the more complex the user interface will need to be. Therefore, the first step towards purchasing user-friendlier products is selecting a device whose feature set is restricted to those functions that you really need.
To demonstrate the importance of this point, Borchers used the example of mobile phones: according to research conducted at his institute, the user interfaces of some of the modern “smart phones” are so poorly designed that some testers could not even find the number pad among all the features of the device, thus being unable to place a simple phone call.
Therefore, Borchers suggests to write down those functions that you expect to use the most on the device. For a mobile phone, three “must-have” features may be (1) making calls, (2) receiving calls, and (3) checking the time, each of which will likely be used several times a day. “Want-to-have’s” might be sending and receiving text messages, and muting the ring tone, each probably used a few times a week. Having these lists at hand while testing the device helps you stay focused on what you really need.
Before testing a device, write down the three most important functions you require the device to perform, noting how often you will likely use each function, and compile a similar second list of want-to-have features.
Describe the functions in terms of what you want to achieve, not how to achieve it. For example, write down “make a call” instead of “type in a phone number and press the call button”. This way, you avoid being biased towards a specific implementation you are already familiar with, and, instead, keep an open mind towards less conventional implementations. Case in point: on phones with voice recognition, calling someone may involve no typing at all.
Have these lists handy when testing a device — be that in a brick-and-mortar store, via a website, through a software trial version, etc. — and try limiting your shortlist of interesting devices to those products that offer these functions, but not too many more. If you do feel like buying a device that offers (perhaps much) more functionality, do focus your testing on what’s on your list, because it is these features that you will use most often, and they better be easy-to-use when accessed on a daily basis.
The following nine rules explain what details to look for during these tests in order to gauge the respective product’s usability.
2. Gestalt Laws
“The positioning of the device’s controls should make sense to you.”
The ways in which our brain interprets sensory perceptions follow certain rules. The so-called Gestalt Laws formulate these rules in a way that has proven to be very valuable for designing user interfaces.
Consider, for example, the number pad on a phone: all keys look the same, feel the same, and usually even sound the same when operated. Therefore, according to the “Law of Similarity”, our brain deducts that each of them also works in a similar manner, can be manipulated in a similar way, and provides a similar function. Since these keys are grouped closely together, our brain perceives of them not only as individual keys, but also as the totality of all ten keys as one “number pad” unit, as per the “Law of Proximity”.
Designers can leverage the Gestalt Laws to support the brain in making sense of a device’s user interface by, for example, grouping controls for related functions like the play controls on a CD player; using similar controls for similar operations like the clutch, brake, and gas pedals in a car; or marking sub-groups of controls by using different colors for the respective groups of controls.
When testing a device, see whether the controls on the device are laid out in a logical way: are the controls scattered all over the device, or are they divided into clearly distinguishable groups? If there are groups, can you make out what each group is for? If you recognize controls that look familiar, like a phone’s number pad, the buttons to set the time on a clock, or even the handle on a faucet, do they operate in a way that you remember from similar devices?
More generally speaking, do the user interface elements of the device operate as you expect them to based on your previous experience, i.e., does an element that looks like a button actually operate like a button?
3. Visibility & Feedback
“The device should make it easy for you to discover both what it can do, and what it is actually doing, at any given time.”
Heater units in older cars tend to be extremely easy to use. In part, that is because there are only very few controls, usually one each for adjusting the temperature, for setting the airflow and fan speed, and for selecting which vents the air should come out of. What’s more, you can usually tell which control is used for which function, which settings are available, and what the current setting is, by simply looking at these controls.
For example, the control to set the temperature is the one with the blue and red markings, and based on cultural convention, we know which position indicates “warm” and which “cold”; the control for the fan is usually marked with numbers, so we can see how many different settings there are for the fan speed; we will know which vents the air will come out of by looking at the symbol that the corresponding dial is pointing at.
Such visibility makes it easier to learn a new device, because it shows us what functions the device affords: because the designer has made visible which function can be set with each control, and which settings are possible, it becomes fairly straightforward to understand which functions are available at all.
This is complemented by feedback, which shows us what a device is doing after we have manipulated it: when I switch on my stereo system’s amplifier, there is a short delay before any comes out of the speakers. To indicate that I successfully switched on the unit, however, the power light changes from a steady red (for standby mode) to blinking green, and once the amp has finished whatever it needs to do after being switched on, the green light is on permanently. If the power light would go straight to green without blinking, I might be wondering whether the system was broken: after all, if the amp is on, as indicated by the green light, it should also play my music through the speakers.
Feedback is not always limited to visual indicators, but can also use sound like the warning signal you hear when you open a car door while the key is still in the ignition lock, or it can be haptic, like when you can feel how a rotary dial “snaps into” distinct settings.
Through visibility, we can tell what we can do with the device at any given time, and thanks to feedback we receive unambiguous information on what the device is currently doing, or has done, at any given time.
When testing a device, you should be able to tell which control is used for which function through proper layout of these controls (as outlined in rule #2 above) and easy-to-understand labels of the controls with plain text or intuitive graphical symbols. Also, when you press a button, move a knob, etc., watch for proper feedback from the device: can you tell what the device did after that button press, knob movement, etc.? Even more importantly, if the device has automatic functions — just think of an electronic thermostat that automatically controls your home’s heating –, verify that you can find detect its current status without any guesswork.
4. Speaking Your Language
“The device should communicate with you in a language you understand.”
A device’s user interface should “speak” a language that you understand: this refers not only to the user interface being localized into your native language, but also to the choice of jargon — or, rather, the lack thereof. Essentially, “make a call” and “establish a connection with the nearest NOC and negotiate a voice channel” are technically the same thing, but the latter expression will only mean anything to you if you are familiar with communication technology.
When testing a device, compare the technical terms used on the device with what you have written down on your function list. Does the device use the same expressions that you have used? Are there any words or symbols that you find confusing, or that make the device difficult to understand? Does the device even “speak” your native language, or is it only available in, say, English?
Does the device come with an easy-to-understand users guide that explains all of its features? More often than not, devices are not quite as “self-explanatory” as sales people want to make you believe…
5. Natural Mappings
“The way the device reacts to your input should feel natural.”
“Mapping” of controls describes which function is hooked up to which control, and how manipulating that control impacts the respective function. A natural mapping is one that is intuitively understood based on the placement of the control and the manipulation which the control affords.
Take, for example, an electric wheelchair that is controlled via a joystick. We naturally assume that the wheelchair’s movement will follow that of the joystick: push it forward, and the wheelchair should move forward, push the joystick to the right, and the wheelchair should steer in that direction, etc. Another example are the buttons in an elevator, whose positioning mimics that of the building’s floors: ideally, they are arranged in a vertical row, with those for the top floors located at the top, and those for the basement at the bottom of that row.
For some cases where there does not seem to be a natural mapping, we humans have developed conventions that apply to the vast majority of cases: e.g., when turning a rotating dial — like the volume control on a stereo system — we expect that “right” means “more”, and “left” means less. Similarly, we expect that, on a sliding control — like a light dimmer switch or the volume faders on a mixing console –, “up” means “more” and “down” means “less”.
When testing a device, compare what happens when you manipulate a control to what you expected to happen: does working the controls feel natural to you? Can you understand the controls intuitively, or do you have to make a conscious effort to get your head around what to do with specific controls?
6. Enough Controls
“There should be enough controls to access each function in only very few steps.”
Ideally, each of a device’s functions should have its own, dedicated control, because in case one control is used for more than one function, the device must operate in multiple modes. These are often difficult to grasp for non-technical users, and many devices do not clearly indicate which mode they are currently in.
A rather extreme example is the single-button control built into the head-set cable of Apple’s iPhone: when listening to music on the iPhone, pressing this button once toggles between play and pause, pressing it twice quickly will jump to the next song, and pressing it three times quickly will jump to the previous song. If the phone’s ringing, however, pressing the button once will accept the incoming call. Depending on when, how often, and for how long you press it, this single button can perform a total of eleven functions!
Contrast this to having dedicated play control buttons — like play, pause, rewind, fast forward, skip to previous or next track — on any stand-alone video recorder, DVD player, CD player, etc.: these tend to use a standardized layout and standardized symbols or labels, so that, if you know how to use these controls on one device, you should be able to use them on any device of this type without ever having to refer to the user manual.
When testing a device, look at the number of features the device has and compare that to the number of controls: are there many more functions than controls? Are the controls labeled so that you can always tell what each control will do? If one control is used to access multiple functions, can you remember what those are, and also tell which function will be triggered at any time?
Note that, for something like a touch-screen mobile phone, you have to take into consideration both the hardware controls on the device itself, as well as those software controls shown on-screen.
7. Consistency
“The device should not surprise you in bad ways.”
In his talk, Professor Borchers used a great phrase to explain what consistency means, characterizing it as “The Principle of Least Surprise”: similar input results in similar output, controls that look similar operate in a similar fashion, a function is referred to by the same name throughout the user interface, etc.
While not directly related to consistency per se, he stressed the point that “least surprise” also means that a device should only become active when it is triggered by user input, or if there is a seriously important reason to interrupt the user: when you quit a software application, it is necessary for the application to actively warn you if there are any unsaved changes, lest you lose data.
There is no need, however, to display a message saying there are no unsaved changes every time you quit an application. More generally speaking, a device should not at arbitrary times “warn” you that everything is perfectly fine, as such positive “completion confirmations” would only interrupt you in your work for no good reason.
Automatic state changes are another unwelcome surprise when using a device. Many devices that have a programming mode — clocks, DVD recorders, car radios, etc. — implement timeouts: if you do not enter the required data within a certain amount of time after putting the device into programming mode, the device will go back to the standard operation mode, discarding any of your changes without warning. As Borchers put it, “timeouts are evil”.
When testing a device, watch out for “surprises” in the form of unexpected behavior. Do similar controls operate in similar ways? Does the device interrupt your workflow by providing feedback that is both unexpected and non-critical at any time? Does it patiently wait for your input, or does it put stress on you by requiring you to react within a certain amount of time?
8. Dialogs, not Monologues
“The device should ‘listen’ to you at all times, and ‘talk’ to you when necessary.”
There is a good reason why “dialog boxes” in a software application have that very name: they are all about two-way communications between user and device. But the dichotomy between dialog and monolog goes further that, as it also relates to how the user can influence whatever task is currently performed by a device.
One of the most apparent examples is being able to stop the copying files from one location to another on a computer by simply clicking a button. That is dialog: by displaying a “progress bar” in a window, the device lets you know that it is busy copying files; but at the same, it “listens” to user input, allowing you to stop this process and possibly tell the device to perform another task instead. Without this “Cancel” or “Stop” button in the file copy dialog window, you would have to wait until the computer has finished copying all files before it would accept further input.
Technically speaking, dialog is about not locking the user out through “modal” operations, and there are countless examples for dialog behavior that we have come to take for granted: adjusting the equalizer in music player software while music is playing, going to another scene when watching a video on a computer by moving the play head below the video, scrolling a web page while it is still loading images, or simply having several software programs open at the same time and being able to switch between them with a single key press.
This principle is not restriced to software, either: just think of the Reverse button on a paper shredder or the “Off” button on a microwave oven.
When testing a device, start some tasks on the device that will run for a few seconds, and try to stop the process, or change settings, while it is running. Is this possible at all, and, if so, what does the dialog between you and the device look like: can you easily tell that your interference was successful?
9. Error Tolerance
“The device’s should help prevent them, and if they happen, make it easy to recognize and fix them.”
Users make errors, and ideally, a well-designed user interface would help prevent errors in the first place: cars with automatic transmissions will not allow you to take the key out of the ignition lock, unless the gear lever is in the neutral position to prevent runaways; the door on a washing machine may only allow you to open it after you have pumped out the water in the drum to prevent flooding of your basement.
Whenever a system utilizes such a “lock-out” function to prevent user errors, the aspects of visibility and feedback become even more important, because the user must be able to find out why the function is not available, and what she needs to do to be able to get around the lock-out.
If an error does happen, the device should help you deal with the error: it needs to explain what went wrong so you will not run into the same problem again in the future, and suggest what to do to fix it. Linking into rule #4 (Speaking your language), error messages and notifications should, again, be written in a way that you can understand: messages like “Error: could not complete operation (-19855)” are meaningless to a non-technical person.
One of the key features of well-designed software applications is to be able to revoke — or “undo” — previous actions. This is especially helpful when you make an error that the software cannot detect, like using the “wrong” words when writing a letter, applying the “wrong” color when drawing an image, or playing the “wrong” note when composing a piece of music.
Unlike technical errors — not being able to save a document because there is not enough memory on the hard drive –, the software is not able to detect “errors” that are based on human taste or personal preference. In such cases, being able to “undo” what you just did, is often the only way to be able to start over from a few steps back.
When testing a device, attempt to provoke an error by doing something that the device was most probably not designed to do: type a very long number into a mobile phone, request a navigation system to find a car route between two continents, assemble a food processor in “creative” ways. Then see how far you can take this before the system interrupts you actively — e.g., via an error message on the phone’s screen — or passively — by making the parts of the food processor fit only in a certain way.
When presented with active error messages, apply rules #4 (Speaking your language) , #7 (Consistency), and #8 (Dialogs, not monologues); and when confronted with passive, mechanical constraints, ask yourself whether you can intuitively tell how to operate the device correctly.
10. Vertical Design
“As few companies as possible should be involved in the device’s design.”
While I would not consider this a fundamental requirement for user-friendly products, Borchers makes the point of preferring “vertically designed” products, all components of which have been designed by one company, over “horizontally designed” products which combine components from several different manufacturers. Think “computer running Apple iPhoto software under Apple’s Mac OS X operating system on Apple hardware” vs. “computer running Google Picasa software under the Microsoft Windows operating system on Dell hardware”.
Although I feel that this aspect usually only relates to computer-like products, anecdotal evidence does support the assumption that the tighter integration of the “everything-from-one-source” approach will make for a more user-friendly and enjoyable user experience.
When testing a device, find out how many manufacturers were involved in building the device. Specifically, be wary of highly technical devices that state that “some assembly is required”!
What’s next?
Professor Borchers’ Ten Rules will not magically turn every reader into a usability expert, let alone allow measuring usability in absolute terms. They do, however, provide solid guidelines for comparing similar products, thereby enabling customers to transcend from feature-list-based purchases to those based on user-friendliness. To that end, the next two steps will net be: (1) user-testing of the Ten Rules and (2) spreading the word.
When I finished editing this article, some questions entered my mind: “Is this article written in a language that non-technical readers can understand?”, “Are the explanations insightful, or are they too abstract?”, “Do the examples refer to something that the ‘average’ reader can relate to?”, etc. User-testing with “non-techie” readers is required in order to be able to answer such questions.
Even if the Ten Rules pass this test, customers still need to hear about them. Therefore, if you are into usability engineering yourself, please help spread the word! And if you would like to comment on this article, or provide additional input, by all means, do send me an email!
