Form Design: Labels, Order, and Field Length
A good form keeps labels visible, sizes fields to the expected input, and marks optional fields. What NN/g, the GOV.UK Design System, and a CHI 2014 study say.
Why do forms fail so often?
Because every field is a small decision, and every badly solved decision is an opportunity to abandon. A study presented at CHI 2014 (Seckler, Heinz, Bargas-Avila, Opwis, and Tuch), cited by NN/g, compared forms that followed usability guidelines with forms that violated them: the first had 78% one-try submissions, against 42% for the second (NN/g: Web Form Design, Kathryn Whitenton, 2016).
That figure is the argument for starting with the basics: labels, order, length, and errors. Before thinking about animation or micro-interactions, a form has to hold up on those four things.
Where do labels go?
NN/g recommends placing the label immediately above the field on mobile and on shorter desktop forms. Only very long desktop forms should place it beside the field. The practical reason is that a label above stays visible while the person types, and does not disappear once the field is filled.
Avoid using example text inside the field as if it were the label. It disappears as soon as someone types, and the person cannot check what they were supposed to enter. NN/g says placeholder text causes many usability problems and is best avoided.
How long should each field be?
Text fields should be roughly the size of what is expected to be typed. A postal code field that is very long suggests more is needed than is, and an address field that is too short forces people to scroll or lose sight of what they wrote. As an example, NN/g analyzed the city names of 2,130 UX conference participants: 99.9% were 19 characters or shorter, in a range from 3 to 22. It is a figure from one sample, so use it as a guide, not as a universal rule.
How do you mark required and optional fields?
NN/g recommends limiting the form to only one or two optional fields and labeling them clearly as optional. The GOV.UK Design System adds “(optional)” to the labels of optional fields and says never to mark mandatory fields with asterisks (GOV.UK Design System: Question pages).
If a question needs explaining, use a hint of a single short sentence beneath the label, for information that helps most people answer. Long explanations do not belong there.
One question per page, or everything on one screen?
The GOV.UK Design System recommends starting with one question per page: according to its guidance, this helps people understand what they are being asked to do. When a page has a single question, that question can be the page heading. On progress indicators, the guidance suggests starting without one and, if people struggle, trying a simple step or question indicator. It cites the Carer’s Allowance team, which removed a 12-step progress indicator with no effect on completion rates or times (GOV.UK Design System: Question pages).
As a practical criterion, one question per page fits when each answer depends on the previous one. If people need to compare or review several pieces of data at once, grouping related fields on one screen, in sections, may work better. In both cases, test with users.
How should errors appear?
Errors are part of the form, not an accident. The GOV.UK Design System recommends putting the message in red after the question and hint text, with a red border that connects it to the field, and summarizing all errors at the top of the page with the same message shown next to the field. It also says not to clear any form fields when showing the error, and to prefer a direct instruction (“Enter your first name”) over a description of the failure (“First name must have an entry”). Among the words it avoids is “please,” because it implies a choice (GOV.UK Design System: Error message).
NN/g adds two rules: signal errors through a variety of cues, not solely through color, and preserve what the person typed so they can correct it. For when each field should be validated, read form validation timing.
Illustrative example
Illustrative example: a service sign-up form asks for first name, last name, date of birth, postal code, and an optional phone number. The original version had labels inside the fields, a postal code field the same size as the address field, and an asterisk next to each required field. When the person submitted with one wrong entry, the message said “Invalid data” and cleared the whole form. The redesign puts the labels above, sizes the postal code field for five characters, marks the phone number as “(optional),” and keeps the data when an error occurs. The message reads “Enter your postal code using five numbers,” a direct instruction rather than a description of the failure. Afterward, the team tracks how many submissions go through without errors on the first attempt.
If the answers need to be validated as they are entered, combine this article with how to write error messages and with loading states for the submission itself.
Common mistakes
- Using placeholder text as the only label.
- Using the same field size for a postal code and an address.
- Marking required fields with an asterisk instead of labeling the optional ones.
- Clearing the form when there is an error.
- Showing “Invalid data” without saying what to fix.
- Asking for data the service does not need.
What you can do tomorrow
- Open your longest form and count how many fields the service actually needs.
- Review each label: if it disappears when typing, move it above the field.
- Submit the form with a deliberate error and check that the message says what to fix and that the data is kept.