How to test website on mobile: four steps

On a laptop the window is large and steady, and a button stays where you left it. A phone shrinks the visible area three ways at once. The on-screen keyboard takes the lower half when a field is tapped, the address bar grows and shrinks as the page scrolls, and a fixed header or cookie banner covers an edge of the screen. A button that is clear on your desktop can end up under the keyboard or behind the banner, and the visitor has no way to know it is there.

• Each field can be reached with the keyboard open, and the field in focus scrolls clear of it.
• The main button stays on screen or within reach at each step, in portrait and in landscape.
• No fixed header, cookie banner or chat bubble covers a field or a button.
• Tapping a button gives a result straight away, and the page does not jump under the finger.

A resized laptop window keeps its height, its room for a keyboard and its fixed bars. A phone does not. When a visitor taps a field, the on-screen keyboard can take more than half the screen, and the page has to scroll that field clear of it. Some sites do that, and some leave the focused field under the keyboard while the button sits below it. The address bar adds a second change. It collapses as the visitor scrolls, so a first screen sized to the visible height can end up taller than what the visitor sees, and its bottom button moves out of reach.

Fixed elements do the rest. A header that stays at the top can cover the first field when the browser brings it into view, and a cookie banner or chat bubble at the bottom can cover a Continue button. A laptop window rarely shows either problem, because there is room around them. A phone has no room to spare, so one fixed bar is enough to hide the one button the visitor needed.

The screenshot at the stop decides which fault you have. If the button is visible when the page loads and disappears once a field has focus, the keyboard covers it. If the button is below the bottom of the screen with the keyboard closed, the layout is taller than the visible area. If the button is on screen and tapping it does nothing, something transparent sits on top of it, such as a fixed element or an overlay. Each needs a different fix, so do not change the layout to solve an overlay.

The visitor's own words help too. A thought that mentions a keyboard, a bar at the top, or a button that only moves when the page scrolls points to the cause. Read that thought beside the screenshot before you open the code, because the code will not tell you which of the three you hit, and a stranger rarely describes it in those terms.

Run the phone test on the path that brings in money or a lead: the sign-up, the trial, the contact form or the address step of checkout. Those screens put several fields and a button on one screen, so they are where the keyboard and the fixed bars overlap. A menu tour tells you the header works. It does not tell you whether a stranger can type an address, read the total and press Continue.

Signup flow testing

Phone layouts break when a new element arrives: a cookie banner, a chat bubble, a sticky sign-up bar or a longer first screen. Each one can cover a button that the last run passed. Rerun the same phone task after each change, on a preview address, and read the stop each time.