The First Ten Minutes of Testing a Design on Mobile

I start with the thumb, not the breakpoint

Before I open DevTools, I hold the phone in my right hand, stand up, and try to reach every interactive element with my thumb. That is the default user posture. Not a perfectly centered browser window, not a device emulator, just a slightly distracted human with one hand free.

If a primary button, menu toggle, or form field lives in the top-left corner, it is already wrong ergonomically, no matter how pretty the layout looks. I do not care yet if the CSS grid collapsed correctly at 375px. If I have to stretch, change grip, or use my second hand for a core action, it fails the first test.

Mobile testing is not about screen width; it is about human reach. The first few minutes are just me hunting for anything important that lives outside the natural thumb zone.

Hover states become dead zones

The next thing I look for is anything that only feels interactive on desktop because of hover. Cards that lift on :hover, links that only change color when the cursor floats over them, ghost buttons that only show their border when you tease them with a mouse.

On mobile, there is no hover. There is just the ambiguity of a tap.

In the first minute, I drag my thumb slowly across the screen and see which elements ignore me until I commit to a full tap. If a link only changes color on hover and has no visible active state, people pause, tap twice, or miss it entirely.

This is where a design that looked elegant on desktop suddenly feels evasive on mobile. The interface is technically there, but nothing is volunteering to be clicked. Before I open any inspector, I already have a list of components that need an obvious pressed state, focus state, or static affordance that says, clearly, “you can touch me.”

The 100vh trap shows up without tools

I scroll to any section that is meant to be “full viewport height” and just watch what happens. On a real phone, the browser chrome eats the bottom part of the layout. The nice, tidy 100vh hero often loses a noticeable slice of space to the address bar, bottom bar, or some other piece of UI the browser insists on showing.

I wrote about this earlier in Why I Rebuilt My Portfolio Navigation From Scratch (Twice).

Then I rotate the phone. If the layout suddenly jumps, crops content, or leaves a weird empty band where the keyboard or chrome used to be, someone trusted 100vh a bit too much.

These are not bugs you catch by resizing Chrome to a fixed mobile width on a laptop. They are environmental distortions caused by the actual browser UI. You feel them before you measure them. I note them mentally in those first minutes, because they are tactile problems, not computational ones.

Text that disappears in the sun

After that, I go looking for text that survives anything brighter than a dim office. Contrast ratios that technically pass WCAG on a calibrated monitor can fail brutally on a phone held outdoors at an angle.

I walk to a window or step outside and check the body text, labels, and secondary information. If I have to squint, tilt the screen, or shade it with my hand to read a label, that design has already failed a real-world accessibility test. The browser does not care that the design system says “muted gray for secondary copy.” My eyes do.

Mobile screens are not calibrated to your Figma canvas; they are calibrated to the weather. In the first two minutes, daylight is a more honest audit than any automated contrast checker.

Forms and keyboards: where layouts go to die

Forms are where I expect things to break, so I get to them quickly. I tap the first input field and watch the viewport instead of the label.

I am checking a few things at once:

• Does the page scroll so that the active field stays visible, or does it end up hidden under a header?
• Does any fixed header or sticky element collapse gracefully, or does it sit on top of the input?
• When the software keyboard appears, does the submit button stay reachable, or does it get buried with no obvious way to dismiss the keyboard?

These are the interactions where mobile UX dies in the real world. A form that looks beautiful as a static mockup often becomes a navigation puzzle once the keyboard arrives.

More on this in my article Why I Still Test In Safari First (And The Bugs It Catches Early).

In the first thirty seconds of testing a form, I do not care about validation messages, error copy, or microcopy. I care about whether I can see what I am typing and reach the button that finishes the job.

Scrolling momentum as a performance test

Before I touch any performance panel, I flick the page and feel the scroll. That first flick tells me most of what I need to know about how heavy the page is.

If the scroll stutters, catches on a sticky header, or feels like it is fighting my finger, I assume there is too much going on: too many repaints, too many sticky layers, or some JavaScript trying to hijack touchmove events.

Smooth scrolling is not a metric in this phase; it is a sensation. The body notices stutter before the profiler does.

Only after that do I make a mental note to look for the usual suspects in DevTools later. The thumb sets the priority list.

The quiet before the metrics

There is a specific quiet in the first ten minutes where I try to be just a user, not a developer. No inspecting elements, no console, no screenshots of the DOM. I pick a simple task and try to complete it: sign up, buy something, read an article, or navigate to a specific page.

Read also What a 90ms Font Swap Taught Me About Performance Budgets.

As I do that, I pay attention to where my patience frays. The moment I feel “this site does not want me to finish,” I stop and write that down. That feeling is the real bug report.

DevTools will later show me layout shifts, blocking scripts, and slow images. It will not show me the micro-frictions: the button I almost missed, the field I lost under the keyboard, the text that vanished in sunlight, the scroll that felt sticky, or the thumb stretch that made the primary action feel optional.

Those first ten minutes, before any metrics, are where the most honest data comes from. The phone, the thumb, the light, and a bit of irritation are usually enough to tell me what is wrong long before the graphs do.