Category: Usability Basics

The very first article on the UI Observatory describes Prof. Jan Borchers’ “Ten Rules for Good Usability”. The Ten Rules’ aim is to help consumers gauge a product’s usability before making a purchasing decision, and this follow-up article will examine a real-world example for how to apply them.

The device

For any guitarist, a tuner and a metronome are essential tools. When I started playing electric bass about two-and-a-half years ago, I purchased a Korg TM-40, which combines both tuner and metronome in a single, handy device.

Just recently, I bought a similar combo device, a Boss TU-88. Comparing these two devices with the help of the Ten Rules resulted in some interesting observations about the devices’ usability.

How the devices work

Like its classic cousin, an electronic metronome provides a precisely timed click sound, which helps musicians practice playing in perfect time. In addition to the simple click provided by the mechanical specimen, most electronic metronomes offer several beat patterns, using two differently pitched clicks for adding an accent to the first down-beat of a pattern.

The key controls for this kind of device start and stop the metronome, adjust the tempo, and select the beat pattern.

State-of-the-art guitar tuners are ingenious pieces of technology: you plug the instrument’s cable into the tuner, pluck a string, and the tuner analyzes the note you’re playing. LEDs and/or a gauge indicate whether the string is in tune, or not. And if it’s out-of-tune, the device shows whether the string needs to be tuned higher or lower to get to the target note.

For basic use, all that is required to control the tuner is a button to switch it on or off.

With the exception of a simple headphone amplifier that is integrated into the Boss, both devices do not provide any functionality that goes beyond the tuner and the metronome. They are very similar in their feature-sets and, thus, make for a great comparison.

1. Simplicity

“The device should offer the functions you really need, and not too many more.”

As outlined in the original “Ten Rules” article, the first step is to compile a list with the three functions offered by the device that one expects to use most often. In the case of the tuner/metronome, my list looked like this:

1. Tune my bass (i.e., de-/activate the automatic tuner feature).
2. Start/stop the metronome.
3. Change the tempo of the metronome.

The list of less-often-used functions that I also expect to use, includes a single item:

1. Change the meter, or “beat”, of the metronome.

Although either device offers a few additional features beyond these four, they do not add any excessive complexity because — with the exception of the Boss’s built-in headphone amp — they are all related to the core tuner and metronome functions. Both devices pretty much focus on what I need.

In the following sections, I will focus on the user interface details related to the four functions from the lists above.

2. Gestalt Laws

“The positioning of the device’s controls should make sense to you.”

On both devices, all essential user controls are located on the front panel. The layout of the controls, however, is decidedly different.

The Korg TM-40 has two distinct groups of buttons that are lined up in vertical columns. These columns are clearly labeled “Tuner” and “Metronome,” respectively. Even if you do not know (yet) what each button does, you can easily tell which group of controls affects which of the device’s functions.

Within these two groups, the buttons are further differentiated by their shape, position, and size:

• The power buttons are oval, whereas the others are round,
• the tuner’s Sound button is slightly removed from the Calib[ration] buttons, and
• the Start/Stop button — which is most likely the most-used control on this device — is much bigger than the Tempo and Beat buttons, so it’s easy to see and hit.

Compared to the Korg, the Boss’s layout is more cluttered in terms of the controls’ location, grouping, and shape. It has four groups of controls: the three buttons above the display for power/tuner/metronome, the four buttons below the display, the Tap button, and the headphone volume dial. In fact, one could argue that, because of their different shapes and their positions relative to the circular bezel, the power button and the tuner/metronome buttons form separate groups, bringing the total to five groups of controls.

Generally speaking, it seems as though the Boss’s designers placed a lot more emphasis on visual aesthetics than the Korg’s. As a result, the Tuner and Metro[nome] buttons are oddly shaped to fit into the circular bezel; valuable space is wasted around the volume control dial; and the Tap button’s location on the front plate gives it way more visual “prominence” than it deserves.¹

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.”

Both devices’ displays clearly show which function is enabled at any time, and both play short beeps for the metronome’s clicks, which are accompanied by bright LEDs lighting up in-sync. Similar LEDs are used for the tuner, indicating whether the string is tuned properly to the correct note, or whether it is too low or too high, respectively. So far, so equal.

To configure the metronome in the Boss TU-88, the user has to set two separate parameters, one for beat pattern and one for the number of beats per bar. For more complex patterns, the second parameter selects the number of bars for the pattern. Both parameters are displayed as single-digit numbers without any identifying labels, so that you need to remember which digit represents which parameter.

For the pattern parameter, you also need to remember which pattern is assigned to which number, because the list of patterns is only found in the users manual, but not on the device itself.

The Korg designers have implemented a more-intuitive solution by combining a single-digit number with a few symbols to indicate the metronome’s pattern setting: when selecting the pattern, the device steps through different straight meters like 3/4, 4/4, 5/4, etc., and then through a few special patterns, including eighth notes and triplets. Straight patterns are indicated by the single-digit number, whereas the special patterns have their own note symbols.

Consequently, it’s simpler and more intuitive to select a metronome pattern on the Korg than it is on the Boss: simpler, because there is a single parameter instead of two, and more intuitive, because icons that are meaningful to any musician are shown on the display instead of an abstract number. (see also “6. Enough Controls” below)

4. Speaking Your Language

“The device should communicate with you in a language you understand.”

Both devices ship with an extensive users manual, and the labels on the faceplates use words and icons that any musician should be familiar with.

The only details that may be confusing when using either device for the very first time are the button “Sound” on the Korg and the button labeled with a speaker icon on the Boss, which both control the same function: they switch a tuning tone on or off, whose pitch you can adjust, and against which you can tune non-electrical instruments.

After you have used this button for the first time, the label should be sufficiently intuitive to help remember what these buttons do.

5. Natural Mappings

“The way the device reacts to your input should feel natural.”

On both devices, some values, like the metronome’s tempo, can be increased and decreased.

On the Boss, two buttons control all such settings through a number of modes (see “6. Enough Controls” below), and these two buttons are arranged horizontally. While, at least in our Western culture, “move towards left” means “less” and “move towards right” means “more”, that mapping has much less urgency than a vertical arrangement, in which “move upwards” means “more” and “move downwards” means “less”.

The Korg designers chose to arrange the three pairs of decrease/increase buttons on the TM-40 in this more natural vertical arrangement.

6. Enough Controls

“There should be enough controls to access each function in only very few steps.”

The tuner and metronome in the Korg have their own dedicated power buttons, so you can switch both sections on or off individually, and even use them at the same time, if you so choose.

All key settings that affect the functions I put on my required-items list — start/stop the metronome, and adjust its tempo and pattern — are accessible directly through a start/stop button and two pairs of decrease/increase buttons.

The Boss has a dedicated power button, and the Tuner and Metro[nome] buttons switch between the two modes of operation, with the Metro button doing double-duty as the metronome’s start/stop control. The buttons beneath the display are shared between tuner and metronome.

To make adjustments, you press the Sel[ect] button repeatedly until you have selected the desired parameter, which starts blinking on the display. Then you use the down/up buttons to adjust the parameter. Although the device is fully operational while a parameter is selected, the blinking on the display can be a bit distracting, so you will likely choose to press the Sel button a few more times until you have left the parameter selection/setting mode.

As a result, changing the metronome’s tempo on the Boss requires pressing the Sel button three times before you can perform the actual adjustment. Contrast this to the Korg’s dedicated down/up buttons, that provide immediate access to the tempo parameter.

Usage modes tend to generally make a device more inconvenient, if not more difficult, to use. Especially when applying a device to a creative endeavor like making music, modes easily get in the way and disrupt the user’s creative flow.

Considering how often a musician will adjust a parameter as fundamental as a metronome’s tempo, I dare say that the Boss’ designers have made a surprisingly bad decision when they implemented this modal approach.

7. Consistency

“The device should not surprise you in bad ways.”

Aside from the visibility issues with the meter/beat selection on the Boss, the only “surprise” I noticed is related to having separate power and tuner/metronome selection buttons on this device.

Switching the Boss on requires pressing the power button first, and the device will then start up in the mode that was active before it was powered off the last time. If it starts up in tuner mode, pressing the Metro button switches to the metronome mode; if, however, it starts up in metronome mode, pressing the Metro button will start the metronome.

8. Dialogs, not Monologues

“The device should ‘listen’ to you at all times, and ‘talk’ to you when necessary.”

The Boss’s settings modes aside, any button presses or dial adjustments affect both devices’ operation immediately, and the data shown on the displays reflects such changes just as quickly.

9. Error Tolerance

“The devices should help prevent errors, and if they happen, make it easy to recognize and fix them.”

Due to the nature of both of these devices, making an error could cause as “dramatic” a problem as the metronome clicking away at the wrong tempo. In other words, any errors you could make by using this device have negligible consequences, and can be fixed easily and quickly.

10. Vertical Design

“As few companies as possible should be involved in the device’s design.”

Prof. Borchers made this point in connection with software running on personal computers and mobile devices, where several software and hardware components may be supplied by a number of different manufacturers.

For simple self-contained gadgets like this one, this point does not apply.

Going beyond the ten rules

The Ten Rules provide helpful guidelines for gauging a product’s usability, but there usually are some factors that they do not address.

For example, the Boss TU-88 has rubberized pads on the underside, which prevents it from sliding around on a slippery surface, whereas the Korg TM-40 may be pulled off a table merely by the weight of the guitar cable.

Unlike the usability of a device’s user interface, it is much harder to detect such details that may affect everyday use. Then again, actively applying the Ten Rules when checking out products at a store may still help find such things. That’s because you tend to take a much closer look at a device than you would when basing your purchasing decisions on feature lists or in-store demonstrations alone.

Play before you pay

At first sight, the Boss TU-88 and the Korg TM-40 offer similar functionality and a more or less similar user interface. When applying the Ten Rules, however, it becomes obvious that there are differences between the two that have a noticeable impact on how easy and how pleasant it is to use either device.

The most obvious detail is setting the metronome’s tempo and pattern: the Korg lets me access both of these parameters directly via dedicated buttons, whereas the Boss forces me into a selection mode before I can make adjustments.

When trying out these adjustments a few times in the store, you probably won’t notice much of a difference. But as soon as you use the device on a regular basis, a small detail such as this will hugely influence your satisfaction with your purchase.

With the help of the Ten Rules, even non-expert consumers should be able to get a feel for this kind of subtle and not-so-subtle differences in usability well before finalizing a buying decision.

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!