Design
Form Design:
The Interface Nobody Thinks About
Forms are where users do the work. They enter addresses, configure settings, submit payments, create accounts. The quality of a form determines whether the user completes the task or abandons it — and form design is routinely underinvested relative to the outsized impact it has on conversion, support volume, and user trust.
Forms Are Conversations
The best mental model for form design is a conversation, not a questionnaire. A questionnaire asks all its questions at once, in the designer's preferred order, and waits for the user to be done. A conversation is responsive — it asks the next question based on what it just heard, provides context when something is unclear, and acknowledges input before asking for more.
This reframe changes how you think about question order, conditional fields, validation timing, and error messages. Each of these is an element of the conversation's quality. A form that asks for your billing address before knowing whether you're using a saved payment method is a conversation that isn't listening.
Labels, Placeholders, and Help Text
What Most Forms Do
Use placeholder text as a label substitute. The placeholder disappears as soon as the user starts typing, leaving the field unlabeled. Users must re-read the placeholder by clearing what they typed, or simply remember what was asked. This is a universal pattern that is universally wrong.
What Works
Persistent labels positioned above the input field. Placeholder text used only for format examples, not field names. Help text appearing below the field for anything that needs explanation: expected format, why this information is needed, what constitutes a valid input.
Floating labels — labels that start as placeholder text and animate up when the field is focused — address the disappearing placeholder problem but introduce complexity on mobile, in autofill scenarios, and for users with motion sensitivity. The engineering cost of floating labels buys marginal visual polish at the expense of robustness. Persistent top labels are more boring and strictly better.
Validation: When and How
Validate on blur, not on every keystroke
Showing an error while the user is still typing (inline validation on keyup) is one of the most common form UX mistakes. For an email field, the user's input will be invalid until they've typed the @ sign — showing an error before then is both premature and anxiety-inducing. Validate on blur (when the user leaves the field) for most fields.
Never clear a field to show an error
If the user's input is invalid, show the error alongside what they typed — don't clear the field. Clearing on error means the user must re-enter information from memory. This is an infuriating pattern most common in password fields, and it should be treated as a critical UX defect.
Error messages must be actionable
"Invalid input" is not an error message. "Phone number must be 10 digits" is. An error message has one job: tell the user exactly what to change to make the input valid. If the system knows what's wrong (too short, wrong format, already in use), say it explicitly. The user should not have to guess.
Show errors inline, summarize on submit
Inline validation catches errors at the field level as the user moves through the form. On submit, if errors remain, show a summary at the top of the form and scroll to it — users who submit and see nothing happen often don't realize there are errors below the fold.
The Questions You Shouldn't Ask
Every additional field has a completion cost. Studies consistently show form completion rates drop as field count increases — not linearly, but more steeply than most designers account for. The question to ask before adding any field is not "would it be nice to have this?" but "what is the minimum information required to complete this task?"
- Don't ask for a username on signup if email will serve as the identifier. Usernames create collision problems, require moderation, and add friction for no functional benefit in most apps.
- Don't ask for phone number unless you'll actually call or text. Collecting contact information "just in case" is a privacy anti-pattern that users have learned to resent.
- Don't ask to confirm email and password unless the field is hidden. If the field is visible and users can see what they typed, confirmation adds friction without preventing errors. Only confirm hidden fields.
- Don't split a single piece of information into multiple fields unless input or processing genuinely requires it. First name / Last name, Country code / Phone number, Card number broken into four groups — the user experiences these as unnecessary work.