Help and documentation

A product should ideally be usable without help, but when people need it, help should be easy to find, focused on their task and written as concrete steps.

Last reviewed

On this page

The law

A product should ideally be usable without help, but when people need it, help should be easy to find and focused on their task.

Good help is written as concrete steps, answers the question people have at that moment, and is available where they get stuck. It is a supplement to a clear design, never a replacement for one.

Where it comes from

This is the tenth of Jakob Nielsen's ten usability heuristics, published in their current form in 1994. Nielsen Norman Group's article on Help and Documentation distinguishes proactive help, such as onboarding hints, from reactive help, such as documentation and support content people look up when stuck.

Research on how people learn software, notably John Carroll's work on minimalist documentation in the 1980s and 1990s, showed that people rarely read manuals from the start and learn best from short, task-focused help they can act on straight away.

What it means for an interface

  • Put help where the problem is. Short hints next to complex fields, and links to the relevant article from the screen where people get stuck, beat a separate help centre alone.
  • Write help around tasks. People search for what they want to do, such as "export to PDF", not for the name of a menu.
  • Use steps. Numbered, concrete instructions people can follow while looking at the product.
  • Make help searchable. A help centre search that understands people's words, including typos and synonyms, is used far more than a browsable tree.

Examples

Contextual tooltips. A tax form that explains a confusing field in a small help link next to it answers the question at the moment it arises.

Task-based articles. A help article titled "How to invite a teammate" with four steps and screenshots is more useful than one titled "User management overview".

Search in help. A help widget that suggests articles based on the current page saves people from describing a problem they may not have words for.

Where it is misapplied

  • Help as a crutch. Writing documentation for a confusing interface instead of fixing the interface leaves most people stuck, since most never read it.
  • Upfront tours. Long onboarding tours are skipped and forgotten. Help works better at the moment of need.
  • Outdated documentation. Help that describes an old version of the interface is worse than none.
  • Help hidden away. A help link buried in a footer is not found by the people who need it.

Checklist

  • The main tasks can be completed without opening any help.
  • Complex fields and screens offer short help in context.
  • Help articles are named and organized around tasks.
  • Help content is searchable and tolerant of people's own words.
  • Documentation is reviewed whenever the interface it describes changes.

Sources

  1. Nielsen Norman Group. Help and Documentation (Usability Heuristic #10).
  2. Nielsen, J. (1994). Enhancing the explanatory power of usability heuristics. Proceedings of CHI '94, 152–158. ACM.