Heuristic analyses

Ariel photo of 100 Euro notes randomly scattered
Cost efficient way to get early feedback

When developing a new application or user interface, get quick usability feedback as early as possible in the development cycle. A cheap and efficient way to do this is through Heuristic evaluation.

Heuristic analysis was developed by Jakob Nielsen and Rolf Molich in 1990 and refined by Nielsen in 1994. In a web context, heuristics can be defined as a set of common sense usability rules of thumb that will increase the probability of your new application or user interface being user friendly. The earlier you do this in the development lifecycle, the cheaper it is to resolve common usability issues.

Whilst at AXA, I developed an internal employee contact directory. As this was a business critical application it was important to get the user interface right. The early results from the heuristic evaluation saved a lot of time and money when the final version was delivered.

The heuristics I checked against were:

Consistency
Recognition
Action status
System speed
Emergency exit
Little is more
Prevention better than cure
Helpful error messages

 

Consistency

  • The terms used were consistent with those used in other parts of the company, for example, names of departments and building abbreviations
  • The branding was the same as other web applications so the user instantly recognised it as a company application
  • Information architecture was then same as the intranet so the user does not have to learn yet another application
  • Make sure the actions mean the same thing and conventions users are used to are followed
  • Where you can’t be consistent (for example the directory enquires functionality), let the user know this beforehand

Remember, the most important consistency is consistency with user expectations.

Back to top

 

Recognition rather than recall

  • The user already has a lot on their minds when using the web. Therefore help them by making their options visible in a simple and clear way. Don’t make them think of the next step!
  • Make the instructions easy to read and clearly set out. For example, in the quick search section, the instructions for why they might want to try the advanced search was clearly explained and laid out

Back to top

 

Action status

  • If the application needs time to think (why is another question!), let the user know this. I used a simple indicator where more that 50 milliseconds were needed to display the result
  • Use roll-overs to acknowledge that a button has been clicked

Back to top

 

System speed

  • My instructions to the technical guys were to make sure that the user is not aware of all the actions taking place in the background. Hide all the multi-tasking and computation and organise it so that the results are within 50 milliseconds. If it takes more, let the user know!
  • Don’t let the users press the same button repeatedly - trap multiple clicks of the same button as otherwise the system will slow down
  • Above all, make it faster!

Back to top

 

Emergency exit

  • Let the user be in control at all times by making sure they control the navigation. Let them exit when they want to
  • Provide an emergency exit so that they can start again. Cyberspace is a scary place if you are lost!

Back to top

 

Little is more

  • Keep the design simple and clean
  • Keep the information to a minimum, as it will compete with other more important information on the page. Don’t cloud the page!
  • However, for important actions, use Fitts’ Law. This is an ergonomic model of human movement which states that “a function of the distance to the target and the size of the target”. Put it simply, use bigger buttons for important actions

Back to top

 

Prevention better than cure

  • Prevent errors by careful design and anticipation of the user journey
  • If a particular process is error prone, either re-think its use or present the user with a confirmation before they commit to the action

Back to top

 

Helpful error messages

  • Errors cannot be prevented. Therefore, give users the error message in simple language – no Information Technology jargon or code
  • Guide users to correct the error and suggest solutions
  • Have a help point if they are really stuck

Back to top

This page was last updated on Tuesday, 10th August 2010.