Contextual Help Design
Design help that meets people where they are — on the screen they're stuck on, in language they understand, without requiring them to remember how they got there.
Core Principle
If a user gets stuck, they should be able to get help without leaving the screen they're on.
Design Patterns
Inline Help
- Tooltip or info icon next to fields that need explanation
- Examples shown next to input fields ("e.g., 15/03/2026")
- Help text visible by default for complex fields
- Inline definitions for specialist terms (underline + tooltip)
- "What's this?" links for uncommon concepts
Guided Tasks
- Step-by-step wizard as an alternative to complex forms
- Examples of completed tasks (filled-in sample forms)
- Templates or pre-built options alongside "start from scratch"
- Progress-aware hints that change based on where the user is
Escalation Path
- Self-service help (search, FAQ) as first option
- Chat or messaging as second option
- Phone or video as third option
- Never require users to re-explain when escalating between channels
- Show estimated wait times for human support
- Never require a reference number to get help
Error Recovery Support
- Error messages include: what happened + why + what to do next
- Link directly to the field or step that needs fixing
- Offer alternative paths when primary fails
- For complex errors: offer human support directly
Help Content Rules
- Write at grade 4–6 reading level
- Use the same terminology as the interface (not different words)
- One instruction per step
- Include images or diagrams for spatial or procedural instructions
- Make help searchable
- Test help content with people who have the actual problem
Assessment Questions
- Can users get help without navigating away from their task?
- Is help written in plain language that matches the interface?
- Can users reach a human within 2 clicks when self-service fails?
- Do help resources exist for the moments where users actually get stuck (not just the moments you anticipated)?