Instructions should be available where and when needed
Aliases: near-task help · contextual guidance · inline explanation · minimalist instruction
What it is
Instructions should appear where users encounter a field, state, error, or decision, not require leaving the task for a manual or remembering training. Contextual help includes placeholder examples, explanations beside fields, corrective errors, shortcut hints, and expandable detail. This sits in the same group as recognition over recall but owns a different layer: not "should the option be visible" but "should the sentence explaining the option travel with it" — a user can see every object and action and still not know how to use one of them, and what is missing there is guidance, not options.
Why it happens
The mechanism turns on a distinction between two kinds of load: intrinsic load comes from the task itself and cannot be removed by interface design; extraneous load comes from the cost of obtaining the answer, and that part is compressible. Remote documentation manufactures extraneous load — the user must first notice they are stuck, remember the exact wording of the problem, leave the current screen, search an unfamiliar document structure, then map the answer back onto the field that stumped them. Any of those five steps can fail or get abandoned, and none of them advances the task itself. Contextual help collapses the five steps into one: the answer and the question share the same visual anchor, so the mapping step disappears.
This is also why inline explanation beats a help button that merely shortens the trip: a button still asks the user to judge "should I click this," while good contextual help removes that judgment by appearing before the user has consciously registered a need for help. John Carroll's minimalist instruction theory supports this direction: people prefer to act first and consult guidance only when they hit a snag, rather than study a manual before touching anything, which is why instruction should surface at the point of failure rather than require reading a manual in full beforehand.
Studying it
A typical comparison uses three conditions — no help, remote documentation (a separate help page or manual), and contextual help placed at the point of need — measuring completion time, first-attempt correctness, help-seeking frequency, and abandonment. This line of work traces back to Carroll's minimalist-instruction experiments, whose consistent finding is that breaking instruction into small chunks inserted at error points gets novices through a task faster than a complete manual delivered up front, even though the manual is more comprehensive.
A more direct method for interface research is log analysis: find the fields where users repeatedly trigger a help icon, keep editing and still err, or return to the same field after submission. These positions form a candidate list of "the help is missing or misplaced" that beats guessing where to add guidance in advance. Think-aloud also works here — the hesitation of "what am I supposed to put here" usually marks exactly where help is absent.
A methodological caution: instructions written by the designers themselves and tested in the lab tend to look more effective than they are. A more reliable check is mining real support tickets or search logs for recurring questions and writing help content backward from that, rather than writing the help first and then confirming it works.
Where it stops holding
Nearby does not mean every explanation stays permanently visible. Too much inline text crowds the workspace, and duplicated guidance is hard to maintain; complex flows still need documentation, tutorials, and support — this principle reduces reliance on them, it does not replace them. Help must stay synced with version, permissions, and localization; an outdated example is worse than none, because a user who follows a stale instruction and fails will first suspect their own mistake rather than the guidance, which makes the error harder to diagnose.
For high-frequency expert users, persistent inline help turns into noise: someone who has filled the same field a thousand times does not need "enter the order number" sitting beside it every time, and it should collapse by default. Screen-reader users mark a separate boundary: help content must be focusable, expandable, and correctly ordered in the reading sequence — help triggered only by mouse hover is effectively absent for this group.
Applying it
- Give each field one necessary rule plus a correct/incorrect example; make error messages offer a corrective action instead of repeating the rule.
- Explain causes and next steps beside empty states, no-results states, insufficient permission, and disabled controls — these are exactly where users get stuck and abandon the task.
- Use expandable help for long explanations while preserving context and scroll position, rather than forcing a jump to another page and back.
- For expert interfaces with high-frequency repeated actions, default inline help to collapsed, expanding on hover or focus, so it does not obstruct the workspace permanently.
- How to check: audit help-click locations and recurring support-ticket topics, migrate frequent answers back into the corresponding on-screen position, and regression-test links and examples with every release.