Split any form's numbers by device and the gap is usually startling. Desktop completion in the fifties, mobile in the twenties, on the same form with the same questions. Most businesses have never looked, because the averaged number sits between the two and looks unremarkable.
It matters because the split is not even. For most small businesses, well over half of form traffic now arrives on a phone, and for anything found through social media or a search on the move it is considerably more. The worse experience is the majority experience.
The good news is that the causes are not mysterious. They are a short list of specific things, most of which can be fixed in an afternoon by somebody who is not a developer.
Look at the split before anything else
The first step is not a fix. It is getting the two numbers separately, because the size of the gap tells you how much of a problem you have and where to spend the afternoon.
A gap of a few points is normal and not worth chasing. Phones are a harder environment, people are more distracted, and some difference is inherent. A gap of twenty points or more is a problem with the form rather than with phones, and it is almost always caused by two or three specific fields rather than by the form as a whole.
If your tool shows per-question drop-off, split that by device too. The question where the two lines diverge is the question to look at, and it is usually obvious once you can see it.
The averaged completion rate is the one number guaranteed to describe nobody.
Typing is the expensive thing
The fundamental difference between the two contexts is that typing on a phone is roughly four times slower and considerably more error-prone. Everything else follows from that.
This means a free text question costs far more on mobile than the same question on a desktop, and a form with three of them is a different proposition entirely. It also means that any question you can turn from typing into tapping pays for itself twice: once in time and once in the errors that never happen.
The practical version is to go through the form and ask, for each field, whether the answer could be a choice instead. A surprising number can. Service, size, timeframe, location and budget are all commonly text fields that would be better as options, and each conversion is worth more on mobile than any styling change.
Keyboard type is a one-line fix
If a field expects a number, the phone should show a number pad. If it expects an email address, the keyboard should include an at sign. This is controlled by the input type and it is wrong more often than it is right, usually because the field was built as generic text with a label.
The cost of getting it wrong is not theoretical. Typing a phone number on a full alphabetic keyboard means switching layouts, which is two extra taps and a moment of irritation at exactly the field that is already the most sensitive on the form.
The same applies to autocomplete. A correctly marked-up address, email and phone field can be filled by the browser in one tap. An incorrectly marked-up one requires typing everything, and the difference over a six-field form is substantial.
Date pickers are the usual villain
If there is one component that accounts for more mobile abandonment than any other, it is the custom date picker. Small targets, a grid that is hard to hit accurately, a month navigation that requires precision, and often a modal that covers the rest of the form.
The native date input on a phone is almost always better than a custom one, because the operating system has designed it for the device and people already know how it works. Custom pickers exist mostly for styling consistency, which is a poor trade for a field people abandon at.
Where the date is constrained, such as an appointment booking, showing available slots as tappable options beats any calendar. It removes the possibility of choosing something unavailable, which is the other way date fields lose people.
The scroll problem
On a small screen, anything below the fold does not exist until somebody scrolls, and people do not scroll if they think they have reached the end.
This catches forms in two specific ways. A long option list can push the continue button several screens down, so somebody who does not scroll past the options thinks the form is stuck. And a submit button that sits below a block of terms text gets missed entirely by a share of people who assume the text is the end of the page.
The other version is the keyboard, which covers the bottom half of the screen when a field is focused. If the submit button sits there, it is invisible at the exact moment somebody has finished typing. This is easy to check and almost never checked.
One question per screen changes the maths
For forms that are long on a phone, moving to one question per screen is usually the single largest improvement available, and it is a bigger change than it sounds.
It removes the scroll problem entirely, gives every question the whole screen, makes the tap targets large without effort, and replaces a wall with a sequence. The trade is more taps, which people mind far less than they mind a page that requires precision.
It is not always right. Short forms are better as one screen, because a three-question form split across three screens feels longer than it is. The rough dividing line is around five questions, or any form where a single screen would require scrolling past the fold on a phone.
Uploads on a phone
File upload questions behave very differently on mobile and are worth thinking about specifically. On a desktop, a person has files. On a phone, they have photographs and whatever is in their cloud storage.
This is fine when you want a photograph, and it is often better, because taking one on the spot is easier than finding a document. It is a problem when you want a document that lives on a computer, because the person has to stop, move to another device, and start again, which most will not do.
If your form asks for a document and gets mobile traffic, offer a way to continue later, or accept the enquiry without it and follow up by email. A required upload of something nobody has on their phone is an abandonment, not a validation.
Tap targets and thumbs
The guidance figure is around forty-four pixels square, which sounds generous until you look at a set of radio buttons where only the small circle is tappable rather than the whole row including the label.
Missing a target on a phone is not neutral. On a set of options, missing usually means selecting the wrong one, and a person who does not notice has now given you a wrong answer rather than no answer. That is worse than an abandonment because it is invisible.
Spacing matters as much as size. Two options adjacent with no gap will be mis-tapped regularly regardless of how large each one is, particularly by anybody using the form one-handed on a moving train, which is a meaningful share of mobile traffic.
Test on a real phone, badly
The browser's mobile preview is useful for layout and useless for everything that actually causes abandonment. It has a mouse, a fast connection, no keyboard covering the screen and no sunlight.
Test on a real device, and make the conditions unfavourable on purpose.
- One hand, thumb only, while standing up.
- Outdoors in daylight, which is where the low-contrast help text fails.
- On a slow connection, which is where a heavy form reveals how long it takes to become usable.
- With the keyboard open, checking nothing important is hidden behind it.
- Switching apps halfway through, then returning, to see whether the answers survive.
Saving progress
That last test matters more than people expect. Phone users are interrupted constantly, and an interruption that loses everything somebody typed is an abandonment that felt like a betrayal.
A form that keeps answers when somebody switches away and comes back recovers a real share of submissions that would otherwise vanish. For longer forms it is close to essential, and it is a setting rather than a project in most modern tools.
The related version is storing partial answers server-side, so an abandonment still leaves you with whatever they had entered. That does not help the customer, and it means an enquiry that got as far as a name and an email is a lead you can follow up rather than a gap in a chart.
Speed is a completion feature
Mobile connections are slower and more variable than office ones, and a form that takes several seconds to become usable loses people before it has asked anything. This shows up as a poor start rate rather than as drop-off, which is why it gets missed.
Forms embedded in a page are the usual cause, because the embed often loads after everything else and sometimes pulls in a substantial amount of code to render a few fields. A person on a train sees the page, sees a blank space where the form should be, and leaves.
If your form is embedded, load the page on a throttled connection and time how long until somebody could type into the first field. Anything over about three seconds is costing you real submissions, and the fix is usually either a lighter embed or a hosted page rather than anything about the form itself.
Error messages on a small screen
Validation errors are more damaging on a phone, because the error often appears above the fold while the person is looking at the bottom of the form, or is hidden behind the keyboard entirely.
The person taps submit, nothing appears to happen, and they tap it again. A form that appears unresponsive is indistinguishable from a broken one, and the second tap sometimes produces a duplicate submission, which is its own problem at the other end.
Errors should appear next to the field, the page should move to the first one, and the submit button should visibly change state so it is obvious something happened. All three are defaults in well-built forms and absent in a surprising number of custom ones.
The order to fix things
If the gap between your two numbers is large, work through this list rather than redesigning. Each item is small and the first three usually account for most of it.
Check the input types and autocomplete on every field. Replace the custom date picker with the native one or with slots. Make sure the submit button is not under the keyboard. Turn the two most-typed fields into choices. Increase the tap targets and the spacing on option lists. Then, if the form is longer than five questions, try one question per screen.
Measure after each change rather than doing them all at once, for the same reason as always, and give it long enough that the number means something. Mobile traffic is noisier than desktop traffic because it arrives in bursts from wherever the link was shared, so a fortnight of it tells you considerably less than a fortnight of desktop numbers would.