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

1. Can users get help without navigating away from their task?
2. Is help written in plain language that matches the interface?
3. Can users reach a human within 2 clicks when self-service fails?
4. Do help resources exist for the moments where users actually get stuck (not just the moments you anticipated)?