Usability Heuristics

HUMAN-COMPUTER INTERACTION

Contents

1. Simple and natural dialogue

2. Speak the users’ language

3. Minimize user memory load

4. Consistency

5. Feedback

6. Clearly marked exists

7. Shortcuts

8. Good error messages

9. Prevent errors

10.Help and documentation

Simple and natural dialogue

Interfaces should be designed as simply as possible.

Additional features on a screen can decrease usability of the interface and give the users more opportunities to misinterpret them.

Interfaces should match the users’ task naturally.

The ideal is to present exactly the information the user needs at exactly the time and place where it is needed!

Graphic design and colour Good graphic design is an important element in

achieving a simple and natural dialogue.

The proper design increases the users’ understanding of relationships between the dialogue elements.

Things are seen as belonging together, as a group, if

they are close together,

are enclosed by lines or boxes,

move or change together, or

look alike with respect to shape, colour, size, or typography.

Graphic design and colour (example)

Guidelines for colours (Rice 1991)

Don’t over-do it. It is better to limit the design to a small number of consistently applied colours (5-7).

Make sure that the interface can be used without the colours. There are also colour-blind people.

Try to use colour only to categorize, differentiate, and highlight, not to give information, especially quantitative information.

Less is more

Identify information that is truly important for users.

Design a single screen with this info and relegate less important information to other screens.

Extra information in one screen slows down even expert users.

A common design mistake is to believe that “by providing lots of options and several ways of doing things, we can satisfy everybody”.

This does not mean that we should not provide alternative techniques.

Speak the users’ language Terminology should be based on the users’ language

and not on system-oriented terms.

“Language” is not limited to the words in the interface but should include nonverbal elements like icons.

To speak users’ language does not imply limiting the interface vocabulary to a small set of commonly used words.

Also, this involves viewing interactions from user point of view:

“You have bought 100 shares of XYZ Corp.” - correct

“We have sold you 100 shares of XYZ Corp.” - incorrect

Speak the users’ language (continued) The system should not force naming conventions

or restrictions on objects named by the user (e.g., long names).

An obvious idea is simply to ask users what words and concepts they would like to see in the interface.

Metaphors (e.g., the operation “delete files” and icons like a trash can, a paper shredder, and even a black hole).

Minimize user memory load

Interfaces should aim at minimizing our memory load.

It is much easier to recognizing something that is shown to you than to recall the same from memory without help.

Our passive vocabulary is much larger than our active vocabulary.

E.g., when users want to rename an info object, we should allow user to make a modification to the name instead of typing everything.

Minimize user memory load (continued) Interfaces based on recognition rely to a greater extent on the visibility of the objects of interest to the user.

Whenever users are asked to provide input, the system should describe the required format and, if possible, provide an example of legal and sensible input. E.g.,

Enter data (DD-Mmm-YY, e.g., 2-Aug-04):

There is no need for the user to have to remember or guess at the range of legal input and the unit of measurement that will be used to interpret it. E.g.,

Left margin: 10 points [0-128]

Consistency

Consistency is one of the basic usability principle.

If users know that the same command or the same action will always have the same effect, they will feel more confident in using the system.

The same information should be presented in the same location on all screens and dialog boxes and it should be formatted in the same way to facilitate recognition.

Use UI standards in the design. This could ensure some consistency.

Standards specify many details of the dialogue, such as how to indicate a pop-up menu or which fonts to use.

Consistency (continued)

Consistency includes considerations of the task and functionality structure of the system.

The program could be inconsistent with:

Users’ tasks expectations

Other relevant programs and interfaces

Inconsistent with itself

Feedback

The system should continuously inform the user about what it is doing and how it is interpreting the user’s input.

Feedback should not wait an error situation has occurred.

System feedback should not be expressed in abstract and general terms.

E.g., warning a user about some irreversible actions, such as overwriting a file.

Good feedback includes attributes of two files: dates of modification, sizes, location, etc.

Feedback (continued)

Degrees of persistence for the feedback:

Low persistence. For example, a message that the printer is out of paper. The message should be removed once the problem is solved.

Medium persistence. The message stays on the screen until the user explicitly acknowledges it.

High persistence. The message remains a permanent part of the interface. An example is the indication of remaining free space on a hard disk.

Response time

Feedback is especially important in case the system has long response times for certain operations.

0.1 sec., 1 sec., and 10 sec. are psychological regarding keeping our attention on the interaction with the system.

Normally, response times should be as fast as possible, but reasonably fast.

E.g., a scrolling list may move so fast that the user cannot stop it in time.

Continuous feedback. Usually it is in the form of percent-done indicator. It should be used for operations taking more than 10 seconds.

System failure

Informative feedback should also be given in case of system failure.

Many systems nowadays simply do not respond to the user when they go wrong.

No feedback is almost the worst possible feedback since it leaves users to guess what is wrong!

Different messages should be given, depending on whether the error is due to the central system or whether the error is local.

Clearly marked exits

The system should offer the user an easy way out of as many situations as possible.

E.g., all dialog boxes and system states should have a cancel button or other escape facility to bring the user back to the previous state.

Exists can be provided in the form of UnDo facility that reverts to the previous system state.

Users quickly learn to rely on the existence of undo.

When UnDo and Escape facilities are available, users are not afraid to experiment with the interface.

Shortcuts

Dialogue shortcuts should be used to perform frequently used operations (especially for expert users).

Typical accelerators include abbreviations, function keys or command keys, double-clicking on an object, and having graphical buttons available to access important functions.

Users should be allowed to jump directly to the desired location on large information spaces, such as a file or menu hierarchy.

Shortcuts (continued)

Also, users should be able to reuse their interaction history.

Some graphical interfaces allow users to reissues the last formatting command or repeat the last search command by a simple command-key shortcut.

E.g., some applications keep track of which files users open in the application, for instance, MS Word.

System-provided default values are also a shortcut.

In many cases, users do not even need to see the default values, which can remain hidden on an optional screen.

Error messages

Error situations are critical for usability for 2 reasons:

By definition, they represent situations where the user is in trouble and potentially will unable to use the system to achieve the desired goal.

They represent opportunities for helping the user understand the system better, since the user is usually motivated to pay some attention to the contents of error messages.

Error messages: rule 1

Error messages should be phrases in clear language and avoid codes.

Users should understand them without having to refer to any manuals or code dictionaries.

Nevertheless, it might be necessary to include internal, system-oriented info or codes.

This can help system administrators track down the problem, but such info should always be given at the end of the message.


Error messages should be precise rather than vague or general.

For example, instead of saying

“Cannot open this document”

the computer should say

“Cannot open “Chapter 5.doc” becausethe application is not on the disk”


Error messages should constructively help the user to solve the problem.

For the previous example, we could replace the words “the application” with the name of the application.

One useful way of generating constructive error messages is by guessing at what the user really meant to say.

In the case of textual input, spelling-correction methods have been available for many years.

Even a simple spelling corrector could handle 27% of all user errors in a text-oriented interface.


Error messages should be polite and should not intimidate or put the blame explicitly on the user.

Error messages like the classic

“ILLEGAL USER ACTION, JOB ABORTED”

are not really useful and needed.

Error messages should also avoid using words like fatal, illegal, etc.

In addition, we should provide good error recovery. E.g., undo the effect of erroneous commands.

Error multi-level messages Instead of putting all potentially useful bits of info

in all messages, it is possible to use shorter multi-level messages.

The most common way is to have two levels and to supplement the short initial messages with a button directing to more detailed info.

Hypertext could be used to refer to corresponding chapters in the help system.

Preventing errors

Besides having good error handling procedures it is even more important to try to prevent errors.

E.g., when users are asked to spell out, there is a risk of spelling errors, so selecting a filename from a menu will eliminate the whole category of errors.

User errors are candidates for eliminating either because of their frequency or because of their serious consequences.

Errors with especially serious consequences can also be reduced in frequency by asking the user to confirm the action.

By this, one should not use confirmation dialogues too often, since the user’s answer becomes automatic.

Help and documentation

Most UIs have sufficiently many features to warrant a manual and possibly a help system.

Also, regular users of a system, may want documentation to enable them to acquire higher levels of expertise.

The existence of help and documentation does not reduce the usability requirements for the interface itself.

“It is all explained in the manual” should never be the system designer's excuse when users complain that an interface is too difficult.

Help and documentation (continued)

The fundamental truth about documentation is that most users simply do not read manuals!

User prefer spending their time on activities that make them feel productive.

If users do read the manual, then they are probably in some kind of panic and will need immediate help.

This indicates the need for good, task-oriented search and lookup tools for manuals and online documentation.

Printed manuals should be supplemented with online help and online documentation using hypertext and good search facilities.


Online help and documentation add an extra set of features to a system, thus complicating the interface.

Also, many users do not progress beyond the first one or two screens, and they mostly scan the screens for potentially useful info rather than reading long paragraphs of text.

Online help has the advantage over documentation that it can be context-sensitive.

Error messages could be linked to online help with further explanation of the error and possible solutions.


The quality of the writing, especially including the structuring of the info and the readability of the text are important.

The quality of help text is far more important than the mechanisms by which those texts are accessed.

When users do want to read the manual they often are unable to find it. The problem can be overcome by using online documentation.

Of course, users are known as removing documentation and help files when they clean up their disks, so even online documentation does not solve the problem completely.


Users go through 3 stages in interacting with manuals:

Searching: locating info relevant to a specific need.

Understanding the info.

Applying: carry out a procedure as described in the documentation.

Two main search tools are the index and the overview map of the structure of the info space (usually it is a table of contents).

The index to a printed manual should contain not only the system’s terminology but also user-oriented task terminology.


Manuals should be written in a way that corresponds to the tasks user want to do and the sequence in which they should carry out the tasks.

If a sequence of steps is given, the steps should be numbered.

The documentation should also include a variety of examples since it is often easier for users to understand examples than to understand abstract descriptions.


It should be possible to keep online help system visible in a separate window while the user returns to the application.

It might even be possible to let the user copy examples directly from the help system, to have them executed.

Three different levels of documentation:

Short reference cards and/or job aids for the expert user who wants to check a fact, and for the novice user who wants to get an overview of the system’s capabilities.

Tutorial and/or introductory manuals for learners.

Traditional reference manuals for expert users.

Heuristic evaluation

Heuristic evaluation is done by looking at an interface and trying to come up with an opinion about what is good and bad.

Ideally people would conduct such evaluations according to certain rules.

However, most people perform some kind of heuristic evaluation.

The goal of heuristic inspection is to find the usability problems in a user interface design.

Heuristic evaluation involves having a small set of evaluators examine the interface and judge its compliance with recognized usability principles.

Heuristic evaluation (continued)

Usually, there are more than one evaluators, since any single evaluator will miss most of the usability problems in an interface.

Different evaluators tend to find different problems. It is a good idea to aggregate their findings.

It is recommended to typically use 3-5 evaluators.

The exact number depends on a cost-benefit analysis.

Reference

Chapter 5 titled “Usability Heuristics” from J. Nielsen, 1993, Usability Engineering, Morgan Kaufmann.

Usability Heuristics

Technology

Transcript of Usability Heuristics