Why mobile design needs its own decisions

This guide lists the decisions, explains what Google and usability research say about each, shows you how to test your own site with a phone in your hand, and ends with a checklist you can use without us.

Say you run a bike repair shop. Your desktop home page has a wide banner photo, four columns of services, a map, a booking form with nine fields, and your opening hours and phone number in the footer. On a phone, a responsive layout stacks all of that into one long column.

Nothing is broken, strictly. The page fits the screen. But the person holding the phone is probably on a pavement outside your shop, or on a bus, wanting to know three things: are you open, where are you, and can I book a repair. The banner takes the whole first screen. The opening hours are a long scroll away. The phone number is plain text, so it cannot be tapped. The booking form needs nine fields typed on a small keyboard, with each label hiding as soon as the visitor starts typing.

The layout works. The page does not. The fix is a set of decisions about priority, not a different screen width.

Three things have to be true before any design decision matters.

The page has a viewport tag. Without it, web.dev explains, "mobile browsers render the page at a desktop screen width (usually about 980px, though this varies across devices)" and then shrink the result, so text becomes tiny. The standard line is <meta name="viewport" content="width=device-width, initial-scale=1">, and any competent developer adds it by default.

Nothing forces sideways scrolling. web.dev's guidance is plain: users are used to scrolling vertically but not horizontally. A single oversized image or table is enough to break this.

The mobile page carries the same content as the desktop page. Google uses the mobile version of your site for indexing and ranking. Its documentation says Google "uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking," and it asks that the mobile site contain the same content as the desktop site, with equivalent titles, descriptions and structured data. If your phone page quietly drops half the text of your desktop page, that is the half Google will not see.

Google recommends responsive web design, where one page adapts to every screen, because it is the easiest pattern to implement and maintain. For most business sites that is the right default, and the rest of this guide assumes it.

This is the biggest decision, and it is made before any pixel is drawn.

Nielsen Norman Group (NN/g), the usability research firm, puts the principle bluntly: "Desktop copywriting must be concise. Mobile copywriting must be even more concise." Their advice is to move the cut-off point between primary and secondary content when designing for phones. What was acceptable as a secondary item on a wide screen becomes clutter on a narrow one.

In practice this means ranking what your visitors came to do. For the bike shop, that ranking is hours, location, contact and booking. For a furniture retailer it is the product photo, price and delivery information. For a professional services firm it is probably what you do, who it is for and how to start a conversation. A written page brief for each important page, with a "mobile priorities" field, forces that ranking before design starts. When we plan a site, every page gets one, and the mobile priorities are in it.

There is a trap here, and it is worth naming. NN/g notes that for many sites content and feature parity between phone and desktop is the right answer, while for others a good mobile experience means trimming content and features. Google, meanwhile, indexes the mobile version. These fit together if you separate presentation from substance. Collapse a long specification into a labeled section that expands when tapped. Move the history of the company lower down. Do not delete the text that answers real customer questions.

As web.dev's responsive design guidance puts it:

"Don't hide content just because you can't fit it on the screen."

Small tap targets are one of the most common reasons a site feels fiddly on a phone, and three sources give three different numbers, which is confusing until you see why.

WCAG is the accessibility standard from the W3C, and its number is the floor you must not go below. The other two are the sizes at which a button is comfortable. Aim for the larger ones on anything that matters, such as the call button, the add-to-basket button and every form control, and do not rely on the floor. NN/g adds that larger targets are warranted for primary actions and for older users with declining dexterity.

Spacing counts as much as size. Two small links stacked tightly in a footer are the classic failure: a tap on one lands on the other.

NN/g lists typing on a virtual keyboard as one of the core differences of mobile use, because it divides the user's attention. Their advice for phones is to minimize the number of steps and, ultimately, the number of page loads.

For a form, that translates into concrete choices:

As a standard, we set body text and form inputs at 16 pixels or larger. That is a commitment about what we build, not a result we claim.

Yes, in two ways.

A phone does not need a desktop-sized photograph. web.dev reports that serving desktop-sized images to mobile devices can use 2 to 4 times more data than needed. The fix is responsive images, where the page offers several sizes and the browser picks the right one. Our guide to website images that help customers understand your offer covers that in more depth.

Phones are also more likely to be on a weak or changing connection. NN/g lists variable connectivity as one of the constraints that define mobile use. Google's Core Web Vitals give targets for real visitors: the main content loads within 2.5 seconds, the page responds to taps within 200 milliseconds, and the layout does not jump (a score of 0.1 or less), measured at the 75th percentile of page loads and segmented across mobile and desktop. If your site feels slow on a phone, why a website is slow walks through how to find the cause.

Use a real phone first. No emulator tells you that your thumb covers the button or that the sun on the screen makes grey text unreadable.

NN/g's comparison of mobile approaches is candid about the costs of responsive design: responsive sites "tend to be slower" because the same content goes to every device, they "tend to be more expensive to develop" than a separate mobile site, and they "work less well for complex tasks and content" such as large data tables. That does not make a separate mobile site a better choice for most businesses, because it doubles the content you maintain and risks the content gap that Google's mobile-first indexing punishes. It does mean that "responsive" is a technique, not a guarantee. A responsive site can still be slow, cluttered and awkward on a phone if nobody made the decisions above.

If your phone experience is the problem, the quickest route is a written list of your three most important pages and what a phone visitor should do on each. That list is the core of a page brief. If you want a site where those priorities are decided before design, read about our website design and development work, or read about what makes a website more accessible, since large tap targets, readable text and clear labels help phone users and people with disabilities alike. When you are ready, you can discuss your project with us.

1. web.dev, "Responsive web design basics" (viewport tag, horizontal scrolling, hiding content)

2. Google Search Central, "Mobile-first indexing best practices"

3. Nielsen Norman Group, "Mobile UX" (constraints of mobile use)

4. Nielsen Norman Group, "Mobile UX Sharpens Usability Guidelines"

5. Nielsen Norman Group, "Mobile Websites: Mobile-Dedicated, Responsive, Adaptive, or Desktop Site?"

6. Nielsen Norman Group, "Touch Targets on Touchscreens"

7. web.dev, "Accessible tap targets"

8. W3C, "Understanding Success Criterion 2.5.8: Target Size (Minimum)"

9. web.dev, "Autofill" (Learn Forms)

10. web.dev, "Serve responsive images"

11. web.dev, "Web Vitals"

12. Google Search Central, "Understanding page experience in Google Search results"

13. Google PageSpeed Insights documentation, "About PageSpeed Insights"

14. Chrome for Developers, "Lighthouse overview"

15. Search Console Help, "Core Web Vitals report"