Mobile mistakes you notice on the first tap
Tiny tap targets, keyboards covering fields, sticky headers, wide tables and hover that doesn't exist: what to check in your mobile version.
Products are usually designed and tested on a big monitor, then used largely on phones: on the bus, in a queue, one-handed. Generated interfaces are “responsive” in the sense that columns stack into one. That’s necessary, and nowhere near enough.
Here are the mistakes we run into most.
Tap targets that are too small
A finger is fatter than a cursor. A 16-pixel icon sitting 4 pixels from its neighbor is fine with a mouse and miserable with a thumb. Aim for a touch area of at least 44 pixels on its shorter side, even if the icon itself stays small. Padding enlarges the target without changing how it looks.
Pay special attention to places where opposite actions sit side by side: Save and Delete, Accept and Decline. A miss there is expensive.
The keyboard covers the field
Someone taps a field near the bottom of the screen, the keyboard slides up, and the field disappears behind it. Or a Submit button pinned to the bottom rides up with the keyboard and covers whatever they’re typing.
What to check:
- the field you’re typing in stays visible on a small phone;
- the right keyboard opens: numeric for codes and amounts, one with @ for email;
- autocorrect and auto-capitalization are off where they get in the way: usernames, codes, addresses;
- the page doesn’t zoom in when a field gets focus. On iPhone that happens when the input font is smaller than 16 pixels.
Sticky headers and bars
A sticky header, a sticky bottom bar, a floating chat button, a cookie banner, and the content is left with a strip in the middle. On a big screen you never notice. On a small phone in landscape it’s half the height.
Pin only what genuinely needs to stay within reach. Headers can hide on scroll down and come back on scroll up. And check that pinned elements respect the notch and the gesture bar on newer phones.
Tables
A ten-column table on a phone becomes either microscopic text or a horizontal scroll nobody discovers. Neither works.
Better options:
- show two or three key columns on mobile and the rest when a row is tapped;
- turn each row into a card with fields stacked vertically;
- if scrolling is unavoidable, pin the first column and make it obvious the table is wider than the screen.
The right choice depends on what people do with the table. If they compare rows, they need columns. If they’re looking for one record, cards are fine.
Hover that doesn’t exist
Phones have no hover. Anything that appears only on hover, such as tooltips, row action buttons or dropdown menus, doesn’t exist for mobile users. Or it behaves oddly: the first tap “hovers” instead of doing anything.
Important actions should be visible without hover, or reachable through an explicit “more” button.
Modals
A modal designed for desktop often doesn’t fit a phone’s height and won’t scroll, or the page underneath scrolls instead. The only way out is an X in the top corner that a thumb can’t reach.
On phones, bottom sheets or full-screen views with a clear Back button work better. And the system back gesture should close the modal, not navigate away from the page.
Speed
A phone on a train is slower than a laptop in an office. Heavy images, a font in five weights and a multi-megabyte bundle feel very different there. Turn on network and CPU throttling in the dev tools and walk the main flow. It’s unpleasant, and it’s worth it.
How to test
The browser’s device emulator is good for layout, but it isn’t a phone: no real keyboard, no fingers, no bad signal. Find the smallest, oldest phone on the team and walk through the key flows one-handed. If you’re irritated by screen three, your users were irritated by screen two.
SUBXCAT tests mobile versions on real devices and fixes whatever stands between a phone user and the main flow.