Form abandonment rate: which field loses them

A visitor filling in a form is in the middle of a task. They are not reading the whole form before they start. They type the first few fields, then reach one they cannot answer from memory: a VAT number, a full billing address, a phone number they would rather not give, or a company name on what is meant to be a personal request. They leave to look it up and do not come back. The same thing happens when a field rejects a valid entry, such as a phone number with spaces or brackets, and the visitor assumes the form is broken.

• Field order: is the hardest question, such as a tax number, placed before the easy ones?
• Required marks: is every field required, and is each one needed to send the request at all?
• Validation timing: do errors show when the field is left, or only after the submit button is pressed?
• Mobile keyboards: does the next field get covered, and does the right keyboard open for it?
• Autofill: does the browser put the wrong value in a field, and does the form accept it anyway?

Form analytics, where you have it, shows which field a visitor last touched before they left. Without it, the simulated run gives you the same answer with a screenshot. The wrong instinct is to delete the whole form, which removes the parts that work along with the part that does not. The right instinct is to find the single field where visitors stop, then ask three questions about it: is it needed to send the request, is it asked at the right moment, and does it reject any valid answer. Often one field fails all three, and it is rarely the one the team argued about.

A password rule that appears only after submit, or an error message at the top of a long form that is off screen, tells the visitor that the page is broken. They scroll, they guess, and some of them stop. The wrong version shows one red banner after the send button. The right version marks the bad field as soon as the visitor leaves it, says what is wrong in plain words, and moves focus to that field. On a phone, the message should sit directly under the field, not above a keyboard that hides it.

A company registration number, a VAT number, a full billing address and a job title each make a visitor stop and think about whether they have the answer. Some stop to search for it, and do not come back. Others skip the field, and then the form refuses to send. Ask yourself whether the request needs the answer at all. A quote for a repair needs a name, a phone number and the job. A sales follow-up can ask for the company size on a second step, after the visitor has already sent the first request and has nothing to lose.

On a phone, the keyboard can cover the field the visitor is typing into, and the wrong keyboard opens for a number or an email. Autofill can fill a postal code into a city box, and the form may accept it because both are text. A bot check can stop a visit too. A simulated visitor blocked that way is marked as blocked by the site, not as a form problem, so the report will not blame the field for it. If your form has a bot check, test whether a person on a phone can get through it without a second attempt.

Forms grow one field at a time: a sales team asks for a company size, a finance team asks for a tax number, a campaign adds a source question. Each addition can become the field where a visitor stops. Run the same form again after every change to its fields, their order or their validation, and check whether more simulated visitors reach the send button. Paid runs can include forms behind a login, using a test account you give.