Heuristics for Modern Web Application Development | January 17, 2007

Heuristic evaluation is a technique that involves analysing the usability of a website against a set of general usability precepts. One or more “experts” will analyse the target site, often following a series of pre-defined scenarios. Whenever they encounter an issue that breaks one of the precepts or “heuristics”, they will note the issue and sometimes the severity.

Heuristic evaluation is usually done either to augment usability testing, or where usability testing is impractical or cost prohibitive. Heuristic evaluation is considered slightly more objective than a simple “expert review” as the results are based upon generally agreed guidelines rather than personal opinion.

There are a number of different usability heuristics around, but the most popular ones on the web are Jakob Nielsen’s 10 usability heuristics and Bruce “Tog” Tognazzini’s basic principles for interface design.

As part of my consultancy work at Clearleft I run a lot of expert reviews and heuristic evaluations. While planning a recent evaluation, I started to feel that the existing heuristics didn’t accurately describe the requirements of a modern web application. In particular I felt that Mr Nielsens heuristics were somewhat convoluted, contained a lot of overlap and varied widely in terms of scope and specificity.

Since Mr Nielsen first created his heuristics back in 1990, the web has changed on a lot. Many of the underlying principals remain the same, but their relative weight has shifted. So using these heuristics as a starting point, I set out to create a set of web application heuristics that better reflected the current landscape.

Usability heuristics are by their nature subjective, so I don’t claim what follows is a definitive list. However I have tried hard to cover as many common usability issues as possible. There is still a lot of overlap, but I think this is because one problem can the result of multiple causes.

Anyway, this is just a first draft so I’m really keen to hear your opinions.

Design for User Expectations

Design the system around the users, their goals and expectations. Choose features and functions the audience will find useful and use the appropriate level of complexity for their experience and abilities. Make processes work in the way users expect, and mirror real-world processes where applicable. Ensure the interface always upholds its promise and never trick or mislead the user. E.g.


Make the system as clear, concise and meaningful as possible for the intended audience. Use meaningful icons, symbols and imagery. Use the natural language of the user and optimise for skim reading. E.g.

Minimize Unnecessary Complexity and Cognitive Load

Make the system as simple as possible for users to accomplish their tasks, but no simpler. Do not overload the user with too many unnecessary choices, and make sure those choices are prioritised. E.g.

Efficiency and Task Completion

Design for user productivity, not the system’s. Optimise the system for the most common tasks. Provide experienced users with advanced features that speed up task completion. Use the most common defaults and honour user preferences and previous selections. However, allow them to be easily overridden when necessary E.g.

Provide Users with Context

Interfaces should provide users with a sense of context in time and space. The system should let users know where they are, where they have come from, what they can do and where they can go next. Processes should inform users of the progress they have made and the remaining duration. E.g.

Consistency and Standards

Labels, processes and interface elements should be used consistently throughout the system. The system should use common web conventions unless a new convention provides a significantly improved user experience. E.g.

Prevent Errors

The system should help prevent errors wherever possible. This can be done by limiting incorrect choices, accepting alternative input formats, providing guidance and inline validation where applicable. E.g

Help users notice, understand and recover from errors

Errors should be obvious and easy to recover from. Error messages should be clear, concise and easy to notice. They should succinctly explain what has happened and suggest possible solutions. E.g.

Promote a pleasurable and positive user experience

The users interaction with the system should be positive and where possible enhance their quality of life. The user should be treated with respect and their preferences and wishes honoured. The design should be aesthetically pleasing and promote a pleasurable and rewarding experience. E.g.

Posted at January 17, 2007 5:03 PM


Achtentachtig said on January 17, 2007 5:43 PM

Good post!

Arnold M. Lund also made a good list of ‘rules’, a bit like this.

Gene said on January 17, 2007 9:00 PM

Nice work. I wonder if you’ve seen this article on heuristics for RIAs (http://www.boxesandarrows.com/view/usability_heuristics_for_rich_internet_applications)

It’s a little dated, and focuses on Flash, but it covers some similar territory.

Sohail Mirza said on January 17, 2007 11:20 PM

Andy, the link to Bruce Tognazzini’s basic principles for interface design is a duplicate of the link to Jakob Nielsen’s 10 usability heuristics.

I hope you can post the correct link to Tog’s basic principles as I’d like to take a look!

Thanks! :)

Wilco said on January 18, 2007 11:12 AM

Good post Andy. I’d like to point out though that Don’t use misleading labels or buttons is quite simular to “Write clear and meaningful labels” and “Use meaningful icons”.

What I don’t see her is informing the user why they should do something, like; Why to fill in more details about yourself in a form? People won’t put ni the extra effort if you don’t tell them how they would benefit.

Harry said on January 18, 2007 6:24 PM

Good stuff. It would be good to have it side by side the classic heuristics (nielsens or whatever) to show how you are actually ‘moving forward’ (expanding, condensing, whatever). In the past I’ve seen people (particularly academics) rebrand concepts without a really good reason, apart from to establish ‘ownership’ and have something to publish. There is a risk that people will glance at this and think “oh, it’s just a rehash of Nielsen’s”. I guess what you’d want people to say instead is “Actually, that is a lot more practical to use in today’s world.. I’m going to start using it from now on…”

Michael James said on January 18, 2007 6:54 PM

A good post, and actually apllicable and practical to the type of work I do. I’m going to suggest we make use of this at our work.

Kelvin71 said on January 27, 2007 7:51 AM

Very cheap drugs:
http://onlinepharmacyopen.info/product_lexapro.htm lexapro [url=http://onlinepharmacyopen.info/product_lexapro.htm]lexapro[/url]
http://onlinepharmacyopen.info/product_hoodia_patch.htm hoodia patch [url=http://onlinepharmacyopen.info/product_hoodia_patch.htm]hoodia patch[/url]
http://onlinepharmacy24.info/product_cialis.htm cialis [url=http://onlinepharmacy24.info/product_cialis.htm]cialis[/url]