Usability heuristics explained

— Published January 18th, 2004  |  by John Wood   |  2 Comments

Heuristic evaluation is one of the most common ways of identifying usability problems on your website.

It involves checking a site against a set of good practice guidelines called heuristics, the most commonly used set of heuristics being those published by Jakob Nielsen.

While this technique is quick and easy to learn, it can be hard to relate abstract guidelines to real site features. This skill comes with practice, but to get up and running here is some guidance on interpreting the Nielsen's guidelines, based on how we teach this technique at iQ Content.

1) Visibility of system status

As Nielsen explains, this means that the site should let users know what is going on using 'appropriate feedback within reasonable time.' This guideline largely relates to those occasions when a site must take control from the user to perform some process, for example validating credit card details.

If a process forces users to wait, timely feedback is important. Appropriate feedback appears when and where it is needed, like a warning beside a button that will start a long process. Appropriate feedback is also informative (like a progress bar rather than an endlessly spinning hour glass) and unobtrusive, like well written link text rather than a pop up message box that warns you of something you would like to have known before you followed the link.

2) Match between your site and the real world

At first glance, this guideline seems easy to understand and implement. However, this is the guideline we see broken most often because most sites are still designed with an inadequate understanding of their audience. This vacuum is filled by self-referential design - designing the site to suit its designers rather than its real audience.

When applying this heuristic, take the time to understand who the audience is and what would seem familiar to them. A site full of medical jargon is fine if it's designed for doctors. And this applies to more than just the language a site uses. The organisation of the content and site navigation may reflect concepts familiar to the organisation that owns the site, but will they make sense to a the audience?

3) User control and freedom

This guideline is closely related to Visibility of system status, above, as they both concern providing the user with the information and options that ensure the user remains in control. In this guideline, however, the focus is on navigation and way finding on the site.

You can test for compliance with this guideline if you can answer these three questions quickly each time you click a link on the site: - Where am I? - How did I get here? - How do I get back to where I came from?

A user who can answer these questions quickly and with confidence will feel in control. Incidentally, breadcrumb trail navigation links work because this one feature answers all three of these questions at a glance.

4) Consistency and standards

As Jakob Nielsen is fond of pointing out, people spend most of their time on somebody else's website, not on yours. As a result, if you use unconventional features on your site people are unlikely to waste time learning how your site works and will go elsewhere.

The advantages of consistency apply within sites as well as between sites. If page layouts, presentation and navigation are radically different between one part of the site and another you are making unnecessary work for your users. Proceed with caution, though, as it's easy to become over zealous in applying this guideline. Using different colours for links may not be a problem for most users, whereas making links indistinguishable from the surrounding text unless it is moused over probably is.

5) Error prevention

This is another guideline that seems simple at first glance but causes endless trouble in practice. It is a particular problem to watch out for in forms and multi-step procedures, such as booking services online. Most often, the site design forces some unexamined assumption on users that does not match their needs and leads them to enter reasonable data that the site won't accept.

For example, retail sites that make postcode information mandatory: outside Dublin, no one in Ireland has a postcode, but most sites force you to enter something in this field or you will be told you have made an error in completing the form.

6) Recognition rather than recall

This guideline is all about understanding a task from the user's point of view, and is one to watch out for in forms and multi-step procedures. To find problems relating to this heuristic, put yourself in the user position and try to perform a typical task on the site.

Typical probelms would be a hotel booking process that doesn't allow you to view a map of the hotel's location in the same place as the listing, forcing you to go back a page for that option. Or a form that requires you to re-enter a term that you already entered elsewhere, and now can't remember exactly. If everything you need to complete a task to your satisfaction doesn't fall into place as you go, then this guideline has probably been broken.

7) Flexibility and efficiency of use

Nielsen's heuristics were originally written for desktop software rather than the Web and don't always seem to apply to the Web. For example, this guideline advises us to provide shortcuts for expert users, but on the Web infrequent visits may make every user of a site a perpetual novice. But the Web is now used to deliver powerful software services, like Google, and browser-based interfaces are being used on many software systems, so this guideline can now be usefully applied to many sites.

The key to applying this is again, understanding user behaviour - especially with regard to frequency of use. Everyone is a novice user at first, but unless a site is infrequently used a person will quickly gain competence. So look for features that serve more competent users where such a user population is likely to exist.

8) Aesthetic and minimalist design

Of all Nielsen's heuristics, this is the one viewed with most suspicion. Many take it to mean that usable sites must look like Nielsen's site - sparse and utilitarian. What this guideline is actually saying is that your site should look good and that the elements of the design should be no more nor less conspicuous than is required. Google is a superb example of these principles, it looks great and every element of the design serves a purpose and integrates into an elegant whole.

When assessing sites against this guideline you need to look at the whole design as well as the elements. Consider what each element adds to the design and how it works with every other element.

9) Help users recognize and recover from errors

Use plain language and, most importantly, suggest a solution

Even if we created a perfect design, there are many things on the web that are out of our control. Broken links and unreachable servers mean that the '404 file not found' error is frequently seen. Failing to fill in required fields in web forms is probably the next most common source of errors on sites.

This heuristic is about how you help the user recover from the problem. A custom 404 error page that suggests what action you should take to locate the unreachable file is better than the stock page that ships with the server. Similarly, telling the user that they haven't completed all required information isn't good enough. Tell them which piece is missing and why they need to supply it.

10) Help and documentation

Good documentation is no remedy for bad design, and few websites should be so complex that they need a manual. But this heuristic is still relevant on the Web. Web applications like search engines or auction sites can get complex enough to need reference materials and instructions. And even an otherwise straightforward site may include advanced search functionality or a complex set of forms.

Where it is needed, help and documentation should be clear, concise, and designed to answer the specific questions people will have in a specific context. If you have a function that may need an explanation, allow people to access the explanation in the same place they access the function.