Our forms get abandoned halfway through. What in the interface is causing it?

The standard advice is to remove fields. It is easy to act on, which is why it spreads, and it usually does not fix mid-form abandonment.

Think about what abandonment halfway through actually means. The person read the form, decided it was worth their time, and started typing. They had already accepted the field count. Something after that decision pushed them out.

A form with twelve fields that behaves well is finished more often than a form with five fields that shouts at you. In the redesigns we do, the forms that leak are almost always the ones that surprise the person filling them in. A rule appears that was not visible before. An error appears somewhere they are not looking. Work they already did disappears.

The useful question is not how long is the form. It is does the form tell the truth about its length and its rules before someone commits.

Each check below pairs a symptom you can see with the interface cause behind it. Work through them in order. The first two cost nothing but ten minutes of your own attention, and in our experience they account for most of the loss.

1. Validation firing on keystroke instead of on blur. Type three letters of an email address and watch. If a red message says "enter a valid email" before you have finished typing, the form is calling the person wrong for typing normally. The fix is to validate when the field loses focus, and after that first check, revalidate live so the error clears as they correct it.
2. Errors placed away from the field. Submit the form with one field wrong. If the message appears in a banner at the top, or in a toast that fades, the person has to hunt for the problem. Put the message directly under the input it belongs to, and move focus to the first failing field on submit.
3. Required rules revealed only at submit. Fill the form the way an ordinary person would and press submit. Anything you are told off for that you had no way to know is a rule discovered too late. Password minimums, phone formats, optional fields that turn out to be required. Show the rule under the field before it is typed in, not after.
4. Data lost on error. Get an error deliberately, then look at what is still in the boxes. If the page reloaded and cleared a textarea someone spent four minutes writing, they are not writing it again. Nothing in a form should ever be cleared by an error except a card number.
5. No sense of how much is left. A single long scroll with no step count or progress marker gives no reason to keep going. If the form is longer than one screen, either break it into named steps or show all of it at once so the end is visible. The worst version is a scroll that keeps producing new fields as you go.

If you patch these on one form, they come back on the next one someone builds. The repairs belong in the shared input component and its tokens, so every form on the site inherits them.

At the component level, one input handles four states: rest, focus, error and disabled. The error state includes the message slot underneath, so a developer cannot ship an error without a place to put the text. That single decision removes the top-of-page error banner for good.

At the token level, the error colour needs to pass contrast against your form background at the small text size the message uses. We have seen a red that looked fine in the mockup fall to roughly 3:1 against a light grey field, which passes for the border and fails for the sentence. Set the message colour from a darker step of the same red than the border uses.

One more component detail worth naming: the helper text slot. If a field has a rule, the rule lives in helper text in the rest state. A component with no helper slot forces every rule into an error, which is the discovered-too-late problem in the previous check.

You do not need field-level funnel tracking to find this. Five people and a video call will surface more than a heatmap will.

Ask five people who are not on your team and not customers. Give them a real reason to fill it in, like “you want a quote for your office, get one”. Then say nothing.

Watch for four things and write down the timestamp each time one happens.

A pause of more than three seconds over a field, which means the label or the rule is unclear. A scroll back up after submitting, which means the error was not where they were looking. Any sentence spoken aloud, because people only narrate when confused. And retyping, which means something was lost or rejected.

Two of five doing the same thing in the same place is a finding. In our own testing that threshold has almost always pointed at one specific field, and fixing that field was worth more than every copy change we could have made to the page.

Before rebuilding anything, check that the form is the actual failure. Three cases mean the interface is not at fault.

The traffic is wrong. If most people arriving at the form came from a paid ad that promised something the page does not deliver, they will start the form out of curiosity and leave when the mismatch registers. No amount of validation timing repairs that.

The ask comes before the value. A demo request placed above any explanation of what the product does gets started by people who then scroll away to find out what they are agreeing to. Move the form below the proof, not above it.

The offer is wrong for the moment. Asking for company size and budget from someone who wanted a price is a qualification form wearing a contact form’s clothes. People fill in the first two fields, meet the third, and understand what is happening. That is not an interface bug, and if it is deliberate, the drop-off is the form working. Decide which one you want before you fix anything.

If none of those three apply, the interface is the cause, and the five checks above will find it. Start with validation timing. It is free, it takes an afternoon, and it is the one we most often find still broken on sites that have been redesigned twice.