Mobile-First Redesign: Designing for Phones Before Desktops

Picture someone looking up your business while standing in a parking lot, phone in one hand and coffee in the other. They want your hours, your phone number or a quick sense of whether you can help. If your site makes them pinch, zoom and squint, there's a good chance they'll tap the back button and try someone else.

Mobile-first design is an approach that starts with that small screen. You plan the layout, content and interactions for a phone first, then expand the design for tablets and desktops. It's the reverse of the older habit of designing a wide desktop page and squeezing it down afterward.

This guide explains what mobile-first means in practice and the specific things to get right during a redesign, drawing on guidance from Google, web.dev and MDN.

Why Start With the Phone

There are two practical reasons. First, designing for a narrow screen forces useful decisions. With limited space, you have to choose what matters most on each page, and that clarity usually improves the desktop version as well.

Second, search. Google uses the mobile version of a site's content for indexing and ranking, which it calls mobile-first indexing. Google advises that the mobile version include the same content as the desktop version, including text, images and their alt text, structured data, titles and meta descriptions. Hiding content on phones to save space can mean Google doesn't consider it.

web.dev's guidance on responsive design also recommends a mobile-first approach: start with the small screen, then widen the layout until the content itself calls for a change.

Responsive Layout Basics

Responsive design means one website whose layout adapts to whatever screen it's viewed on. It's the approach Google recommends, because there's only one version to build and maintain. A few fundamentals make it work:

• The viewport meta tag. This line in a page's code tells phone browsers to match the page to the screen's width. Without it, MDN explains, mobile browsers lay the page out as if on a much wider screen and shrink it to fit, which leaves text tiny.
• No sideways scrolling. People expect to scroll up and down, not left and right, so content should fit within the screen's width.
• Flexible images that shrink to fit their space instead of spilling off the edge.
• Breakpoints chosen by content. A breakpoint is the screen width at which the layout changes, for example from one column to two. web.dev advises letting the content decide where those changes happen, rather than targeting particular devices.
• Simple single-column layouts on phones, with the most important information near the top.

On a phone, navigation usually collapses into a menu button. Keep the menu short and use plain labels so people can reach what they need in a tap or two.

Tap Targets That Fit Fingers

A tap target is anything a visitor touches to take an action: buttons, links, menu items and form fields. Fingers are far less precise than a mouse pointer, so small or crowded targets lead to mistaken taps.

web.dev recommends touch targets of around 48 by 48 device-independent pixels, which it notes is roughly the size of a finger pad, with about 8 pixels of space between them. The accessibility standard WCAG 2.2 sets a lower minimum at its AA level: targets of at least 24 by 24 CSS pixels, with some exceptions such as links inside a sentence. Aiming for the larger recommendation gives most people a comfortable margin.

Give extra attention to the actions people take most on phones. A phone number that opens the dialer when tapped, or an address that opens a map, is a small detail that fits how people actually use their devices.

Text People Can Actually Read

Readable text on a small screen comes down to a few basics:

• A comfortable base font size, so visitors never need to zoom just to read a paragraph
• Strong contrast between text and background; WCAG asks for at least 4.5:1 for normal-sized text
• Short paragraphs and clear headings that break up long pages
• Sensible line lengths on wider screens; web.dev cites the classic guideline of roughly 70 to 80 characters per line

Also leave zoom switched on. MDN warns against viewport settings that stop people from zooming, because people with low vision rely on enlarging text to read it.

Keep It Fast on Phones

Phones are often on slower or less reliable connections than office computers, and many have less processing power. That's why Google's PageSpeed Insights tests pages on a simulated mid-range phone over a mobile network, as well as on a desktop setup.

Google's Core Web Vitals give you three targets, assessed at the 75th percentile of real page loads, which roughly means that at least three out of four visits should meet them:

• Largest Contentful Paint of 2.5 seconds or less, for how quickly the main content appears
• Interaction to Next Paint of 200 milliseconds or less, for how quickly the page responds to taps
• Cumulative Layout Shift of 0.1 or less, for how little the page jumps around while it loads

Practical ways to stay within these during a redesign include compressing and correctly sizing images, giving images a width and height so the layout doesn't jump as they load, limiting custom fonts, avoiding heavy sliders and autoplaying video at the top of the page, and being selective about third-party add-ons such as chat widgets and tracking scripts.

Test on Real Phones

Browser tools that imitate phone screens are handy during design, but they can't fully reproduce the experience of a real device in your hand. Before launch:

1. Open key pages on at least one iPhone and one Android phone, borrowing them if you need to.
2. Complete your main tasks, such as calling, booking or filling in a form, using only your thumb.
3. Rotate the phone to check the landscape view.
4. Try the site on mobile data, away from Wi-Fi.
5. Run PageSpeed Insights on your homepage and a few important inner pages.

Key takeaways

• Design for the phone first, then expand for larger screens.
• Keep the same content on mobile and desktop, because Google indexes the mobile version.
• Use a responsive layout with the viewport tag set, no sideways scrolling and flexible images.
• Make tap targets generous, around 48 by 48 pixels, with space between them.
• Aim for good Core Web Vitals and test on real phones and real connections.

Sources

• Google Search Central: Mobile-first indexing best practices
• web.dev: Responsive web design basics
• web.dev: Accessible tap targets
• MDN Web Docs: Viewport meta tag
• web.dev: Web Vitals
• W3C WAI: Understanding Success Criterion 2.5.8, Target Size (Minimum)