Designing Forms That People Actually Complete

The failure is usually structural, not visual

Most forms that get abandoned were not abandoned because the buttons looked wrong. People give up three fields earlier, at the point where the form asks for something they do not think they have. A date of birth when the service only needs to know they are over eighteen. A registered company name for a one-person freelancer. A full postal address when the invoice would have gone to a single inbox without trouble.

When a form underperforms, the instinct is to open a colour picker. That rarely moves the number. The useful first conversation is not visual at all; it is a field-by-field interrogation of what the form is for. Every input needs to answer three questions: who is providing this value, why does the business genuinely need it, and what happens to the request if it is missing or wrong. Our team at SmartEdge IT Solutions usually starts with an unfashionable document — a list of fields with a column for each of those answers. It surfaces scope disputes before a single pixel is drawn, which is far cheaper than surfacing them after launch.

A field that cannot survive that interrogation should come out. Not into a “we might want it later” list that quietly becomes a backlog, but out. The true cost of a field is not the markup needed to render it. It is the abandonment it causes, the support time spent on people entering it wrongly, and the storage and privacy exposure of holding a value nobody ever reads.

Ask for the least you can still use

Field reduction has diminishing returns and there is a floor below which the form stops being useful. Identifying an enquiry needs enough to contact somebody and route the request. Opening an account needs enough to verify identity and to satisfy whatever the business is obliged to record. A feedback form about a delivery needs the answers that would actually change a decision next time.

Three approaches help more than deletion outright.

• Move the question later. Not everything has to be asked before the first action. Take an email address, let the person begin, then ask the rest once they have invested effort. People behave differently once they have already spent something, though some will still leave, so the follow-up step has to stay forgiving.
• Derive the value. Country and dialling code follow from a phone number in most cases. City and state follow from a postcode. A separate surname field disappears when only a display name is stored.
• Pre-fill from context. If the person arrived from an account page, the identifier is already known. If the form sits inside an application where somebody is signed in, asking for their name is theatre.

That third point is the one teams forget. Passing known values through from context is unglamorous and reliably outperforms a visual refresh, provided the pre-filled value is visible and editable. A hidden value that the person cannot check generates a different failure: they assume what they read is what will be saved.

One category of field is worth defending, though: the one that proves identity. Removing a check to make the flow faster trades a little friction now for more fraud and manual review later. If a value exists to satisfy a legal or financial obligation, it stays, and working out which fields those are needs someone who understands the business rather than the interface.

Labels belong to inputs; placeholders do not

The most common labelling mistake is putting the instruction inside the input as a placeholder. The moment somebody starts typing, the instruction vanishes. That is a problem for everyone on a small screen with a keyboard covering half the viewport, and for anyone completing the form twice. It also fails outright for password fields, where masking means the person cannot check what they typed, so a label that disappears leaves nothing behind.

A persistent label above or beside the control survives zoom, translation, autofill and review. The placeholder, if there is one, is for format examples: for example, 09876543210 rather than enter your number. Examples that include a realistic value help more than abstract hints, particularly for postcodes, tax identifiers and phone numbers, where people genuinely cannot tell whether their format is expected.

Related: do not describe a field by its technical name. “Employee ID” means something only inside a particular company. “Your employee number, as printed on your payslip” means something everywhere.

Grouping matters too. Long forms read as a wall when every field is visually identical and evenly spaced. Breaking them into labelled groups with headings gives a sense of progress and gives people permission to come back later, because they can see how much is left. Where a form is genuinely long, a visible “Step 2 of 4” does more for completion than any amount of polish on one step.

Validate when the answer becomes knowable

Validation timing is where a lot of form damage originates. The two common failure modes are validating everything on submit, which means someone fills in twelve fields only to be told the email at the top was wrong, and validating on blur, which catches people while they are still in the middle of typing a value they have not finished.

The practical rule is to validate when the field loses focus, not while the keystrokes are arriving, and to hold off on anything expensive or server-side until the person has finished with that field. There is a nuance with formatted inputs: a partially typed email looks invalid for most of its life, so in-field error styling during typing reads as failure even when the value is fine.

Where it makes sense, let the browser do the cheap work. Native constraint attributes on inputs of type email and tel, plus required, give keyboard users the right on-screen keyboard and give assistive technology correct semantics at no cost. They are not sufficient alone — their messages are not translatable or branded, and the wording varies between products — but they are a good baseline before anything custom is written.

Server-side validation stays regardless. Client-side checks are a courtesy to the person filling the form in; they are not a control, because anyone can post to an endpoint directly. This point comes up repeatedly in our application testing work, and it is the reason validation logic tends to live in one shared place rather than being duplicated between a browser and an API.

Error messages that say what happens next

An error message has one job: tell the person what to do, and tell them where to go. “Invalid input” does neither. “Enter a date as day, month and year” does both, and costs eleven words more.

Place the message next to the field, connect it to that input so a screen reader announces it when focus arrives, and put a summary at the top listing the problems with links to each one. That last pattern exists because a long form scrolled to the bottom after submission is disorienting. Nobody knows which field is at fault, so they work upwards through everything, re-reading as though the failure were a test.

Three habits make the difference between a message that helps and one that inflates:

• Say what was wrong with the value the person gave, not with the field. “That phone number is one digit short” is more use than “invalid phone number”.
• Never blame. Nothing in the interface should imply the person did something foolish.
• Keep the value. A rejected form that clears every field is punishing twice. Redisplaying what was typed, with only the offending input highlighted, is the minimum acceptable behaviour.

Warnings are a separate case from errors. A value that is valid but worth confirming — a business email that turns out to be a public one, an unusually large order — belongs in a review step, not in a blocking error.

Mobile input is a different design problem

On a phone, most of the viewport is keyboard. A field placed in the lower third of the screen will be covered the moment somebody taps it. The fix is unglamorous: scroll the focused input into view and keep it clear of the keyboard area, accounting for the safe area at the bottom of the screen on recent devices. Getting this wrong makes the form feel broken in a way that screenshots do not capture.

Autofill matters more here, not less. Correct autocomplete values on name, email, address and telephone fields let the operating system fill the whole form from stored data, which removes most of the typing. It is a small piece of markup that has an outsized effect, and it is worth checking on both platforms because behaviour differs.

Numeric keyboards for numeric fields matter for error rates on long number strings. Masked inputs, on the other hand, are often a net loss: they make paste impossible, they annoy anybody who wants to verify what they entered, and the cursor jumps as separators are inserted. If a format must be enforced, do it on blur and normalise the value on the server, where you can also reject it properly.

Test on a real small device rather than trusting device emulation mode in a desktop browser, which does not reproduce the keyboard, the safe area, or actual touch behaviour. When a form is one component of a larger mobile product rather than a standalone page, this work sits more naturally with mobile interface design than with a page build, because the form inherits whatever navigation and error conventions the surrounding screens already use.

Measure the steps, not just the form

Overall completion rate tells you almost nothing about which field is the problem. Step-level drop-off tells you a great deal, and most analytics tools can produce it with an event per field group rather than anything elaborate.

Three further signals are worth collecting. Time to complete, compared against your own previous figures rather than an external benchmark, because long forms are sometimes correct. Error frequency per field, which distinguishes a confusing label from a genuinely difficult value. And the specific values that fail validation, which is where you discover that people are entering a GST number into a field labelled tax reference, or that everybody is entering dates day-first because the label implied it.

Session replays are useful for seeing how people interact, but they are a diagnostic tool, not a measurement. Watching ten sessions tells you what ten confused people did. It does not tell you how common the confusion is.

A pre-launch review worth having an argument about

Before a form goes live, walk through it with somebody who was not involved in building it and who is not the target user. Ask them to complete it while narrating. The narration is the signal. Where people start apologising to the form, or ask the person beside them what a word means, you have found a wording problem that internal review will never surface, because everyone on the team already knows what the field means.

Then check the unglamorous list. Does every input have a persistent label; is every required field marked as such before it is left empty; do error messages survive being read out loud; does the form work with a keyboard alone; does it survive a password manager filling everything in at once; does it still make sense at double text size; does it work when the session has timed out halfway through. That last one catches more real problems than any amount of visual polish.

None of this requires a large budget. It requires agreeing early on what the form is for, resisting fields nobody asked for, and testing with somebody outside the team. Where the problem is spread across a whole site rather than concentrated in one form, a broader site review is the better place to start, because the form is usually a symptom of something structural rather than the cause of it.

A form is not a component. It is the point where a person’s uncertainty, your data model and your business rules all meet. If any of those three is unclear, no amount of interface refinement will move the completion number. That is the argument we have with clients who want a redesign of the visual layer, and it is why our interface design work at SmartEdge IT Solutions starts with the field list rather than the wireframe.