Reviewing Mobile and Responsive Designs With Clients

StatCounter's figures from September 2026 put mobile devices at just under 60% of global web traffic, with desktop trailing at under 40%. Most review rounds still happen entirely on a laptop. That gap is where a surprising number of launch-day complaints come from: a client approved a site they only ever saw on a 15-inch screen.

What that gap actually costs

A site that was only ever judged on a laptop screen can launch with real problems nobody on the project ever saw: a menu that never closes, a button hidden under the keyboard, text that needs zooming to read. None of these show up in a desktop review, and all of them show up immediately to the majority of people who land on the site first on a phone.

Resizing a browser window isn't a mobile review

Shrinking a desktop browser gives you the responsive breakpoints, not the real experience: no touch targets, no on-screen keyboard pushing a form up, no actual thumb reach across the screen. It's a fine check for a developer confirming layout rules. It's not a substitute for someone opening the site on an actual phone.

What to ask clients to check on their own phone

• Tap targets - can every button and link be tapped accurately without hitting the wrong thing next to it?
• Text size - is anything small enough that it needs pinch-to-zoom to read comfortably?
• Navigation - does the mobile menu open, close, and reveal every page it should?
• Forms - does the on-screen keyboard cover the submit button, or push important fields out of view?

Frame it as a short, separate task: "open this link on your own phone, in your normal browser, and just scroll through once." Most clients own exactly one device that matters here, their own, and reviewing on it takes two minutes.

Show, don't just tell, when you report a mobile issue back

The same logic that applies to clients reporting bugs applies here: "the menu is broken on mobile" is hard to act on without knowing which phone, which browser, and what "broken" actually looked like. Whoever is doing the reviewing, client or agency, benefits from attaching a quick screenshot from the actual device rather than describing the problem from memory afterward.

Run the desktop and mobile rounds separately

Bundling both into one review tends to bury mobile-only issues under desktop comments, since most people default to reviewing on whichever screen is already open in front of them. Send two short links or two clearly labelled sections instead: "desktop feedback here, mobile feedback here," so neither gets skipped because the other felt like "enough."

Where feedback gets collected matters more on mobile

A client scrolling a site on their phone is unlikely to also open a laptop to write up what they noticed, which is exactly how most mobile issues quietly go unreported. Being able to leave a comment pinned to the exact spot, on the device they found the problem on, removes that second step entirely. Roundmark works the same way on a phone browser as on a desktop one, so a tap target issue gets reported from the phone where it was actually noticed, not forgotten by the time its finder sits back down at a laptop.

Build it into your standard timeline, not as an extra step

The easiest way to make sure a mobile pass actually happens is to put it on the project timeline by name, the same way "client review round two" has its own line. "Mobile review" left implicit inside a general review round is the first thing to get skipped when a client is short on time, since it reads as optional even when you didn't mean it that way.

Don't skip tablets entirely, but don't over-invest either

Tablets sit in an awkward middle ground: enough traffic to be worth one quick look, not enough to justify a third full review round. A single check that nothing overlaps awkwardly at tablet width is usually sufficient, saved for the technical QA pass rather than a separate client review step.