Why do visitors abandon forms?
If people start your form and don't finish, it's tempting to start deleting fields. Sometimes that helps. But they may also be unsure what they're agreeing to, unable to recover from an error, or waiting for information they don't have. And some simply got interrupted.
Find the stage where progress stops before deciding what to change. Someone who never starts needs a different investigation from someone who presses Submit three times and gets nowhere. A shorter form won't rescue a request that your server keeps rejecting.
Count the journey before blaming the fields
Start with a unit you can count consistently, such as unique visits that reach a particular form version. Count each stage once per visit, using the same inclusion rules and observation window. If you can't reliably connect returning visits without collecting more personal data, keep them separate. Don't quietly turn guesses about identity into precise-looking numbers.
An illustrative repair-booking form produces this funnel:
| Stage | Visits | What it establishes |
|---|---|---|
| Form displayed | 100 | The form was available in the visit |
| First form interaction | 60 | The visitor began using it |
| Submission attempted | 44 | The visitor tried to send it |
| Submission accepted | 36 | The service confirmed a valid request |
The accepted-submission rate is 36% of form-viewing visits, or 60% of starting visits. Both are valid measures; they answer different questions. Sixteen starters made no observed submission attempt. Eight attempted submissions did not reach an accepted outcome in the measurement window.
It's easy to turn those groups into “24 people disliked the form.” We haven't established that. Some may have hesitated or been interrupted. Others may have hit an invalid entry, a network failure, or a broken success event. Compare the accepted count with deduplicated business records before trusting the browser's version of events.
The form starts before the first field
A form asks for a small commitment. The visitor is giving you time and information because they expect something in return. Read the button that brought them here, the form heading, and the message after submission. Are they describing the same exchange?
“See availability” sounds like a way to check a calendar. Follow it with a sales inquiry, and you've changed the deal. Likewise, “Get a price” followed by six questions and no price can disappoint someone even when every line of code works.
Write down the answers a cautious visitor would need:
- What will I receive when I submit?
- Will someone contact me, and through which channel?
- Am I booking, requesting, applying, or buying?
- What information do I need to have ready?
- Is the action reversible?
Put the answers where people have to make the decision. Your privacy page may explain the whole policy, but someone looking at a phone-number field still wants to know why you need it. Be truthful. “No sales calls” is a promise the rest of the business has to keep.
Give every question a job
Sit down with the person who actually uses these submissions. Take each question in turn: what will they do with the answer, and when do they need it? A field can seem essential because it's always been there. That's worth checking.
| Question | Decision it supports | Possible treatment |
|---|---|---|
| Which repair do you need? | Route the request to the right team | Keep, with understandable choices |
| Full street address | Plan an eventual collection | Ask later if collection is not being arranged now |
| Where did you hear about us? | Marketing analysis | Make optional or measure separately |
| Describe your problem | Understand unusual requests | Explain the useful detail, avoid a blank writing assignment |
But removing a question can create work somewhere else. If it prevents unsuitable bookings, it may deserve its place. Explain it clearly, then check the consequences of removing it: invalid requests, extra follow-up, or appointments the team can't fulfill. More submissions aren't much of a win if someone has to untangle them all.
Make optional fields visibly optional, too. People shouldn't have to submit an incomplete form to discover which questions they were allowed to skip.
Make errors recoverable without detective work
A visitor who submits an incomplete form has already expressed intent. Help them finish. W3C's form guidance recommends understandable error descriptions, instructions for correcting them, and clear feedback on success. Error summaries can link to the relevant controls. W3C form notifications.
Try to finish the form when things go wrong. Use invented input to submit an empty form, an invalid format, and a request the server rejects. Then make the connection fail. If every case produces “Something went wrong,” you've learned something useful about the recovery experience.
Check that previously entered non-sensitive information remains available where appropriate, the error is visible at the current scroll position, and keyboard focus reaches a useful place. Never put passwords or payment details into analytics while investigating.
Give the visitor an action they can take. “Invalid request” leaves the investigation to them. And if their request may already have been accepted, explain how to check before retrying. Otherwise, their reasonable attempt to finish can become a duplicate booking for your team to resolve.
Try it with the keyboard open
Your mobile screenshot may look excellent. Now open the keyboard. Complete the form on an actual phone, including scrolling, selecting a date, changing a choice, and returning from another app. The page has much less room to work with now.
Look for the button hidden behind a sticky footer, a date picker that escapes the screen, or a helper message pushed far away from its field. Try autofill with a synthetic test identity. Check that visible labels remain useful after the fields contain text.
On desktop, put the mouse aside and finish with the keyboard. Follow the focus order, open each custom control, and recover from an error. A recording might show someone pausing at this point, but it can't establish whether a screen reader announced the problem correctly. That needs a direct assistive-technology check.
When reviewing recordings, keep input values masked. Field identities, validation categories, focus changes, and accepted outcomes should be sufficient for this investigation. You need to know that a visitor struggled with the date selector, not the date they entered.
Match each observation to a plausible fix
Review visits with different endings: successful completions, starts without attempts, and unsuccessful attempts. Keep the form version and device context consistent. Successes matter here. If people who finish also pause at the date picker, a pause alone tells you less than you might think.
Write observations as sequences: “Opened the date picker, changed months repeatedly, closed it, then left.” Add a hypothesis separately: “Available dates may be difficult to distinguish.” That hypothesis now has a direct test with a realistic booking task.
Maybe they're checking a calendar. Maybe they were interrupted. Likewise, returning to the same field doesn't establish that its label is confusing. Keep possible explanations open until you can test them.
Prioritize reproducible failures first. Then choose one supported usability change, such as showing availability before asking for contact details. Keep the intended business outcome intact, and note what evidence would make you reverse the change.
Judge the fix by accepted, useful submissions
After release, repeat the original task and confirm that events still count the same stages. Compare the relevant form version, device group, traffic source, and observation window. Report counts alongside rates.
Keep an eye on the quality of what arrives: duplicate requests, unsuitable bookings, or submissions requiring extra clarification. The person handling the inbox should recognize the improvement, too.
If the numbers improve after release, check what else changed. Traffic mix and availability can move the rate alongside your edit; a before-and-after comparison doesn't establish causation. Keep a short note of what was broken, what changed, what worked when tested, and what remains uncertain. When the team revisits the form, they'll have a reason to keep the change instead of just a green percentage to point at.