Mobile-First Design in 2026: Still the Right Default?
Mobile-first used to mean designing for a small screen because that's where traffic was going. That argument is basically settled now; for most consumer products we build, mobile traffic share has been the majority for years. But we still default to designing mobile-first even on projects where desktop usage is significant, like a B2B analytics client whose users mostly work at a desk, because the constraint has value independent of where the traffic actually lands.
Designing the smallest viewport first forces prioritization that a large canvas lets you avoid. On that analytics client's dashboard, we mocked the mobile view first even though we knew fewer than 15% of sessions would happen there, purely because it forced us to decide which of the twenty requested metrics actually mattered enough to survive a 375-pixel-wide screen. That prioritization exercise made the desktop version better too, not just the mobile one.
Where we deviate from strict mobile-first now is on genuinely desktop-native workflows, things like a multi-column data grid with inline editing, or a video editing timeline, where the mobile version isn't a smaller version of the desktop experience, it's a fundamentally different, reduced one. Forcing a true mobile-first process on those features means designing a UI you'll throw away rather than one you'll progressively enhance, so we design desktop-first for those specific screens and mobile-first for everything else in the same product.
One thing that's changed since 2016-era mobile-first orthodoxy is foldables and larger phones; 'mobile' is no longer one fixed width. We now design against a small set of breakpoints within the mobile range itself, not just mobile versus desktop, because a layout that works at 360 pixels can genuinely break at 430.
So yes, mobile-first is still our default, but we hold it as a design discipline for forcing prioritization, not as an assumption about where usage lives. On projects where the workflow is inherently desktop-native, we say so upfront instead of forcing the methodology where it doesn't fit.
