A site gets drawn on a 27-inch monitor, approved by a director on a laptop, and then viewed one-handed on a cracked screen on a train. The gap between those three situations costs real enquiries. Here is what designing mobile-first actually means: the order you build layouts in, the tap sizes that work, why scroll smoothness beats animation, and how to verify all of it without relying on the browser emulator.

Mobile-first is not "shrink the desktop"

Adapting downward always produces the same outcome: everything from the desktop survives on the phone, just stacked. Six sections become six screens of scrolling, the menu hides behind three lines, and the primary button ends up on screen four. Designing upward forces an honest decision at the start — which of this is genuinely needed.

• The constraint acts as a filter. At 375 pixels wide you physically fit one heading, one paragraph and one button. Whatever fails that test was usually not needed on desktop either.
• Priority becomes visible. The order of sections in a mobile layout is your funnel. If price ended up below the company history, you have just spotted a positioning problem.
• Performance is designed in. When the layout starts from a phone, heavy background video and parallax never make it into the project — they simply are not in the source version.
• Search evaluates the mobile version. What the phone sees is what gets indexed. Content dropped from mobile is content you hid from search.

The working order that actually holds

1. 1

   One screen, one decision

   For every screenful of scroll, write down which action it asks for or which objection it removes. A screen without an answer gets deleted, not "refined".

2. 2

   The 375-pixel layout comes first

   That is the lower bound still in common use. If the composition survives there, it survives at 430 and at 1440. The reverse route never works.

3. 3

   Two breakpoints instead of five

   In practice, transitions around 640 and 1024 pixels are enough. More breakpoints mean more states to test and more places where the layout falls apart.

4. 4

   Type and grid before colour

   Base text from 16 pixels, line height 1.5, line length 45–75 characters. On a phone this is what decides whether the text is read at all.

5. 5

   Element states as their own screen

   Empty lists, long product names, form errors, loading placeholders. Missing states are the main reason a finished site looks worse than the mockup.

Fingers, thumb reach and forms

A cursor is accurate to one pixel; a fingertip to about seven millimetres. That single physical difference produces most of the rules below.

Scroll smoothness beats animation

The most common complaint about mobile sites is not "it looks bad" but "it stutters when I scroll". Three things cause it nearly every time: backdrop blur, large-radius shadows, and endless animations the browser repaints every frame. On a flagship phone none of that shows. On a mid-range device three years old it is the difference between 60 and 25 frames per second.

• Backdrop blur is the most expensive effect on the list. A single translucent blurred element in a sticky header can consume half your frame budget while scrolling.
• Animations that never stop — pulsing buttons, shifting gradients, rotating shapes. They keep running for as long as the page is open, including when they are off-screen.
• Animating the wrong properties — move transform and opacity. Changing width, top or margin forces the browser to recalculate the whole layout.
• Images without dimensions — with no explicit width and height, content jumps during loading, which directly damages your layout-shift score.

/* Keep expensive effects for pointer-capable desktops,
   and always honour the system motion preference */
.panel {
  background: rgba(12, 14, 18, 0.92);
}

@media (min-width: 1024px) and (hover: hover) {
  .panel {
    background: rgba(12, 14, 18, 0.6);
    backdrop-filter: blur(12px);
  }
}

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

Speed and smoothness are two different problems with two different metrics. The first is measured by how long the main element takes to appear, the second by how long the page takes to respond to a tap. Both are broken down separately in our guide to Core Web Vitals, and the practical optimisation order is in the piece on website loading speed.

How to verify instead of hoping

The font-scaling item is not box-ticking: text zoom and contrast overlap with accessibility requirements, and fixing them after launch costs twice as much. What specifically to check is collected in our website accessibility guide.

Frequently asked questions about mobile-first design

In short

• Mobile-first is an order of work, not a set of media queries. Start the layout at 375 pixels or the phone inherits a cropped desktop.
• A finger needs a 48-pixel target, inputs need a 16-pixel font, and the primary action belongs in the lower third of the screen.
• Scroll smoothness is worth more than animation: strip backdrop blur and endless effects from mobile first.
• The mobile version is the indexed version, so content removed from it disappears from search too.
• Verify on a real mid-range phone, on a throttled connection, with the system font scaled up.