Toolbox · No. 16

Test your site on phones before it ships

A site that looks right on a laptop can slide sideways or hide its call button on a small phone. Here is how to check before launch.

5 min read
Stacked red, blue, yellow and green building blocks beside a ladder on a warm white background.

An owner approves the new site on a laptop, nods at how sharp it looks, and signs off. Later, a customer on a small phone opens the same page, finds the call button pushed under a bar, and dials the next business on the list.

Before a site ships, it should be opened at phone sizes in more than one browser engine, the part of a browser that draws the page, and checked for sideways scrolling, hidden buttons and cut-off names. Ask your builder to show you that test and its results.

The short answer

  • Approve a site on a phone as well as the laptop it was built on.
  • Ask for a test that runs in more than one browser engine.
  • Treat a hidden call button as a broken page.

Your laptop is the wrong judge

A site looks right on the screen it was designed on because that screen has room to spare. A phone has none. Wide layouts, long headings, fixed bars and big images all behave differently when the space shrinks, and the person approving the site rarely sees that shrinking happen.

The same problems repeat. The page slides sideways, so a visitor drags it left and right just to read a line. One ordinary cause, per web.dev's responsive design basics, is that an image displayed wider than the viewport can cause horizontal scrolling. A call button ends up under a bar or off the edge, which hides the one action you want taken. Even a business name can lose its last letters.

Nobody on the team sees any of it, because everyone checks on their own devices. A designer's phone is usually new and large, and a developer's browser window is wide. The people most likely to hit the break are the ones nobody asked: a customer standing in a driveway, one-handed, on a smaller phone.

What can break on a small phone, and how to see it yourself.
On the pageSmall phone viewHow to spot it on your own phone
Page widthNo spare roomSwipe left and right; the page should not move
Call buttonCan sit under a barLook for it without scrolling, then tap it
Business nameCan lose its last lettersRead the full name in the header
HeadingsCan run off the edgeRead each one to its last word

Small screens also change how people behave. A visitor with a problem wants a number to call or a form to fill, and wants it within a thumb's reach. If the page makes them hunt, they leave, and you never learn they were there.

More words will not repair a layout problem, and a longer page is not automatically a stronger one, so spend your effort on how the page behaves on a small screen.

What a phone-sized test checks

A browser test opens your page the way a phone would, at a narrow size, and then checks what it finds. It can confirm that nothing scrolls sideways, that the call button is on screen and clickable, and that headings fit. A tired person skips steps; a script repeats them the same way every time.

We use Playwright as the test runner behind our responsive and visual regression checks. Its documentation describes an end-to-end test framework for modern web apps that runs in the major browser engines, headless or headed, with native mobile emulation for phones. It can also simulate a specific device, including its screen size, viewport and whether it has touch.

Playwright The test runner behind our responsive and visual regression checks.

Each browser engine draws the page its own way, so a pass in one is not a pass in all of them. Ask for a run in more than one, and treat a single-engine pass as half a check.

Run the test at several phone sizes too, since a layout that holds at one width can break at the next. The smallest phones are where names get cut off and buttons crowd each other.

A test also only checks what it is told to check. Point it at what costs you calls: the call button, the form and the top of the page where your name sits.

Approved on a laptop

  • One desktop screenshot signed off
  • The phone view glanced at on a single device
  • Problems found by customers

Checked at phone sizes

  • Real browser engines at narrow sizes
  • Call button and form confirmed on screen
  • Problems found before anyone calls

What to ask your builder to show you

Ask for evidence, not reassurance. A builder who tests properly can show you a run at phone sizes, in more than one browser engine, with the call button and the form checked. If the answer is that it looks fine on their phone, keep asking.

You do not need to read test code. You need to see the result and know what it covered. A short list of pages and sizes checked, with a pass or fail beside each, is enough. If something failed and was fixed, that should show in the list too.

Before launch, run a pre-mortem and ask what a customer on a small phone would hit first. The test then proves or clears each guess. Heavy extras are another place to look: a video earns its place on a service page only when it does a job, since each added piece is one more thing that can push a small screen sideways.

What to ask for before launch

  1. Ask which sizes were checked

    Phone sizes belong on the list next to the laptop width.

  2. Ask which engines ran

    More than one, so a pass in a single browser is not mistaken for all of them.

  3. Ask to see the call button

    It should be on screen and tappable on every page you send people to.

  4. Ask what happened to the form

    Fill it in the phone view and watch the message arrive.

  5. Ask for the failures

    A report that has never failed deserves a second look.

Make the phone check a rule

Every change to the layout can break the small screen, so the check belongs in the launch routine, right next to the form test and the tracking test.

Check tracking from the phone view as well. Confirm that analytics is recording there, because a page that loads but reports nothing hides a different problem from the one you were looking for.

If you are choosing a builder, look for one whose web design process puts a phone test before launch, and ask to see it in writing. Then Optymize your own approval step by writing the phone check into the launch routine.

Your own five minutes on a real phone

  • Drag the page with your thumb and watch for any sideways movement.
  • Tap the call button until the phone starts dialing, on every page you send people to.
  • Send yourself a message through the form and find it in the real inbox.
  • Open the same page on a phone of another brand and compare it with yours.
  • Read the business name and the top heading in full, holding the phone one-handed.

Talk to Offer before you decide anything.

You'll talk with Offer, not a sales rep. A short call, no pitch deck.

Talk to Offer

This post was drafted with AI tools from our own project records, anonymized, and checked by us before it published. Read our editorial standards.

Related Articles

Want to talk through your marketing?

Tell us where things stand and we'll tell you plainly what we'd do next.