Mobile-First Mistakes That Cost Enquiries

“Mobile-first” has become a box on a proposal rather than a way of working. A site can be perfectly responsive — nothing overflows, nothing overlaps, every breakpoint behaves — and still be a poor place to try to hire a plumber while standing in a flooded kitchen.

Responsive is a layout property. Usable is a behaviour property. The gap between the two is where enquiries go missing, and the failures below are the ones we see repeatedly.

Designing at a desk, reviewing at a desk

The first mistake is procedural. The design is built at 1440 pixels wide on a colour-accurate monitor, reviewed by squashing the browser window, signed off, and shipped. Nobody holds it.

Squashing a desktop browser is not the same test. It tells you nothing about thumb reach, nothing about how the on-screen keyboard eats half the viewport, nothing about tapping accuracy while walking, and nothing about how the whole thing looks outdoors in July. Load the staging site on an actual phone, one-handed, and try to complete the thing a customer would want to complete. Then do it on an older Android handset, not just the newest iPhone in the studio.

Burying the one thing they came for

For a large share of local service businesses, the mobile visitor wants a phone number and wants it in the first screenful. What they often get is a full-bleed hero image, a slogan, a scroll indicator, and the number tucked into a footer four thumb-swipes away.

Put the action at the top. A tappable tel: link is not a design compromise, it is the point. If you take enquiries by WhatsApp or by form instead, put that at the top. The rule is not “phone number”; it is “the next step is visible without scrolling”.

Watch out for the sticky-bar arms race as well. A sticky header, a cookie banner, a promotional strip and a chat bubble can between them leave a 360-pixel-tall window of actual content. Each was added by someone reasonable. Together they are hostile.

Tap targets and the fat-finger problem

Links spaced for a mouse cursor are not spaced for a fingertip. Both the Android and iOS interface guidelines recommend a minimum touch target in the region of 44 to 48 pixels, and WCAG 2.2 added a target size criterion for the same reason.

The practical failures are consistent: navigation items stacked with no vertical padding, so people hit the wrong one; a “close” cross on a modal that is 16 pixels square; footer links listed at body line-height; adjacent “yes” and “no” buttons with two pixels between them. Give anything tappable room, and give destructive or dead-end actions more room than the action you want people to take.

Also consider where the thumb naturally sits. On a large handset, the top corners are the hardest part of the screen to reach one-handed. A primary action pinned to the top right is a small, constant tax on everyone using the site.

Forms that fight the keyboard

Mobile form abandonment is rarely about the number of fields alone. It is about friction that only exists on a phone.

Set the right inputmode and type on every field. An email field should raise a keyboard with an @ on it. A phone field should raise a numeric pad. A postcode field should not autocapitalise badly or autocorrect into a word. These are one-line attributes and they are missing from a surprising number of otherwise careful builds.

Use autocomplete tokens — given-name, email, tel, postal-code — so the browser can fill the form from stored details. That turns a two-minute task into a two-tap one.

Then check what happens when the keyboard opens. On many phones it covers the lower half of the screen. If your submit button now sits behind it, and the page does not scroll the focused field into view, people assume the form is broken. Test this specifically; it is invisible on desktop.

Menus that hide everything

The hamburger icon solved a real problem and created a smaller one: anything behind it gets looked at less. That is an acceptable trade for a twelve-item navigation. It is a bad trade when the only things you sell are hidden behind it and the header contains nothing else.

Two things help. Surface your two or three highest-value destinations directly in the header or in a bottom bar, and keep the menu itself behind them. And when the menu opens, make it usable: full height, closable with an obvious control, scrollable if it is long, and not silently scrolling the page behind it.

Content that assumes a wide screen

Some content types simply do not survive the transition and need a mobile-specific decision rather than a overflow: scroll.

Tables. A five-column price comparison becomes unreadable. Either restructure it as stacked cards per row, or accept horizontal scrolling and make it obvious that scrolling is possible.

Long paragraphs. A 90-character line on desktop becomes fifteen lines on a phone. Break the copy up more aggressively than feels necessary, and use subheadings so people can skim.

Multi-column layouts. Three columns stacking into one changes the reading order. Check that the order still makes sense, especially where a sidebar is now sitting between two related sections.

Images with text baked in. A graphic containing essential words at 1200 pixels wide is illegible at 375. Put the words in HTML, over or beside the image.

Testing that catches this before customers do

Chrome DevTools device emulation is fine for a first pass on layout. It does not reproduce touch accuracy, keyboard behaviour, real network conditions or genuine device performance, so do not stop there.

A short manual routine on two real handsets catches most of it: reach the phone number, open and close the menu, submit the form, and read one long article page. Then check your analytics for the mobile-versus-desktop split on conversions. If mobile is most of your traffic and a small fraction of your enquiries, the problem is on this list somewhere.

That split is worth looking at before commissioning any redesign at all. It usually tells you which three pages to fix rather than fifty.

If you want a second pair of eyes on how your site behaves on a phone, that is part of what website development work should cover, and it is worth settling before you consider anything more ambitious like mobile app development.