Loading…
Loading…
Help text is supplementary information that clarifies interface elements, explains requirements, or provides additional context. It appears as inline text near form fields, tooltips on hover, expandable FAQ sections, or contextual hints within workflows. Effective help text anticipates confusion and resolves it in place.
stellae.design
Help text bridges the gap between what an interface shows and what users need to understand. It includes inline descriptions below form fields, info-icon tooltips, onboarding callouts, and contextual sidebars. The best help text is invisible until needed.
Before/after examples: • Before: (no help) → After: Below API key field: 'Keep this secret. Never share it in client-side code.' • Before: Tooltip: 'Info' → After: Tooltip: 'Your display name is visible to other workspace members' • Before: 'See documentation' → After: Expandable 'What is a webhook?' with a 2-sentence explanation inline
Help text is the supplementary instructional copy that appears alongside form fields, interface controls, and interactive elements to explain what information is needed, what format is expected, or why the system is asking for something — and its quality directly impacts form completion rates, error rates, and user confidence because help text addresses uncertainty at the precise moment and location where it arises. Without effective help text, users must guess what a field label means, attempt a submission to discover format requirements through error messages, or abandon the task entirely to search documentation for guidance — all of which represent unnecessary friction that well-placed, well-written help text eliminates. Products that invest in clear, contextual help text see measurably lower form abandonment rates, fewer support tickets, and higher data quality, because users who understand what is being asked provide accurate information on the first attempt rather than cycling through errors.
Stripe's payment and account setup forms include persistent, concise help text beneath fields that commonly cause confusion — 'This is the name on your bank statement, not your business name' beneath the statement descriptor field, and 'We'll use this to verify your identity' beneath sensitive fields — addressing the specific uncertainty each field creates rather than restating the label. The help text is styled in a muted color and smaller font size that is clearly subordinate to the field label and input, maintaining visual hierarchy while ensuring the guidance is visible without interaction. This approach significantly reduces form errors and support tickets because users understand both what to enter and why it is being requested before they begin typing.
GOV.UK's design system specifies help text patterns for common government form fields — 'For example, QQ 12 34 56 C' for National Insurance numbers, 'This is on your passport or driving licence' for identity questions — providing format examples and source hints that ground abstract questions in concrete, familiar references the user can act on immediately. The help text is based on extensive usability testing with citizens across literacy levels, and each pattern has been validated to reduce errors for that specific field type. This research-driven approach to help text demonstrates that investing in understanding what users actually find confusing about each field produces dramatically more effective guidance than generic 'required field' annotations.
A corporate expense management system presents a form with field labels like 'GL Code,' 'Cost Center Allocation,' and 'Requisition Authorization Level' with no help text, no format examples, and no explanation of where users should find this information — assuming that everyone who uses the system understands the company's accounting terminology and code structure. New employees consistently enter incorrect values, triggering opaque validation errors like 'Invalid GL Code format' that still do not explain what a valid format looks like, creating a cycle of guess-and-check that turns a five-minute expense submission into a thirty-minute ordeal requiring a call to the finance department. Adding a single line of help text to each field — 'Your GL code is a 6-digit number from the chart of accounts, e.g., 401200' — would eliminate the majority of these errors and the support burden they create.
• The most common mistake is writing help text that merely rephrases the field label — 'Enter your email address' beneath an 'Email' label adds zero information and wastes space that could be used for genuinely useful guidance like 'We'll send your receipt here' or 'Use your work email for team features.' Another frequent error is hiding all help text behind tooltip icons that require hover or click to reveal, which means most users never see the guidance and only discover they needed it after making an error — persistent help text visible by default is more effective for fields where users commonly struggle, with tooltips reserved for optional supplementary context. Teams also neglect to coordinate help text with validation messages, so users see help text that says 'Enter a password' and then an error that says 'Must contain at least 8 characters, one uppercase letter, and one number' — the format requirements should have been in the help text from the beginning so users can get it right on the first attempt.
Was this article helpful?