Tuesday, 10 August 2021

Jakob Nielsen's 10 Heuristics

  1. Visibility of system status: the system should always keep the user informed of what is going on within a reasonable amount of time using progress indicators or busy signals.
    • if an action will take less then 100 milliseconds it's instantaneous 
    • if an action takes a second it's noticeable but acceptable
    • if an action takes less then 10 seconds it requires a notification that something is happening
    • if an action takes more then 10 seconds it should be done in the background, with indicators and estimates
  2. Match between system and the real world: the system should leverage real world language that is familiar to the user rather the system jargon. follow real world paradigms making information appear in a natural and logical order.
    • Takes advantage or users schema
    • Align real world actions with digital ones
    • processes should just make sense.
  3. User control and freedom: Users often choose system functions by mistake and will need a clearly marked "Emergency Exit" to leave the unwanted state without having to got through an extended dialogue. Support undo and redo.
    • Support 7 stages of action, perhaps user wants to try approach again but with deviation.
    • Users employ trial and error approach to figure out how to use new system.
  4. Consistency & Standards: users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions
    • helps users transfer schema knowledge from one part of the system to another.
    • coherent conceptual modal helps user learn system effectively.
    • use the same term in the same what through system, don't use search and then find
    • by staying consistent you help users more rapidly learn new systems by following paradigms they're already familiar with.
  5. Error prevention: Even better the good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present the user with a confirmation option before they commit to the action.
    • in-process feedback, give the user feedback before they submit, ie invalid email
    • provide constraints, keep user from making mistakes by asking for input very specifically.
    • confirm if the user is trying to accomplish something dangerous like delete all files
    • prevent users from actions that are likely to fail
  6. Recognition over recall: Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
    • try to use recognition over recall
    • is it reasonable for users to have to recall something
    • if recall fails are there cues to help 
  7. Flexibility and efficiency of use: Accelerators, unseen by the novice user may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow to tailor frequent actions.
    • recall for new or inexperienced users is very difficult whereas recall for veteran users is not a problem and both types of user need to be catered to.
    • allow users to customize their experience but don't force them to
    • accelerators are things like keyboard short cuts
    • allow users to create bookmarks and shortcuts
    • personalization tailors experiences based on past usage
  8. Aesthetic and minimalist design: dialogs should not contain information that is not relevant or is rarely needed. every extra unit of information in a dialog competes with the relevant units of information and diminishes their relative visibility.
    • Visual clutter makes it difficult to focus on important actions
    • good use of color, share, animation and gestalt principles guide the eye
    • the more there is to look at the less the user will see.
  9. Help users recognize, diagnose and resolve errors: error messages should be expressed in plain language (no codes), precisly indicate the problem, and constructivly suggest a solution.
    • good error messages will explain what the user did wrong and how to fix it.
  10. Help and documentation: Event though it's better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out and not be too large.
    • sometimes the UI just isn't intuitive enough
    • best if help is not needed
    • if required make sure that
      • help is searchable 
      • task-focused
      • concrete 

these 10 rules of thumb are in place to help design a system that is a pleasure to use