Help entry points should sit near where the problem occurs

What it is

A contextual help entry should appear beside a field, error, empty state, permission notice, or complex decision, and it should preload the current object, role, version, and error context. A global help center is still a necessary foundation, but users should not be required to leave the failure scene and redescribe the problem from scratch. This card divides the work cleanly from the other two in the group: those two decide whether documentation exists and how it is organized; this one decides where the door opens when a user is standing right in front of the problem, and how much information that door already carries so the user does not have to repeat it.

Why it happens

When help is opened from a specific point in the interface, the system already holds much of what diagnosis needs: which page the user is on, which object is selected, what the error text says, and the current account's role and permissions. If those parameters flow automatically into the help entry, a long document that would otherwise apply broadly collapses down to just the section relevant to this exact scenario — the user sees not an overview article titled "invoice management" but the one paragraph that explains the specific permission error they are looking at right now. A global help entry detached from the problem, by contrast, forces the user through three translations: turning what they see on screen into a verbal description, turning that description into search terms, and then mapping a generic answer back onto their specific situation. An error in any one of those three translations can leave a user confidently applying an answer that does not actually fit their case. A nearby entry point removes all three translations, and as a side effect lowers the odds that the user gives up midway and goes back to blindly experimenting with the interface instead.

Where it stops holding

More entry points is not automatically better — too much density becomes its own visual noise, making the interface look like it is flagging a problem everywhere at once. Low-risk, easily understood fields are better served by a hover tip or a collapsible note, keeping help restrained; an explicit, persistently visible help link is worth its screen space only for high-consequence errors and genuinely complex decision points — a judgment that should be made by risk tier, not applied uniformly. Security and privacy contexts can restrict automatically passing full context to a help system or third-party support tool — a field value containing personal data should not ride along unmasked in a support link, and such cases need masking first, carrying over only enough to identify the problem type. Small mobile screens, a screen reader's linear reading order, and a help panel embedded inside a third-party system each need separate verification of whether the entry is reachable and whether the user can return to their original task afterward; a common failure in these environments is a help panel that opens and covers the original form, leaving the user with no way back.

Applying it

• Configure a help link for error messages, empty states, insufficient-permission notices, and high-complexity fields, each automatically carrying the current object, version, and error code as context parameters.
• When help content opens, clearly highlight which version and role it applies to, so users are not reading steps meant for a different account; preserve previously entered content and scroll position when returning to the original interface.
• Link directly from an error message to its corresponding solution, and offer a one-click path to create a support request that automatically attaches masked diagnostic information.
• How to check: verify the help entry is discoverable and usable under keyboard navigation, touch input, page zoom, and weak network conditions, and confirm returning to the task keeps all prior input intact — losing content under any one of the four conditions counts as a failure.

Related

• Same group: B3.10.1 The interface should ideally work without documentation · B3.10.2 Documentation should be searchable and task-oriented
• Nearby: B3.06 Recognition over Recall · B3.09 Error Recognition, Diagnosis, and Recovery
• Search terms: contextual help entry · help link · support context · deflection