Mobile-first design is the practice of designing and building for the smallest, most constrained context first, then progressively enhancing for larger screens and greater capability. Popularized by Luke Wroblewski, it inverts the older habit of designing a full desktop experience and then deciding what to remove for mobile, an approach that reliably produces mobile experiences that feel like something with pieces missing.
The reasoning is that constraint forces prioritization. A small screen cannot display everything, so the team must decide what matters most, and that decision improves the desktop version too, because a clear hierarchy is valuable at every size. Working in the opposite direction defers the question until the end, at which point the choices are made under time pressure by whoever is implementing the breakpoints, usually without the stakeholders who would have argued about them.
Mobile-first is also a technical strategy, not only a design one. Building the base experience for constrained devices and layering enhancements above it means the default payload is small, the core content and functionality work without heavy JavaScript, and additional capability is added where it can be supported. The reverse approach ships a full desktop implementation to every device and then attempts to hide or disable parts of it, which reduces what is visible without reducing what is downloaded and executed.
The context argument is frequently overstated and worth stating accurately. The early framing of mobile users as distracted people in transit with narrow, immediate needs has not held up: mobile is a primary and often exclusive access method for many people, including at home, and mobile users complete complex, high-value tasks routinely. What genuinely differs is the physical constraint of the screen, the imprecision of touch, the variability of connections, and the frequency of interruption. Designing for those constraints is well founded; designing for an assumed narrower intent is not, and it produces the common failure of a mobile site that omits information people actually need.
The measurable consequences of getting this wrong are visible in almost every commerce dataset, where mobile traffic share exceeds desktop while mobile conversion trails it substantially. Some of that gap is genuine, reflecting research on mobile and purchase on desktop, but a large part of it is attributable to experiences that are harder to use: cramped forms, slow pages, awkward checkout, and content buried behind additional taps. Treating that gap as inevitable rather than diagnosable is one of the most expensive assumptions a business can make.
The other constraint that mobile-first work must handle explicitly is interruption. Mobile sessions are more frequently paused, backgrounded, and resumed than desktop ones, and processes that lose state when this happens punish precisely the behavior the context makes likely. Saving form progress as it is entered, allowing a session to resume where it left off, avoiding hard timeouts that discard entered data, and supporting a return from an external application such as a banking authentication step without losing the transaction are all requirements rather than refinements. Payment flows that redirect to an authentication step and cannot recover if the user takes too long are a specific and costly example, and one that is frequently discovered only after launch.
Closing it usually requires work on two fronts simultaneously. The interaction and layout side sits with product design, while the loading and rendering side sits with web performance, since mobile devices and networks amplify every weight and blocking-resource problem. In commerce specifically, the highest-value target is nearly always the mobile checkout, which is why e-commerce engagements typically begin by measuring the mobile funnel separately rather than reading blended figures that conceal where the loss occurs.