When GUIs fail

 

Our informal studies show that 60% of a system's usability comes from task focus, 25% from consistency and just 15% from presentation of information.

Ask someone to write the history of usable computer systems, and most people will put the GUI-the "gooey" or graphical user interface-as the pinnacle of mankind's achievement.

Which is interesting, because the GUI has been responsible for more sins against users than any other invention. The GUI equates usability with information presentation: windows, icons, use of colour, menu design-essentially the information that we see on the screen. Yet the GUI is often a veneer hiding a wealth of usability problems, like wallpaper over cracks.

E-mail programs

One example can be had by comparing the e-mail programs, Claris Emailer and Eudora. You can see from the pictures that the first thing that strikes you about Claris Emailer is the attractive visual design. The user interface is built around the now familiar metaphor of "Tabs".
 
The difficulty this poses is that if you create a new mail message while the "In box" tab is active, you don't get the reassuring feedback of seeing the new message appear in the "Out" list. I found that every time I created a message, I would then click on the "Out Box" tab just to make sure it had been created OK. Eudora, on the other hand, has separate windows for the "In" and "Out" mailboxes.
 
This means you get immediate feedback when you create a message.

 

Visual presentation

An additional problem with this "GUI-fication" is that Emailer uses graphic symbols to denote status, whereas Eudora uses alphabetic symbols. So for example, once you reply to a message, Emailer appends a green "return" symbol to it, where Eudora uses the letter "R". But if you Forward a message, Eudora gives the message the status "F", whereas Emailer provides no information. The risk here is that, with Emailer, the user could end up replying to a message after forwarding it, forgetting that the message had already been dealt with. A further difference is the symbol used for unread mail. Eudora uses a bullet in the left hand margin which disappears once the message is read. Emailer provides a symbol only after you have read the message. So in Emailer, if the tick column is blank, the message still hasn't been read. Usability is being sacrificed here to achieve a pleasing visual design.

 

Nobody would argue with the fact that users are influenced by the "look and feel" of software, just as we make decisions about people by the way they dress and talk. You probably have your own list of user interface crimes: such as poor use of colour, difficult to read fonts, and icons that obfuscate rather than illustrate. So you may be interested to know that our experience shows that visual presentation, although important, only accounts for a small percentage of the overall usability of the system: perhaps 15%.

Consistency

Systems that score high on usability also show a second key feature: consistency. Consistency accounts for about 25% of a system's usability.
We can all point to annoying inconsistencies in (or between) much of the software we use. For example, in virtually every Macintosh application ever designed, the keyboard shortcut COMMAND-S saves the current file to disk. I have recently used a Macintosh organiser application where this keyboard shortcut is used instead to "Sort" a list of items. In this example, the inconsistency is an irritation, but move the application domain to a nuclear power station or the control room of a chemical plant and one man's irritation quickly becomes another man's environmental catastrophe.

 

Consistency is sometimes derided because it seems open to judgement. For example, if I asked you to put away the knives, forks and spoons in my kitchen, you would look for the cutlery tray. But if I then asked you to put away a penknife, you would probably look for the overstuffed drawer that contains items like the corkscrew and the tin opener. And if I then asked you to put away a Stanley knife, you would probably place it in the garden shed with the hammer, screwdrivers and other tools. This seems inconsistent, and it is at this stage that the designer throws his hands up at the futility of ever understanding people and retreats to his suite of GUI tools.

In fact, your behaviour in these examples is entirely consistent with the task that you use these objects for. A knife is more like a fork than a Stanley knife when the task is eating; but it is more like a hammer when the task is DIY. The task is the common denominator. This leads us on to the most important factor in designing usable systems, a factor that is missed when we just focus on information presentation and consistency.

Task focus

The bulk of a system's usability, the remaining 60%, is accounted for by task focus.

 

You know a system has task focus when you get a warm feeling that the person who designed this system knew what they were doing. You find you are able to use the system to do exactly what you want. There is no need to go searching through menus or dialogue boxes for obscure commands: the main things you want to do are there, in front of you: easy to find and simple to carry out. The system delights you. Successful computer games are fine examples: very quickly, the "interface" disappears and you are exploring the world of the game-the task.

How do you achieve task focus? Rules for good visual design are plentiful-you can get them from a book. Consistency can be achieved by using code libraries and then testing against a style guide. But task focus-well, it all depends on the task...

The crucial first step is to drive your design with a set of realistic tasks that real users are likely to carry out. For example, if it's a videophone, users are going to want to make a videophone call. But that isn't the task-that's just another description of the product. To drive the design, the tasks need to be complete, representative and concrete. So if we elaborate, making a videophone call may have the following steps:

  1. Check the self-view
  2. Dial a number from the on-screen phone book
  3. Initiate the connection 
  4. Share electronic documents

These are still not tasks, however: they lack the detail needed to drive the design. Re-writing these steps as a task gives:
"Adjust the self view facility to check your image is framed appropriately by the camera. Then find Peter Smith in the phone book and dial his number. Show Peter the proposed design for the new office and decide on the best alternative for the layout of the desks on Floor 2."

The advantage of this description is that it focuses on interface problems that occur during tasks the user will actually be doing, and it gives some idea of the importance of any problems in the context of the job. Because a single task scenario cannot cover all the functionality of the system, it will be necessary to write a number of scenarios and check them against the stated functionality of the system. But in our experience, it is rare to require more than seven or eight tasks scenarios, even for very complex systems.

Next time you're faced with the design of a new system, don't fall into the GUI-fication trap. Allocate your design activity to reflect the needs of end-users, and put the bulk of your effort into task focus. Users will thank you because they will be able to work more effectively. And just as importantly-you will sell more software!
-- April 1997

For more information contact Leslie Fountain.

If you enjoyed this, try these:

Case Study: Designing the HCI for an automated fingerprint system
The Home Office commissioned us to ensure the usability of the £93 million National Automated Fingerprint Identification System (NAFIS). The usability challenge was to ensure that fingerprint officers-whose exposure to computers is often slight-could use the system.

The usability of online banking: how not to do it
Within 3 years, 26m adults in the UK will have access to on-line banking, mainly through their TV set. We predict that less than half of this target market will actually use on-line banking unless the usability of current on-line banking is fundamentally improved. This is because these services flout even the most basic usability principles, effectively making the service impossible for novices to use.