Loading…
Loading…
Form labels identify what information is needed, while instructions explain how to provide it. Together, they eliminate ambiguity and reduce form abandonment. The placement, wording, and visibility of labels directly impact completion rates and error frequency.
stellae.design
Forms are where users exchange data with your product. Labels are the contract between the interface and the user — they define what's expected. Good form design uses visible labels, inline help text, and clear formatting guidance.
Before/after examples: • Before: 'Name' → After: 'Full name (as it appears on your ID)' • Before: 'Phone' with placeholder '555-1234' → After: 'Phone number' with helper text 'Include country code for international numbers' • Before: 'Password' → After: 'Create a password' with requirements listed below the field
Form labels and instructions are the textual elements that tell users what information a form field expects, what format it should be in, and why the information is being requested — and they are the single most impactful factor in form completion rates, because a user who does not understand what a field is asking for will either guess incorrectly, abandon the form, or contact support, all of which represent conversion failures that no amount of visual design can compensate for. Research consistently shows that clear, well-positioned form labels reduce error rates by 50% or more compared to ambiguous or missing labels, and that adding brief contextual instructions — such as why a phone number is needed or what constitutes a valid password — reduces both form abandonment and post-submission support requests. From an accessibility standpoint, properly coded form labels are not optional: they are a WCAG Level A requirement, and forms without programmatically associated labels are unusable by screen reader users, exposing organizations to both legal liability and the exclusion of millions of potential users.
GOV.UK's design system places clear labels above every field and uses hint text beneath labels to explain format requirements, provide examples, or clarify why information is being requested — the National Insurance number field shows 'It's on your National Insurance card, benefit letter, payslip or P60. For example, QQ 12 34 56 C' as persistent helper text that users can reference while typing. This pattern reduces errors dramatically because users never need to guess at formatting, and the hint text answers the 'where do I find this?' question that causes the majority of field-level abandonment for government forms. The approach has been validated through extensive usability testing across diverse literacy levels and is now considered a global benchmark for form design.
Shopify's checkout flow uses above-field labels with contextual instruction text that appears only when needed — the phone number field includes a brief note explaining 'In case we need to contact you about your order' which addresses the common user concern about why a phone number is required for an online purchase. Error messages reference the specific field label and explain exactly what needs to change, and the form pre-fills country and region fields based on shipping address data, reducing the number of decisions users need to make. This thoughtful label and instruction strategy contributes to Shopify's industry-leading checkout conversion rates.
A financial services registration form uses placeholder text as the only field identification, labels several fields with ambiguous single words — 'ID,' 'Reference,' 'Code' — that could refer to multiple types of information, and provides no instruction text explaining the required format for the account number field, which expects a specific 12-digit pattern that users have no way of knowing without trial and error. Validation errors appear in a single summary block at the top of the page with messages like 'Field 3 is invalid' that do not reference the label or location of the problematic field, forcing users to count fields to find the error. Accessibility testing reveals that four fields have no programmatic label association, making them completely unusable for screen reader users.
• The most common mistake is using placeholder text as a substitute for visible labels — it creates an immediate accessibility failure and a usability regression because the field's purpose becomes invisible the moment the user begins typing, making form review and error correction significantly harder. Another frequent error is writing labels from the system's perspective rather than the user's — 'User identifier' instead of 'Username,' 'Remittance reference' instead of 'Payment reference number' — which forces users to translate system terminology into concepts they understand. Teams also neglect to provide contextual instructions for fields where the required format is not self-evident, assuming users will intuit that a date field expects DD/MM/YYYY rather than MM/DD/YYYY, or that a phone number field requires a country code — these unstated assumptions generate the majority of form validation errors.
Was this article helpful?