Mobile First Is Not a Layout Decision

A team ships a responsive site. Every breakpoint behaves, nothing overflows sideways, the navigation folds into a tidy drawer. Then the numbers arrive and phone traffic behaves nothing like desktop traffic: shorter sessions, fewer completed forms, and a drop-off that begins before the first scroll ends. Nobody made a layout mistake. They made a content one.

Mobile first design is usually taught as a CSS instruction: write the narrow styles first, then add the wider rules on top. That is a reasonable build technique and it is not the decision. The decision is which sentences, which fields, which controls and which images deserve the only screen most of your visitors will ever see. Everything after that is arrangement, and arrangement is the part a product design team can do quickly once the ranking exists.

Put it harder. If the phone gets the same content as the desktop, in the same order, you did not design mobile first — you designed for a large screen and then made it fit. Mobile first is a ranking exercise before it is a layout exercise. The ranking is the work. The layout falls out of it.

Layout is the last decision, not the first

Start with the question a visitor arrived carrying, not with a grid. On a wide screen you can afford to be wrong about the order, because three things sit side by side and the eye picks between them. A phone has no side by side. It has a queue. Whatever you put third is read by fewer people than whatever you put second, and the gap between those two positions is not small.

This is why the term misleads people. Nobody argues about whether the hero should be full-bleed. They argue, or ought to argue, about whether the hero deserves the top of the queue at all when the visitor came from a search for a spare part. A page designed from the queue is a different page, not a narrower one.

A test that takes a minute: describe the page to somebody over a phone call, in order, and stop after three items. If what you said covers what the page is for, the queue is right. If you found yourself saying and then further down there is the bit that actually matters, it is not.

What gets cut is the entire exercise

Cutting is the step teams skip, because cutting means somebody loses. The events banner belongs to one team, the trust badges to another, the newsletter block to a third, and each of them can defend their block on its own terms. None of them is arguing about the page. They are arguing about their block.

The argument gets easier when somebody holds evidence about what the visitor came for. That is one of the few moments where research that could have changed the plan repays its cost on the same day: it turns a contest of opinions into a recording of a person scrolling straight past the block in question without pausing.

The cut nobody wants to make

The block that usually needs to go is not the ugly one. It is the one that exists because somebody senior asked for it, has no stated job, and occupies the position immediately after the first paragraph. On a wide screen it lives in a sidebar and costs nothing. On a phone it sits between the visitor and the answer.

Removing it is a political act, so give it a rule rather than a preference. Ours: a block earns a place above the primary action only if it changes whether somebody takes that action. Reassurance qualifies. Decoration does not. A logo strip nobody can explain in one line does not.

Hiding is not cutting

Setting display to none at a narrow breakpoint feels like a cut and is not one. The markup still ships, the images still download unless somebody was careful, and the content still exists for anything that reads the page rather than looks at it. You have paid the cost and removed the benefit, which is the worst of the available outcomes.

Worse, hidden-on-mobile is where teams quietly park the things they were told to include and did not want. Two years later nobody can say whether the phone is missing something people need. If a block does not deserve the small screen, it rarely deserves the large one either. Delete it, or give it a page of its own and link to it honestly.

Touch targets are a content decision wearing a different hat

The standard advice is to make things bigger. Correct, and incomplete. A target is small because too many targets are competing for the same band of screen, and they are competing because nobody removed any of them. Sizing is downstream of counting.

WCAG 2.2 gives a floor rather than a goal. The minimum target size criterion asks for 24 by 24 CSS pixels at level AA, and the enhanced criterion asks for 44 by 44. Read the smaller figure as the point below which you are failing, not as the size to aim for. Thumbs are imprecise, and the far corners of a large phone are reached by a stretch nobody enjoys performing while holding a coffee.

Spacing is only half of it. The other half is the label. A control called "Submit" beside a control called "Cancel" demands precision the medium cannot supply; controls called "Send enquiry" and "Keep editing" are separable at a glance and forgiving of a near miss. This is why microcopy is the cheapest conversion work available on a small screen: when pixels are scarce, the words carry the affordance.

Placement is content too. The action that matters belongs where a thumb already rests, which is not the top right corner where a decade of desktop convention put it.

The network you tested on is not the network they have

Every site is fast on the machine that built it: local, cached, wired, on a laptop with a quick processor and a warm font cache. The visitor is on a phone a few years old, on a connection that works and then briefly does not, having already spent most of their patience on whatever link sent them here.

That changes what "first" means. First is not the first section of the design. It is the first thing that renders and the first thing that answers a touch. If the hero is a video that must arrive before anything is readable, the first experience you have designed is a wait. The rendering strategy decides more here than any image tweak, which is the argument in static, server-rendered or client-side.

Two field measurements tell you whether you got this right, and neither of them is a lab score. Largest Contentful Paint says when the main thing appeared. Interaction to Next Paint says whether the interface replied when a person touched it. A page that tests well synthetically and badly in the field is a page that is fast for you and slow for them, and only one of those two facts is worth acting on.

The practical consequence is unglamorous. Fewer scripts. Images with real dimensions so nothing jumps under a thumb. Fonts that do not hold the text hostage. No third-party widget added without somebody asking what it costs and who owns it. Each of those is a content decision, usually taken by somebody who was not thinking about content at all.

The desktop assumptions that leak in

The leaks are rarely deliberate. They arrive as habits formed in a medium with a pointer, a wide viewport and a keyboard, and they survive review because on the reviewer’s screen they look fine.

• Hover carrying meaning. A tooltip that explains a field, a menu that only opens on hover, a caption revealed by a pointer: on a touch screen these either never happen or happen as an accidental tap.
• Width standing in for density. Four columns of specifications become forty rows nobody scrolls. The information did not get smaller. The container did.
• The fold as a shared idea. There is no single fold on phones. The useful question is not what sits above it, but what sits above the first thumb flick.
• Fixed furniture that made sense on a big canvas. A sticky header, a consent bar, a chat launcher and a promotion strip can leave a short screen with a slot of actual content in the middle.
• Precision assumed as an input. Drag handles, tiny dismiss buttons, sliders that need a pixel of accuracy, date pickers built around a mouse.

Overlays, and everything they cover

Overlays are the worst offenders because they are added last and reviewed least. A floating launcher lands on top of the content on a small screen, and its dismissal control is often the smallest target on the page. We have written about how that pattern behaves for assistive technology in where a floating chat widget fails a screen reader, and the small-screen failure shares a root cause: the component was designed into a corner of a wide canvas and never re-decided for a narrow one.

Forms, tables and the density habit

Forms are where the leak costs money. A desktop form can carry a field you might want later, because it sits beside three others and costs a glance. On a phone every field is a separate screen event, a keyboard change and an opportunity to stop.

The discipline is triage: ask for what you need in order to reply usefully, and defend anything beyond that out loud. Our parent company set out the fuller version in a form is a triage instrument, and shortening a form is the change that most often improves conversion on phone traffic without anyone touching the visual design.

Tables need a decision rather than a scroll bar bolted on at the end. Either the table is the content, in which case give it a scroll container with a visible edge and a caption saying what it holds, or it is a summary of the content, in which case choose the two columns that decide something and let the rest live on a detail view.

A prioritisation exercise that takes one afternoon

This is what we run before anybody opens a design tool. It needs the page, a list of everything currently on it, and one person with the standing to make a decision stick.

1. Write the visitor sentence. One sentence, in their words, describing what they arrived to do. If you cannot write it without naming three audiences, the page is doing too much and no amount of stacking will rescue it.
2. Inventory every block. One line each: what it is, who asked for it, what it is meant to cause. Blocks whose third column is blank have answered the question themselves.
3. Rank in single file, no ties. A tie means nobody chose, and the medium will choose for you by putting one above the other regardless.
4. Draw a line after three. Everything above the line justifies itself against the visitor sentence. Everything below it is later on the page, on a different page, or gone.
5. Decide the primary action once. One page, one action that matters. Secondary actions may exist. They may not look the same as the one that matters.
6. Write the order into the content model, not the stylesheet. Order that lives in a media query is invisible to editors and dies at the next redesign. Order that lives in fields survives both.

That last step is the one teams skip and later regret. If the priority order exists only as CSS, the next person to touch the page will not know it was ever a decision. A structured content workspace such as Acrosite takes the other route: editors fill the fields a page type defines, and the files it generates and commits carry the order the editor chose, so what a phone shows first is an editorial decision rather than an accident of markup.

The exercise is cheap and it is not comfortable. It ends with somebody being told their block is going below the line, which is why it works better as a scheduled hour with a decision-maker in the room than as a comment thread. When it runs inside a website build, it happens before wireframes, never after them.

A phone does not have a layout problem. It has a queue. Somebody decides the order, and if you do not, the markup will.

What the decision changes, element by element

Element by element, the shift is from an arrangement question to a priority question. The right-hand column is the one worth arguing about in a review.

Where we would start on Monday

If you are choosing one place to begin, begin on the page that already carries the most phone traffic rather than the homepage. The homepage is the page everybody has an opinion about, and usually not the page that decides anything.

Run the ranking, ship the reorder, then look at behaviour instead of at opinions. This is a case where a handful of watched sessions tells you more than an experiment you do not have the traffic to power, and we have set out how to choose between the two in five users or ship and measure.

One situation reverses the advice, and it is worth naming plainly. If the thing you are designing genuinely lives on desktop, such as a workspace, an editor or an administrative tool people sit with for hours, then designing its interface phone-first produces a weaker product. Design that for the screen it is used on. Then design its marketing pages, its documentation and its sign-up flow mobile first, because those are read on phones by people who are not users yet.

What does not reverse is the ordering discipline. Deciding what matters most, in a strict order, with one person accountable for the call, improves the wide screen as well. It simply does not punish you there, which is exactly why the habit never forms until a phone forces it. If you want a second read on a page that performs worse on phones than it should, send us the page and tell us what it is meant to cause.