Mobile-first is not a layout decision, it is where your customers are

Mobile-first gets explained as a technique, which makes it sound like a preference. It is not. It is an observation about where your customers are standing when they look you up, and everything else follows from that.

What the phrase actually means

Two ways to build the same site.

The common way is desktop-down: design the wide version, then squeeze it. Menus collapse, columns stack, and things that made sense in a 1,400-pixel row get crammed into 390. What ends up on the phone is a compromise, and the compromise is where most of your visitors live.

Mobile-first inverts it. Design the phone version properly, decide what genuinely matters when you only have one column, then use the extra room on desktop for more. The constraint comes first, so nothing important ends up squeezed out at the end.

The difference shows in what gets cut. Desktop-down cuts whatever fits worst. Mobile-first cuts whatever matters least, which are rarely the same thing.

Why a local business feels it hardest

A visitor to a national e-commerce site is often at a desk, browsing. A visitor to a local service site is frequently none of those things.

They are outside, or in a car, or standing in a shop deciding whether to bother walking in. They have one question: are you open, do you cover my street, what does it cost, can I ring you. They are on mobile data rather than wifi, and often on a signal that is worse than the one in your office.

That changes the brief. It is not “make it work on a small screen”. It is “make the one thing they came for available immediately, on a bad connection, with a thumb”.

The four failures we found most often

We measured 300 local Chicago-area sites on an emulated phone. The full findings are here; these are the four that are specifically mobile problems.

No tappable phone number, on 55% of them. The digits were usually present as text. On a phone that means memorising them, leaving the site, and typing. This is the largest and cheapest mobile failure in the entire sample.

Blocked pinch-zoom, on 9%. Somebody deliberately switched this on, and it stops a visitor enlarging your text. It is a WCAG failure and it is the clearest case in the data of a layout being protected from the people trying to use it.

Colour contrast failures, on half of them. Contrast that is merely acceptable indoors becomes unreadable in sunlight. Your customers are outside more often than your designer is.

Weight. The median site made 63 requests. That is fine on wifi and a different experience on a weak signal in a car park, which is where a good share of local searching happens.

What mobile-first actually looks like in a build

The first screen answers the question. Not a slogan. What you do, where you do it, and a way to make contact, visible without scrolling.

Tap targets are big enough. Around 24 pixels minimum, more for anything important. A phone number in body text is a link somebody misses twice before giving up.

One column, ordered by what matters. Not the desktop layout stacked in whatever order the markup happened to be in. Decide the order deliberately.

Text sizes that survive being enlarged. Which means not blocking zoom, and building a layout that still works when somebody doubles the size.

Images sized for a phone. Sending a 3,000-pixel-wide photograph to a 390-pixel screen is the most common cause of a slow local site, and it is invisible on the developer’s laptop.

Forms with the right keyboards. A phone field should bring up the number pad, an email field the email keyboard. It costs one attribute and saves the visitor a small irritation at exactly the moment they were deciding whether to bother.

How to check your own site in five minutes

Do not use the responsive mode in a desktop browser. Use an actual phone, on mobile data, with wifi switched off.

Load your homepage and count how long it takes to become useful. Try to tap the phone number. Try to pinch-zoom the text. Try to complete your own enquiry form with one thumb. Then go outside and read the page in daylight.

Most local businesses fail at least two of those. None of them require a rebuild, and the phone link is one line.

What mobile-first does not mean

Four things get sold under this heading that are not it.

A separate mobile site. The m. subdomain approach is largely gone and good riddance. It means two sites to maintain, two sets of content that drift apart, and a set of search problems around which version is canonical. One site that adapts is the answer.

Hiding content on small screens. The tempting shortcut is to hide the sections that do not fit. If a visitor on a phone does not need it, ask why anybody needs it. If they do need it, hiding it from most of your audience is not a design decision, it is a decision to serve them worse.

AMP. Google’s accelerated pages format was pushed hard, is no longer required for anything, and carries real costs in control and analytics. A fast ordinary page is better and simpler.

Passing a mobile-friendly test. Automated checks confirm the page does not overflow and the text is not microscopic. They cannot tell you whether somebody can accomplish what they came for. A site can pass every automated test and still be useless with one thumb outdoors.

The two numbers worth tracking

If you measure nothing else about mobile, measure these.

How long until the biggest thing on screen appears. Largest Contentful Paint, in Google’s language. Under 2.5 seconds is the threshold it treats as good, and under one second puts you ahead of roughly three quarters of local businesses. It is the number a visitor experiences as “has this loaded yet”.

What share of your enquiries come from phones. If your traffic is 70% mobile and your enquiries are 20% mobile, that gap is the entire problem, stated as a number. It is also the most persuasive thing you can put in front of somebody who thinks the site is fine because it looks fine on their laptop.

Neither is measurable without analytics installed, which is the unglamorous prerequisite behind most of this.

Where this sits in a build

We build the phone version first because that is where the enquiries come from, and the desktop version gets the extra room rather than the priority. Our own viewport deliberately permits pinch-zoom, because blocking it is a failure and the previous version of this site shipped exactly that on every page.

The web design service page covers what that means in practice, and the nine things a local service site needs is the shorter checklist version of this piece.

The short version

Mobile-first is not a style. It is designing for a person standing outside on a bad connection with one question and one thumb. Answer that question on the first screen, make the phone number tappable, do not block zoom, and check it outdoors rather than at your desk. Half your competitors have not done the first two.