Forms Deserve Better

Forms are where a product actually makes or loses money. The checkout, the signup, the booking: that is the moment of truth, and it is the least designed surface in most software. We polish landing pages nobody converts on and ship a checkout held together with default browser styling. Every field you add costs you completions, and the good news is you can measure that cost instead of arguing about it.

The cost of a field is a real number

Start with the evidence, because forms are one of the few design problems with solid public data. Baymard Institute, which has run checkout usability studies for over a decade, finds the average online checkout asks for 11.3 form fields, and that most could be cut to around 8 without losing anything the business needs. Meanwhile the average documented cart abandonment rate sits above 70 percent. A share of that is people who were only browsing. A large share is friction, and a form is friction you built on purpose.

That last number deserves its own sentence. Nearly one in five people who abandon do it because you demanded an account before they could pay. A guest checkout is not a nice-to-have. It is the removal of a wall you put between a paying customer and their own money. If you take one thing from this piece, let it be that a required account before a first purchase is the most expensive field on the form, and it is not even a field.

You do not have to take these averages on faith, because your own form is measurable. Instrument each field and watch where people stall, retype, or leave. A field with a high correction rate is confusing. A field where drop-off spikes is the one to question first. This turns form design from an argument about taste into a funnel you can read. The most expensive field is rarely the one people complain about. It is the one they silently abandon, and analytics is how you find it before it costs another quarter of revenue.

The mechanics almost everyone skips

Most form pain is not strategy, it is plumbing that never got connected. The browser already knows the user's name, address, and card, and it will fill them in for free, but only if you label your fields in the language the browser speaks. That language is the autocomplete attribute, defined in the HTML standard, with specific tokens like given-name, family-name, email, and street-address. Get the token right and a ten-field form fills in one tap. Leave it off and you have asked a person to type their own address from memory on a phone.

The second piece of plumbing is inputmode, which tells a phone which keyboard to show. A field for a card number or a one-time code should bring up digits, not the full QWERTY keyboard, because hunting for numbers behind a letters layout is a small tax you charge on every entry. And associate every label with its input properly, so tapping the label focuses the field and a screen reader announces it. These are not enhancements. They are the difference between a form that respects the person and one that fights them.

Two more small things pay off far beyond their effort. Use the right input type, so type=email gives you validation and the correct keyboard, and type=tel does the same for phone numbers. And do not fight password managers: give fields stable names, let people paste, and never block paste in a password box, a habit that helps nobody and pushes people toward weaker passwords they can retype. The browser and its extensions are trying to fill your form correctly. Most form bugs are a site getting in their way.

Then there is the placeholder used as a label, a pattern that looks clean and quietly fails everyone. The grey hint text vanishes the moment someone starts typing, so they lose the label exactly when they need it to check their work. It usually fails colour contrast, screen readers treat it inconsistently, and an empty field with only a placeholder gives assistive tech nothing to announce. A placeholder is a hint, at most. It is not a label, and using it as one is an accessibility failure, not a style choice.

Validate at the right moment, not on every keystroke

Inline validation, checking a field before the whole form is submitted, is good when it is timed well and maddening when it is not. Validate on every keystroke and you scream INVALID EMAIL at someone who has typed the letter a and is not finished. Wait until submit and you make them fix five things at once, after the fact. The timing that research supports is to validate a field when the person leaves it, on blur, once they have had their say. Then, if it becomes valid while they fix it, confirm that in real time.

The words in the error matter as much as the timing. Invalid input tells the user they failed and leaves them stuck. Enter your date of birth as DD MM YYYY tells them exactly what to do next. An error message has one job: get the person unstuck in the smallest number of words. Put it next to the field, not in a summary at the top they have to scroll back to find, and never rely on colour alone, because red means nothing to someone who cannot see it or read it as red.

Two guardrails sit around all of this. First, client-side validation is a courtesy, never a security boundary, so validate again on the server, because anything the browser checks can be bypassed. Second, confirm success as clearly as you flag failure. A field that quietly goes valid, with a small tick or a colour that also carries a shape, tells the person they can move on and stops them second-guessing a box they already fixed. Silence after a correction reads as another error waiting to happen.

Your form has assumptions, and they are wrong for most of the planet

Forms are full of quiet assumptions about names, addresses, and phone numbers, and almost all of them break outside a narrow slice of the world. Two boxes marked First name and Last name assume everyone has exactly two names in that order. Many people have one name, or three, or a family name written first. A required postcode assumes every country has one in your format. Phone fields that reject a plus sign or a leading zero assume everyone dials the way you do. These are not rare edge cases. They are the default state of a global user base.

Anything someone tells you is their name is, by definition, an appropriate identifier for them.

The safe defaults are humbler than the ones we usually ship. Prefer a single full name field over split first and last, unless you have a real downstream reason to separate them. Let names hold spaces, apostrophes, hyphens, and non-Latin characters, because O'Brien and a name in Tamil are both valid and both common. Make the parts of an address that vary by country actually vary. The GOV.UK Design System publishes patterns for names and addresses backed by real research, and they consistently land on asking for less and assuming less.

Email and phone hide the same trap. Treat email as case-insensitive and trim stray spaces, because Name@example.com and name@example.com reach the same inbox, and a person pasting from an address book should not be punished for a capital letter. Do not reject an address because your regular expression dislikes a plus sign or a newer domain ending, both of which are perfectly valid. If you genuinely need to know an address works, send a message to it. A rule that guesses at correctness rejects real customers while waving through typos that happen to match the pattern.

Fewer fields, or less effort?

Here is where I push back on the advice you have heard a hundred times. Reduce the number of fields is repeated as gospel, and it is not quite right. The honest version is reduce the perceived effort, which is related but not the same. A form can have fewer fields and still feel worse, if those fields are ambiguous, badly grouped, or ask for something people have to go and look up. Sometimes more fields, split into clear and obvious chunks, converts better than a short form that makes people stop and think.

A one-column layout is the reliable default here. Multiple columns invite the eye to skip a field, and they read ambiguously: is the box on the right the next step, or a separate question? A single column gives one clear path from top to submit, which is also the order a keyboard and a screen reader will move through. Test the whole thing by tab key alone, no mouse, and again with a screen reader. If you cannot complete your own checkout that way, neither can a chunk of your customers, and they will not email to tell you why they left.

Splitting a long form across steps can lower perceived effort even when the field count is identical, because a short page feels finishable and a wall of inputs feels like a chore. The catch is that each step is another page to load and another chance to lose someone, so steps earn their place only when they group the work in a way that makes sense: address here, payment there. A progress indicator helps, but only if it is honest about how many steps remain. The goal is never fewer screens or fewer fields as a rule. It is the shortest felt distance from start to done.

Read that research and a pattern jumps out. The teams that win at checkout are not the ones with the prettiest forms. They are the ones that removed a step, connected autofill, and stopped asking for things they did not need. None of that photographs well in a portfolio, which is part of why it stays undervalued while the logo gets another round of polish.