A form that nobody finishes is usually not ugly. It is often the tidiest thing on the site, built from a component library, with proper spacing and a good typeface. People still leave it, and the analytics show them leaving at a particular point rather than drifting away evenly.
That detail is the useful part of form UX. Abandonment is local. It happens at a field, at a moment, or at a message, and the fix is almost always narrow rather than a redesign.
Abandonment happens at a field, not at a form
The first move is to stop treating the form as one object. Every field is a separate transaction where the person decides whether answering is worth it, and a form fails at whichever field loses that argument first.
Three kinds of field lose it reliably.
Fields that ask for effort out of proportion to the task. A phone number on a newsletter signup. A company size on a contact form. Each one is a moment where the person reconsiders the whole exchange, and reconsidering is where they leave.
Fields whose purpose is invisible. People will give a surprising amount of information when the reason is obvious and almost none when it is not. A date of birth on a medical intake form is unremarkable. The same field on a download form reads as data collection, because it is.
Fields that cannot be answered from memory. An account number, a model number, an order reference. These do not cause abandonment so much as deferral, and deferral is worse. The person leaves to find the number and the tab is gone by the evening.
The cheapest improvement available to most forms is to count the fields, then take a hard look at what is required. Marking a field optional does not remove its cost, because the eye still processes it, but it does remove the wall. A required field the person cannot answer ends the session; an optional one they skip does not.
The order matters as much as the count. Fields that are easy and obviously relevant belong at the top, because a person who has answered three questions is measurably more likely to answer the fourth. Fields that feel like an intrusion belong last, after the person has invested enough to want the thing at the end.
The keyboard is the interface on a phone
On a small screen, most of the visible area during typing is keyboard, and most form frustration on phones comes from the wrong one appearing.
Two attributes control this and they do different jobs.
The input type carries meaning and validation. An email type triggers a keyboard with the at sign present, and it also enforces a format on submit. A tel type produces a keypad. A number type produces digits but comes with spinner controls and its own handling of leading zeros, which makes it a poor fit for anything that is a string of digits rather than a quantity, such as a postal code.
The inputmode attribute is a hint only and enforces nothing. Its values are none, text, decimal, numeric, tel, search, email and url. It has been available across browsers since December 2021, and the browser uses it to pick a virtual keyboard. Where the input type has to stay as text for validation reasons, inputmode="numeric" still gets the digits keyboard, which is the common reason to reach for it.
The third attribute is the one most often left out, and it saves more typing than either. autocomplete tells the browser what a field contains, using tokens such as given-name, family-name, email, tel, postal-code and street-address. A correctly annotated address block can be filled with one tap. An unannotated one is typed out on a phone keyboard by every visitor.
Two conditions are worth knowing, because autofill failing silently is common. Browsers may require the field to have a name or id attribute, to sit inside a form element, and for that form to have a submit button. And the same token used on two fields will be filled with the same value in both, so billing and shipping blocks need their tokens prefixed to stay distinct.
Labels, placeholders, and the information that vanishes
Placeholder text as a label is the most persistent bad pattern in form design, and the reason is that it looks correct in a mockup, where nothing has been typed yet.
What breaks in use: the label disappears at the moment the person starts typing, which is exactly when they might want to check what was asked. It disappears again when the browser autofills the field. Anyone who is interrupted halfway comes back to a form of grey boxes with values in them and no way to tell what any of them is. Placeholder text is also rendered in a low contrast grey by default in most browsers, which pushes it below the contrast people can comfortably read.
Labels above the field, left aligned, are the default worth arguing for. The eye travels a short distance from label to input, the pairing survives a narrow screen without reflowing, and long labels do not force the input column to move.
Placeholders still have a job. They are for an example of the format, where the format is genuinely ambiguous, and the example should not be the only place that information appears. If a date needs a particular order, say so in help text under the label, which stays visible, rather than in the placeholder, which does not.
One column, and the narrow exceptions
A single column is the right default because it produces one unambiguous path through the form. Two columns create a question at every row about whether to go right or down, and people answer it inconsistently, which is how the second column ends up skipped.
The exceptions are narrow and specific. Fields that are genuinely one unit can share a row: a date split into three inputs, a first and last name pair, a city and postal code. The test is whether someone would describe them as one piece of information out loud. Anything else goes on its own row, including the pair that looks like it belongs together because both boxes are short.
Width is the other signal, and it is free. An input for a two letter state code should not be as wide as an input for a street address. Matching field width to expected content tells the person how much is wanted before they start, and it catches errors early, because a field sized for four digits makes a sixteen digit entry obviously wrong.
Validation: timing is the whole design
Nearly every complaint about form validation is about when, not what.
Validating on every keystroke marks a field as invalid while it is being filled in. An email address is invalid at every character until the last one, so the person types under a red border and a message telling them they are wrong, which is both untrue and unpleasant.
Validating only on submit means the person completes the whole form, presses the button, and is sent back to fix something they did four minutes ago. On a long form this is where sessions end.
The timing that works for most fields is on blur: check when the person leaves the field, and clear the error as soon as their correction makes it valid. There is one useful exception, which is a field with a rule the person cannot guess, such as a password with composition requirements. There, showing progress against the rules during typing helps, because the alternative is repeated rejection.
Two things about the messages themselves. An error has to be next to the field it belongs to, not collected in a banner at the top, because a banner forces the person to work out the mapping. And it has to say what to do rather than what happened. "Enter a date in the future" is actionable. "Invalid input" is a dead end.
The cheapest error to fix is the one that should never have been an error. A phone number rejected because it contains spaces, a card number rejected because it was pasted in groups of four, a name rejected because it contains an apostrophe. Accepting what people naturally type and normalising it afterwards removes an entire class of failure, and it costs a few lines.
One page, sections, or one question per screen
Long forms have three shapes, and the choice is mostly determined by the audience rather than by taste.
| Shape | Suits | Cost |
|---|---|---|
| One long page | Short forms, and people filling it in repeatedly | Looks intimidating at length, no sense of progress |
| Sections with next buttons | Forms with distinct topics, and mixed devices | Progress must be shown, or people cannot tell how much is left |
| One question per screen | Phones, and forms that are new to the person | More taps, and reviewing an earlier answer is harder |
The variable that decides it is how familiar the person is with the content. Someone submitting a weekly report wants everything on one page so they can move through it fast. Someone applying for something once wants one question at a time, because each screen is small enough to be obviously doable and the count of remaining questions is the reassurance that keeps them going.
Two things make multi step forms work rather than fail. Progress has to be real, meaning it reflects the questions remaining rather than a decorative bar. And nothing should be lost when someone leaves, either by saving as they go or by keeping their answers when the back button is pressed. A multi step form that discards a half finished submission is worse than a long page, because the person lost more work.
The part of the experience that happens after submit
The form experience does not end when the button is pressed, and this is where the largest gap usually sits.
The immediate need is confirmation that something arrived. A page saying thank you covers the moment, but it is gone as soon as the tab closes, and it gives the person nothing to search for later. An email sent on submission with a copy of what was entered is what removes the follow up message asking whether the form went through. On intake forms that class of message is often a significant share of everything that arrives.
The second need is a next step with a timescale. "Someone will be in touch" invites a chase. "A reply comes within two working days" does not, provided it is true.
Both of these are functions of the tool rather than the design, which is why they are worth checking against the features list of whatever is being used before spending another week on layout. A form that captures beautifully and then drops the submission into a spreadsheet nobody owns has moved the failure downstream rather than fixed it. Keeping the response, the owner, the stage and the reply in one place is what makes the promised timescale something a team can actually hold to.
What to change first
Count the required fields and remove the ones that do not change what happens next, then set autocomplete on everything that has a token. Move validation to blur with messages beside the field, and check that an email with a copy of the answers goes out on submission, because Halict sends that from the response itself rather than as a separate step someone has to remember.
Q1. How many fields is too many for a form?
There is no single number, because the answer depends on what the person gets at the end. The useful test is per field rather than per form: if a field will not change what happens next, and cannot be asked later, it is costing completions for nothing. Required fields carry far more weight than optional ones.
Q2. Are placeholders instead of labels really a problem?
Yes, and mostly for a reason unrelated to accessibility. The label vanishes the moment typing starts and again when the browser autofills, so anyone interrupted returns to filled boxes with no way to tell what was asked. Keep the label above the field and use the placeholder only for a format example.
Q3. Should validation run while someone is typing?
Not for most fields. Checking on every keystroke marks an email address as wrong at every character until the last one. Validate when the person leaves the field, clear the error as soon as it becomes valid, and make the exception for rules nobody can guess, such as password composition.
Q4. Is a multi step form better than one long page?
It depends on how familiar the person is with the content. Someone filling in the same form weekly is faster on one page. Someone doing it once, on a phone, finishes more often with one question per screen. Either way, progress has to be visible and a half finished submission must not be discarded.
Q5. Why does browser autofill not work on some forms?
Usually a missing autocomplete attribute, and sometimes a structural requirement. Browsers may need the field to carry a name or id, to sit inside a form element, and for that form to have a submit button. Reusing the same token on two fields also causes both to be filled with the same value.
Q6. What is the single change that most often improves completion?
Removing required fields that nothing downstream uses. It costs no design work, it cannot break, and it shortens the form for every visitor rather than for a segment. After that, correct keyboard and autofill hints on phone traffic, which is where most of the typing effort actually is.