Mobile-first web design: why most of your UK customers judge you on a phone

Mobile-first web design means you design and build the phone version of your website first, then expand it for tablets and desktops. Responsive design only promises that the layout adapts to the screen. The difference matters because, for most UK businesses, the phone is where a customer first meets you, and since 2024 Google has crawled and ranked sites almost entirely on their mobile version. If your site was designed on a 27-inch monitor and squeezed down afterwards, the version Google judges and most visitors see is the afterthought.

Below is what mobile-first means in practice, a ten-minute test you can run on your own site today, the mistakes we fix most often and what it costs to put right.

How many of your visitors are really on a phone?

Ofcom’s Online Nation reports have shown for several years that the smartphone is the device most UK adults use to go online, and that a large share of browsing time happens on phones. That is the national picture. Yours will be different, so check it before you spend anything.

In Google Analytics 4, open Reports → Tech → Tech details and switch the dimension to Device category. Look at the last 90 days, not the last week. Then look at conversions (form fills, calls, sales) by device, because traffic share and money share are not always the same thing.

Here is the rough pattern we see across client sites:

Those are ranges from our own projects, not a survey. The point is that even a B2B firm in Leeds selling to procurement teams gets a meaningful slice of first impressions on a 6-inch screen, and a mobile hairdresser in Cardiff may get nearly all of them.

What Google does with your mobile site

Google moved to mobile-first indexing over several years and completed the switch in 2024. In plain terms, Googlebot visits your site pretending to be a smartphone, and the content it finds there is what gets indexed and ranked. Three consequences follow.

• Anything missing on mobile is missing, full stop. If your developer hid a block of text, a table of prices or your reviews on small screens to tidy the layout, Google may never see them.
• Core Web Vitals are measured on real phones. Google’s thresholds for a “good” experience are Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1. Mobile scores are almost always worse than desktop, because phones on 4G in a car park are slower than an office PC on fibre. We explain these in Core Web Vitals explained.
• Intrusive pop-ups count against you. A full-screen newsletter box that covers the content as soon as someone lands from Google is a known problem on mobile. Cookie banners required by law are treated differently, but they still need to be small and easy to dismiss.

Responsive vs mobile-first: what actually changes

Almost every site built in the last ten years is technically responsive. The columns stack, the menu turns into a hamburger and nothing scrolls sideways. That is the minimum. Mobile-first is a different starting point, and it shows in the decisions:

The desktop version of a mobile-first site usually ends up better too. When you have been forced to decide what matters on a small screen, the large screen gets less clutter.

What mobile-first changes in the design itself

Content in the order people need it

Someone searching “emergency plumber Bristol” on their phone wants three things in the first screen: that you cover their area, that you can come today, and a button to ring you. A three-paragraph company history is not in that list. We write a short brief for the first screen of every key page before anyone opens a design tool.

Thumbs, not cursors

WCAG 2.2, the accessibility standard we build every template to, sets a minimum target size of 24 by 24 CSS pixels at level AA. Apple and Google recommend larger, around 44 to 48 pixels, and that is what we use for anything people tap often. Links in a paragraph need enough spacing that a thumb does not hit the wrong one. Primary buttons sit low enough on the screen to reach one-handed.

Text you can read without pinching

Body text at 16 px minimum, line length that does not run edge to edge, decent contrast in sunlight. Form inputs also need 16 px text or iPhones zoom in when someone taps the field, which throws the layout around and annoys everyone.

Forms that use the right keyboard

Small details make a big difference on a phone. A phone number field should open the number pad (type="tel"), an email field should show the @ key, and autocomplete attributes should be set so the browser can fill in name, address and postcode in one tap. For UK addresses, a postcode lookup saves people typing a full address on a glass keyboard.

Images sized for the screen

A 3 MB hero photo looks the same on a phone as a 120 KB one cut to the right size. We serve WebP or AVIF images at several widths and let the browser pick, so a phone on 4G never downloads the desktop version.

A ten-minute mobile test you can run today

Take your own phone, turn off Wi-Fi so you are on mobile data, and open your website from a Google search, not a bookmark. Then work through this:

• Does something useful appear within about two seconds, or do you stare at a white screen?
• Does the page jump around while it loads, so you tap the wrong thing?
• Can you tell what the business does and where it works without scrolling?
• Is there a phone number you can tap to call, and does it actually dial?
• Can you open and close the menu with one thumb, and are the links far enough apart?
• Is the body text readable without zooming?
• Does a pop-up or cookie banner cover more than about a third of the screen?
• Fill in your own contact form. Does the right keyboard appear for each field? Does the browser offer to autofill? Did the message arrive?
• If you sell online, add something to the basket and get as far as the payment page. Does Apple Pay or Google Pay appear?
• Turn the phone sideways. Does anything break?

Then run the page through Google PageSpeed Insights on the mobile tab. Look at the “Discover what your real users are experiencing” section first: that is field data from Chrome users, which is what Google uses. The Lighthouse score below it is a lab test, useful for finding causes.

If you answered no to three or more of the questions above, the site is costing you enquiries.

The mobile mistakes we fix most often

• Sticky headers that eat the screen. A header with logo, phone number, menu and a promo bar can take 30 % of a phone screen and stays there as you scroll. One slim row is enough.
• Hover menus. Drop-downs that open on mouse hover often need a double tap on a phone, or do not open at all.
• Carousels in the hero. Slides that auto-rotate every four seconds on a phone are rarely read, and they usually carry the heaviest images on the page.
• PDFs for key information. Price lists and menus as PDFs mean pinching and zooming. Put them in the page as text.
• Embedded maps that trap the scroll. A full-width Google Map catches the thumb and stops people scrolling past. Use a static map image with a link to directions.
• Hidden content. Sections hidden on mobile “to keep it clean” that contained the reviews, the prices or the service areas.
• Page builders. Sites built with heavy visual page builders often load several hundred kilobytes of code a phone does not need. We explain why we avoid them in our article on custom WordPress development.

How we build mobile-first sites

Our process is the same for a five-page site for a café in Manchester and a large catalogue for a retailer in Birmingham. Wireframes start at 360 px wide. We agree the content order for the first screen of each key template with you before any visual design. Themes are hand-built, with no page builder, so the code that ships is only the code the page uses.

We target a Lighthouse score of 95 or more and WCAG 2.2 AA on every template, then test on real devices: at minimum a current iPhone, an older iPhone with a small screen and a mid-range Android phone, with the connection throttled. Forms are tested end to end, including the email that arrives in your inbox. Before launch we check the mobile and desktop versions carry the same content, so nothing is lost to Google.

We are based in St Albans and work with businesses right across the UK, mostly remotely, with in-person meetings in London and the Home Counties when that helps.

What mobile-first design costs

All our website packages are designed mobile-first. These are our current offer prices, excluding VAT:

On the Startup Website the mobile responsive add-on is optional on paper. In practice we would always take it: a site that does not work on phones is not worth £350.

Worked example: fixing an existing WordPress site. Say your site is two years old, the content is good, but the mobile version is slow and the forms are awkward. A typical mobile clean-up (image optimisation, a slimmer header, form fixes, removing a slider, tidying the menu) takes around 10 to 15 hours. At 10 hours of WordPress development: 10 × £50 = £500, less the 5 % volume discount = £475, plus VAT of £95 = £570. Hours are paid online through hire us and never expire, so anything left over can go towards later changes.

If the site is built on a heavy page builder or an old theme, patching it can cost more than it is worth. Past about 25 to 30 hours of fixes, a rebuild on one of our fixed-price packages is usually better value, and we will tell you which side of that line you are on.

Do you need an app as well?

Usually not. If customers use your service once or twice a year, a fast mobile website is the right answer. An app earns its keep when people come back often, for example to rebook, reorder or track something, or when you need features like push notifications, offline use or the camera.

There is a middle option. A progressive web app is a website that can be added to the home screen, work offline and, on most devices, send notifications, without going through the app stores. When a full app does make sense, we build for iOS and Android together with Flutter; see our mobile app development service.

Where to start

Run the ten-minute test above and the PageSpeed check on your three most important pages: the home page, your main service or category page and your contact or checkout page. If the problems are small, a few hours of fixes will do. If the site fails on most counts, start again on a mobile-first build. Either way, send us the link through our contact page and we will tell you honestly which route makes sense, and roughly what it costs, before you commit to anything.

Photo: Azwedo L.LC via Unsplash