Mobile first web design for B2C brands

Nearly every site built in the last decade is responsive, in the sense that it rearranges itself when the window gets narrow. Far fewer are mobile first, in the sense that the phone version was the one that was designed and the desktop version is what happens when there is more room. For a consumer business, where most first visits arrive on a phone from a social app or a search result, that distinction decides a great deal.

This is what mobile first web design means in practice, past the word itself.

Mobile first is a sequence, not a breakpoint

The practical definition is boring and useful: the small viewport is designed first, reviewed first and signed off first, and the wide layout is derived from it. Doing it the other way round produces a desktop page with things hidden, and hiding is where the argument goes. Something is always cut for the phone, and it is always the qualifying detail that answered the objection.

Designing the narrow version first forces the priority conversation at the point where it is cheap. If a section cannot earn its place on a phone screen, it is usually not earning it on a large one either, it is just less visibly in the way.

What a phone actually is, in a hand

The device in the buyer's hand is not a small desktop. It is one thumb, often the only hand free. It is a screen being read in daylight with glare. It is an interruption waiting to happen, so any state you do not save is state you lose. And it is frequently a connection that is fine on average and awful for ten seconds at a time.

Every decision below follows from that description rather than from a device width. We think that is the whole of the method: design for the circumstances, then let the breakpoints serve them.

The first screen, on a small viewport

On a phone the first screen holds a headline, a line of qualifying detail and one action, and that is roughly all. This is a constraint worth accepting rather than fighting with a smaller font. What it forces is a decision about the single thing the visitor most needs to know, which is a decision most home pages have been avoiding for years.

Two things we would insist on. The headline says what the thing is, not how it feels. And whatever sits directly below the fold should be visibly cut off by the bottom of the screen, because a section that ends exactly at the fold tells the eye there is nothing further down.

Touch targets and the standard behind them

WCAG 2.2, published at w3.org/TR/WCAG22, added several criteria that read as if they were written by somebody watching a person use a phone on a bus, and they are worth applying as design rules rather than as an audit.

• Target size: interactive controls need to be large enough to hit without precision, with spacing between them, which mostly means links in body copy should not be the primary way to do anything important
• Dragging movements: anything achieved by dragging needs a simple tap alternative, because dragging is unreliable on touch and impossible for some people
• Focus not obscured: a sticky header or a floating bar must not cover the field a person has just moved focus to, which is a common failure in mobile forms
• Accessible authentication: no puzzle in the way of a login, and never block pasting into a password field
• Consistent help: put the contact route in the same place on every page rather than only where you think it is needed

The nearest thing to a universal rule is to keep the important controls within reach of a thumb, which is the lower portion of the screen and not the top corner opposite the hand holding it.

Type, contrast and the outdoor test

Consumer sites are read outdoors more than any other kind. Contrast that passes on a calibrated monitor in a dim office can be unreadable on a phone at a bus stop, and grey text on white is the usual culprit. Meeting the contrast ratios in WCAG rather than the taste of whoever chose the palette is the fastest improvement available to most sites.

Set body text at a size that does not require the browser's zoom, keep line length short on narrow screens, and let text wrap rather than truncating it with an ellipsis. Truncation on a phone hides the words that were doing the selling, and no reader taps a shortened line to find out what it said.

The weight budget is the design constraint

On a slow connection, the biggest thing on the page decides the experience. That is almost always an image, and the fix is mechanical rather than aesthetic.

• Serve modern formats, and use srcset and sizes so a phone downloads a phone sized file rather than a desktop one scaled down
• Give every image width and height, or an aspect ratio in the CSS, so the layout does not jump when it arrives
• Load below the fold images lazily, and load the main image of the first screen eagerly with a high fetch priority, since lazy loading the largest visible element makes the page slower rather than faster
• Self-host fonts, keep the number of weights small, and set a display strategy so text is readable while the font loads instead of invisible
• Audit third party scripts by asking what each one earns, because chat widgets, tag managers and consent scripts are frequently heavier than everything the design team argued about

The Core Web Vitals thresholds at web.dev/articles/vitals are a fair way to keep score: how quickly the main content appears, how quickly the page responds to a tap, and whether things move while being read. Measure them on a mid-range Android device, not on the newest phone in the office.

Forms on a phone

A form that is mildly annoying on a laptop is abandoned on a phone. One column, visible labels, and the correct input types so the keyboard arrives suited to the field. Autocomplete attributes let the browser fill in what it already knows, which removes most of the typing from a checkout. Validate when a field is left rather than mid-word, and keep the error message beside the field it belongs to rather than in a summary at the top.

For a consumer business collecting personal data in India, the Digital Personal Data Protection Act, 2023, documented at meity.gov.in/data-protection-framework, shapes what the form has to say and how consent to marketing is recorded. The practical points are that the notice has to be plain, the consent to marketing has to be a separate and unticked choice, and the record of that consent has to exist somewhere other than in a plugin's default settings.

Navigation people can actually use

The collapsed menu is fine for secondary navigation and a poor place to keep the thing you most want people to do. If there is one primary action, it belongs on the page, visible, repeated as the page gets longer, and not behind an icon.

Search deserves a mention for any consumer catalogue. On a phone, browsing a large category through a narrow column is slow, so search becomes the primary way in. If the search returns nothing useful for a misspelled product name, the visit ends there, and the analytics will record it as a bounce rather than as the failure it was.

Test with one thumb, on a real device, with the brightness turned down and the phone in the hand you would actually hold it in. Most mobile design problems are found in the first minute of doing that, and almost none are found in a resized browser window on a desktop.

Checkout and payment

For a consumer business the checkout is where mobile first stops being a design preference and starts being revenue. Guest checkout should exist, because forcing account creation before purchase is asking for a favour at the least convenient moment. Show the total, including delivery, before asking for anything. Keep the steps few and the back button working, because people on phones use it constantly and a checkout that loses its state on a back tap loses the sale with it.

In India the payment choice matters more than in many markets, because consumers have strong habits around what they will pay with and an unfamiliar checkout is a reason to abandon. Offer the methods your customers already use, put them where they can be seen rather than behind a more options link, and remember that the redirect out to a bank or an app and back is the moment your session state is most likely to be lost.

Traffic from social apps arrives in a different browser

A good deal of consumer traffic begins as a tap inside another application, which means the page opens in that app's embedded browser rather than in the phone's default one. Those environments are not identical to the browser your team tested in. Storage can be partitioned, autofill is weaker, some capabilities are restricted, and the journey out to a payment app and back into an embedded view is the most fragile part of the entire path.

The remedies are small and specific. Open your own advertised links from the apps you advertise in, and complete a real purchase that way before launch. Do not rely on a saved session surviving a round trip to a payment provider. Offer a visible way to open the page in the real browser, and keep anything essential working without third party storage, since assuming otherwise is how a checkout works perfectly for the people who built it and fails for the people it was built for.

What to check before launch

1. Load the site on a mid-range Android phone on mobile data, not office wifi, and watch what happens in the first few seconds
2. Complete the primary action with one thumb, without zooming
3. Rotate the phone, then rotate it back, and check nothing has been lost
4. Fill the form with a name that contains characters the developer did not expect
5. Go through the checkout and press the browser back button at the worst possible moment
6. Turn the brightness down and step outside with it

None of that requires a testing lab or a budget. It requires a phone, ten minutes, and a willingness to be told something inconvenient before the launch rather than after it.

Questions people ask about this

What is the difference between responsive and mobile first?

Responsive means the layout rearranges itself to fit the screen. Mobile first means the small screen version was designed, reviewed and approved first, and the wide layout derives from it. The difference shows in what gets cut: designing wide first and hiding things for the phone usually removes the qualifying detail that answered the buyer's objection.

How large should tappable controls be?

Large enough to hit without precision, with clear spacing between neighbouring controls. WCAG 2.2 sets a minimum target size criterion for exactly this reason. The practical consequence is that a link buried in a paragraph should not be the main way to do anything important, and the primary controls belong within thumb reach rather than in the far top corner.

What slows down a mobile site most?

Usually images that were not resized for a phone, followed by third party scripts nobody has audited: chat widgets, tag managers, consent tools and tracking pixels. Fonts contribute when too many weights are loaded. Measure with Core Web Vitals on a mid-range Android device on mobile data, because the newest phone in the office will hide the problem.

Do I need consent notices on a consumer site in India?

If you collect personal data, yes. The Digital Personal Data Protection Act, 2023 requires a plain notice about what is collected and why, and consent to marketing has to be a separate, unticked, recorded choice rather than something bundled into a contact form. Read the framework rather than relying on a plugin's default settings, which are frequently written for another jurisdiction.