Mobile-first design checklist: 12 things to verify before launch

What is mobile-first web design?

Mobile-first web design starts with the content and actions someone needs on a small screen. Instead of shrinking a desktop layout, you design a clear mobile experience first and expand it for tablets and desktops.

Mobile-first vs responsive design: what is the difference?

Responsive design lets a page adapt to different screen sizes. Mobile-first is an approach to creating that page: begin with the narrow layout, then add columns, spacing and optional visual details when there is room. A responsive website can be built desktop-first or mobile-first; the terms are not interchangeable.

For example, a service page might start with a short introduction, pricing and a contact button in one column. On desktop, the same content can expand into two columns with supporting imagery. Keep essential information and the contact journey available at every size.

Browser resizing is not mobile testing. Real devices behave differently. This checklist covers what we verify on every mobile-first build before it goes live.

What belongs on a mobile-first design checklist?

1. Test on real hardware, not just dev tools

Chrome DevTools device simulation is useful, but it does not replicate real rendering, real network conditions, or real touch behaviour. Test on at least one iOS device (iPhone) and one Android device before launch. The differences are real and often show up as font rendering issues, scroll behaviour, or tap target problems.

2. Check tap-target size and spacing

Aim for at least 44 by 44 CSS pixels for primary buttons and controls. WCAG 2.2's Level AA minimum target-size criterion is 24 by 24 CSS pixels, with spacing alternatives and exceptions; the enhanced Level AAA criterion uses 44 by 44 CSS pixels, also with exceptions. Check adjacent controls on a real touchscreen as well as with automated accessibility tools.

3. Verify the navigation works without a hover state

Desktop navigation often relies on hover to reveal submenus. On mobile, hover does not exist. Every navigation element must be accessible through tap alone. Test every dropdown and mega-menu on a real phone.

4. Check text is readable without zooming

Use 16px body text as a practical starting point, then check the typeface, contrast and line spacing on a real phone. Verify that paragraphs, captions, labels and form fields remain readable when users increase text size or zoom. Do not disable zoom to hide layout problems.

5. Verify images do not overflow their containers

Images set in pixels rather than percentages cause horizontal scroll on narrow screens. Every image should have max-width: 100% as a baseline. Check wide tables, code blocks, and iframes as well.

6. Test all forms on mobile

Forms on mobile have a completely different interaction model. Verify: the correct keyboard type is triggered (email fields show the email keyboard), the form is visible when the keyboard is open (a common iOS bug), fields are large enough to tap accurately, and error messages appear near the relevant field.

7. Check horizontal scroll does not exist

Any element wider than the viewport creates horizontal scroll, which breaks the entire page experience. Open the site on mobile and swipe left — there should be nothing. Common culprits: fixed-width elements, tables, code blocks, and oversized SVGs.

8. Verify sticky elements do not consume too much screen

Sticky headers and navigation bars are useful, but on a 375px screen, a 70px sticky nav removes a significant amount of content viewport. Check that sticky elements are appropriately compact on mobile and do not overlap content like modals or fixed CTAs.

9. Test on slow network conditions

Chrome DevTools allows you to throttle network speed to simulate 3G or slow 4G conditions. Load the site on simulated slow 3G and note what the user sees while waiting. Unoptimized images and blocking scripts become painful here. This test often reveals the most impactful performance fixes.

10. Verify page speed scores on mobile specifically

Use PageSpeed Insights to inspect mobile performance, distinguishing simulated Lighthouse results from real-user Core Web Vitals data when available. Mobile-first indexing means Google uses the mobile version of content for indexing; it is not a Lighthouse score threshold. Core Web Vitals contribute to Google's ranking systems, but a score of 90 or a passing assessment does not guarantee rankings.

11. Check the critical user journeys end to end on mobile

Do not just scroll through pages. Complete the actual user journey: find the service, read the page, complete the contact form. This surface-level flow catches broken submit buttons, form validation errors, and redirect issues that a static review misses.

12. Verify in both orientations

Rotate the device. Layouts that look fine in portrait sometimes break in landscape, particularly on tablets and newer large-screen iPhones. Check that images do not stretch awkwardly and text remains readable in both orientations.

Save this as a launch checklist. Running through all 12 points takes about 45 minutes and prevents the kind of mobile issues that get reported on launch day.

When should mobile testing start?

Not after the desktop design is done. The mobile-first approach means designing and building for the smallest screen first, then scaling up. Mobile testing should happen at every stage: wireframes (does the layout work?), design (does it look right?), build (does it behave correctly?).

Leaving mobile testing until after the desktop build is complete means discovering fundamental layout problems at the worst possible time.