Testing on a Real Phone, Not a Simulator

What the browser view actually shows

Every desktop browser can pretend to be a phone: pick a device, and the page reflows to that width.

It is a useful tool and it is doing one job well, which is showing you the layout at a given screen size.

It is not a test of the experience, because almost everything that goes wrong on a phone goes wrong for reasons the emulator does not reproduce.

The distinction matters because teams reasonably conclude they have tested on mobile, having checked the thing that was easiest to check.

Speed is the biggest gap

The emulator runs on your desktop machine, with a desktop processor, on your office connection.

A real phone has a fraction of that processing power, particularly the mid-range and older handsets a great many customers actually carry.

It is also frequently on mobile data with variable signal rather than on fast broadband.

A page that appears instantly in the emulator can take eight seconds on a three-year-old phone with two bars, and no amount of resizing a desktop window will ever reveal that.

Touch is not a small mouse

A mouse pointer is one pixel and perfectly accurate. A fingertip covers roughly the width of a thumbnail and arrives with the finger obscuring the target.

Clicking a small link with a mouse in an emulator succeeds every time and tells you nothing about whether a person can tap it.

Neither does the emulator show you the two-handed stretch a large phone requires, or the way a thumb naturally rests, or the fact that a control in the top corner is genuinely awkward.

These are physical facts about hands and devices, and they are invisible to a simulation running on a machine with a keyboard.

What only a real device reveals

• How long it actually takes on a normal connection.
• Whether targets can be tapped accurately.
• Which keyboard appears for each form field.
• Whether the page is readable in daylight.
• Whether tap-to-call actually dials.
• How much the page moves while it loads.

The third and fifth are impossible to check any other way, and both are directly connected to whether an enquiry happens.

Test on the phone you do not have

Testing on your own device is a large improvement and it carries a specific bias.

Your phone is probably newer than average, and if you use one platform you are unlikely to notice faults that appear only on the other.

The practical approach for a small business is to check on two: your own, and an older or cheaper handset belonging to somebody in the office.

The older device is the more informative of the two, because it approximates what a substantial share of your visitors are holding.

Where a wider spread genuinely matters, testing services exist that provide real devices remotely, though for most small businesses two real phones covers nearly everything.

Test the way a customer arrives

Three conditions that change the result and are usually wrong when people test.

On mobile data rather than the office wireless, since a customer standing outside a building is not on your broadband.

With the cache cleared, or in a private window, because your phone has visited your site many times and is loading a stored copy.

And arriving from a search result rather than by typing the address, since that is how real visitors land and they often arrive on an interior page rather than the homepage.

A worked example

A trades business had checked their new site carefully in the desktop browser's phone view and found it faultless.

Opening it on an actual phone, outside, on mobile data, produced four findings in about six minutes.

The homepage took roughly nine seconds to become usable, because of a background image nobody had resized.

The phone number in the header was an image, so tapping it did nothing at all.

The quote form's phone field brought up the standard letter keyboard rather than a number pad.

And the page shifted downward twice while loading, so a tap intended for the call button landed on a service link instead.

None of the four was visible in the emulator. All four sat directly between a visitor and a phone call.

Where emulators are genuinely useful

Worth being fair to the tool, because the argument is about what it is for rather than whether to use it.

Checking layout across many widths quickly, which is tedious on real hardware.

Finding elements that overflow sideways at particular sizes.

Inspecting code and diagnosing a fault you have already found.

And rapid iteration while building, where switching to a phone after every change would be impractical.

The right sequence is to build with the emulator and confirm with a device, rather than treating the first as a substitute for the second.

Watch somebody else use it

The single most informative test available, and it costs nothing.

Hand your phone to somebody who does not work for you, name one task, and say nothing else while they attempt it.

Not what do you think of the site, which produces opinions about colours. A specific task: find out whether we cover Langley, or book an appointment.

Watch where they hesitate, what they tap that is not tappable, and where they scroll back up looking for something.

Three people, three minutes each, tells you more than a fortnight of internal review, largely because they do not know what the site intends and are therefore reacting to what it does.

The counter-case

This can be taken to an unproductive extreme.

A small business does not need a device lab, a testing matrix, or coverage of every handset in circulation, and pursuing that is a good way to spend money without improving anything.

Two real phones, checked properly at the points that matter, catch nearly everything that costs enquiries.

The right moments to test are after a launch, after any significant change, and once or twice a year otherwise. Continuous testing of a site that has not changed finds nothing and quietly stops happening.

The test

1. Use a real phone, not the browser's device view.
2. Switch to mobile data and clear the cache.
3. Arrive from a search result, on an interior page.
4. Time how long the page takes to become usable.
5. Tap every important control, including the phone number.
6. Open every form field and check the keyboard.
7. Repeat on an older handset, then watch a stranger try it.

Fifteen minutes, twice a year, and after every change of any size.

Why a site feels slow on a phone is covered in why your site feels slow on a phone.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.