Labels and placeholders
Forms are where users give you data, and often where they quit. Most problems come from a few basic choices, and the first is how fields are labeled.
Put a visible label above each field. Labels above the field are easy to scan, work on narrow screens and leave room for long text. Labels beside fields can work in dense admin screens but take more care.
Do not use placeholders as labels. It looks tidy, but the text disappears when the user starts typing, so they cannot check what the field was for. Placeholder text also has low contrast in many designs, and some screen readers treat it differently from a real label. Use a real label. If you use a placeholder, make it an example, such as "[email protected]", not an instruction.
Some more label rules:
- Use short, plain labels. "Work email" beats "Please enter your work email address".
- Mark optional fields as "optional" instead of marking required ones with an asterisk. Most fields should be required anyway. If most are optional, ask why they are there.
- Put short help text under the field when the format is not obvious, so the user sees it before they make a mistake. "Use 8 or more characters" beats an error shown afterwards.
- Make the label clickable, so tapping it focuses the field. That is what a proper
labelelement gives you.
Field order and grouping
A form should read like a conversation. Start with what the user knows easily and end with what takes more thought.
- Use one column. Single-column forms are usually easier to complete than multi-column ones, because the eye moves in one line. Put fields side by side only when they belong together, like first and last name, or city and postcode.
- Group related fields under a short heading, such as "Billing address" or "Team settings".
- Ask for easy things first. Name and email before company details.
- Match the user's order of thought, not your database's.
- Cut fields. Every field costs attention. For each one, ask: what do we do with this, and do we need it now? If the answer is "we might use it later", remove it.
- Make the main button clear. One primary action, labeled with a verb for what happens: "Create workspace", not "Submit".
- Put the secondary action quietly. A "Cancel" link should not look as strong as "Save".
When to validate
Validation means checking the input. When you do it matters as much as what you check.
| Timing | Good for | Problem |
|---|---|---|
| While typing | Password strength, character counts, available usernames | Showing errors before the user has finished is rude and noisy. "Invalid email" after one letter helps nobody. |
| When leaving the field | Most fields: email format, required, number ranges | Fine for most. The user gets feedback while the context is fresh. |
| On submit | Whole-form checks, server-side rules | If this is the only moment, users get a wall of errors at the end. |
Our default is to validate when the user leaves a field, and to re-check as they fix it. Once a field shows an error, remove the error as soon as the input becomes valid, without waiting for another blur.
Also remember that validation on the server is not optional. Browser checks help users, but the server must check everything again.
Do not block people for things you can accept and fix. Accept phone numbers with spaces or dashes and clean them up in code. Accept emails with capital letters. Let people paste. Do not force a format on someone when the computer can handle it.
Writing error messages
Error messages are the most useful text in a form. Most are poor: "Invalid input", "Error", "Something went wrong".
A good message does three things. It says what is wrong, it says how to fix it, and it does so without blaming the user.
| Weak | Better |
|---|---|
| Invalid email | Enter an email like [email protected] |
| Password error | Use at least 8 characters |
| Required field | Enter your company name |
| Error 422 | We could not save your changes. Check the fields marked in red and try again. |
| Wrong date | Choose a date that is today or later |
Place the message next to the field, not only at the top of the page. If there are several errors, also show a short summary at the top that links to each field, and move focus to it so screen reader users hear about it.
Do not rely on color alone. A red border with no text is invisible to many people. Add an icon and words. And keep the user's input: never clear a form because one field failed.
Long forms and saving progress
Some forms are long by nature: tax details, a detailed profile, a bulk settings page. You cannot always shorten them, but you can make them easier.
- Split into steps when the form has clear sections. Show where the user is and how much is left. Do not split just to make it look short, since it adds clicks.
- Save as you go. If someone leaves halfway, bring them back to where they were. Autosave drafts for anything that takes more than a minute or two.
- Let people go back without losing what they entered.
- Allow skipping. If a section can be finished later, say so and let them.
- Offer a review step for high-stakes forms, with edit links on each section, before the final submit.
- Warn before losing data. If the user navigates away with unsaved changes, ask first.
- Prefill what you know. If you already have the user's name or company, do not ask again.
Also think about what happens on a slow connection or a session timeout. A long form that loses everything on an expired session is a very bad experience.
Mobile input types
On a phone, the keyboard is part of the form. The right input type makes typing much easier, and it is almost free.
- Use the right
typeandinputmode:emailfor emails,telfor phone numbers,numericfor digits like a code or a PIN. These show the right keyboard. - Use the
autocompleteattribute so the browser can fill name, email, address and one-time codes. The MDN documentation lists the available values. - Turn off auto-capitalization and auto-correct for emails and usernames.
- Make tap targets large enough. WCAG 2.2 sets a minimum of 24 by 24 CSS pixels for most targets, and a comfortable size is bigger.
- Keep the active field visible above the keyboard.
- Do not disable pasting in password or code fields. It makes password managers harder to use.
- Prefer native controls for dates and selects on mobile, unless you have a good reason.
The MDN page on the autocomplete attribute is a good reference.
How we check forms
Forms are among the first things we test in a UX audit. We fill them in wrongly on purpose, use only a keyboard, and try on a phone. Most products have something to fix here. For a new product, we design forms with their error and empty states from the start in an MVP design sprint. You can read more about our focus on the SaaS design agency page. If you have a form that you think loses people, send it to us for a free design review.



