Usability Heuristics
Help and Documentation
Even a self-evident interface should offer help that's easy to find and focused on the task.
Where it comes from
It's the tenth and last of Jakob Nielsen's ten usability heuristics. Ideally a system is self-evident and needs no documentation — but in reality some help is sometimes necessary, and when it is, it should be easy to find and genuinely useful.
Why it matters for your website
Even well-designed systems sometimes need explaining. Nielsen Norman Group's tenth heuristic says help should be easy to find, tied to the user's actual task, and concrete enough to act on — a trusted companion, not a last resort.
The bar for help is that it actually helps. It should be easy to find, tied to the user's real task, and concrete enough to act on — not a sprawling manual the user has to search, but focused guidance at the point of need.
Crucially, this comes after the other nine heuristics, not instead of them. Good documentation is a companion to a well-designed interface, not a patch for a confusing one — if users constantly need the help, the real problem is upstream, in the design that made it necessary.
Wrong vs right
A sprawling help centre disconnected from the task, that users have to search and interpret themselves.
Focused, findable help tied to the user's actual task, concrete enough to act on.
Using documentation to paper over a confusing interface rather than fixing the design.
A self-evident interface first, with help as a companion for the genuinely tricky moments.
Help that's buried, generic, or so abstract the user can't act on it.
Help that's easy to find, specific to the task, and immediately actionable.
Understanding Help and Documentation
Help and documentation is the tenth and final of Jakob Nielsen's ten usability heuristics. The ideal it points to is a system so self-evident it needs no documentation at all — but Nielsen acknowledges reality: sometimes help is necessary, and when it is, it should be easy to find, tied to the user's actual task, and concrete enough to act on.
The quality bar is that help should genuinely help. Rather than a sprawling manual users must search and interpret, it should be focused guidance available at the point of need, listing concrete steps toward the user's real goal. Help that's hard to find, generic, or too abstract to act on fails the heuristic even when it technically exists.
Its position as the last heuristic is meaningful. Good documentation is a companion to a well-designed interface, not a substitute for one — if users constantly need help, the real fix is upstream, in the design that made it necessary. It connects to the paradox of the active user (who won't read it unless it's in context), progressive onboarding, and microcopy.
How Kweri checks it
Kweri can note whether help is available, findable, and tied to tasks, and flag cases where it's absent, buried, or disconnected from what the user is doing. What it can't fully judge is whether the help content is genuinely useful and actionable for your users, or whether frequent need for help points to deeper design problems — both of which depend on real usage. So Kweri surfaces missing or hard-to-find help and prompts you to make it task-focused and actionable, while whether users actually find it useful is confirmed by testing.
FAQ
What is the help and documentation heuristic?
It's the tenth of Jakob Nielsen's usability heuristics: even a well-designed system may need help, and when it does, the help should be easy to find, tied to the user's actual task, and concrete enough to act on.
Should a good interface need help documentation?
Ideally a system is self-evident enough to need no documentation. But in reality some help is sometimes necessary. The heuristic says when help is needed, it should be findable, task-focused, and actionable — a companion, not a crutch for bad design.
What makes help and documentation effective?
It's easy to find, tied to the user's real task, and concrete enough to act on — focused guidance at the point of need rather than a sprawling manual to search. Help that's buried, generic, or too abstract to use fails even if it exists.
Why is help the last of the ten heuristics?
Because it's a companion to good design, not a substitute. The other nine make the interface usable; help supports the genuinely tricky moments. If users constantly need help, the real problem is upstream in the design.
How should help be delivered?
At the point of need, tied to the task, and actionable. Because users tend not to read documentation out of context (the paradox of the active user), the most effective help is contextual — surfaced where and when it's relevant.
Related principles
Users never read instructions — they start immediately and muddle through, even when reading would save them time overall.
Good design externalises the knowledge users need to act — it puts it in the world, not in their heads. A product that requires memorisation is a product that requires training.
Teach a product in context, a step at a time, rather than front-loading a tour nobody remembers.
Attribution & sources
Identified by Jakob Nielsen (1994). Catalogued from Nielsen Norman Group — Help and Documentation.
The tenth of Nielsen's 10 Usability Heuristics; the linked article is the reference used here.
See Help and Documentation on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →