Mobile-First Was the Wrong Lesson: Why Context-First Is What Actually Matters
June 2026 - 12 min read
Mobile-first changed how the industry builds products. It produced leaner interfaces, cleaner hierarchies, and better performance under constraint. It was a necessary correction. But somewhere along the way, a useful discipline became a reflexive rule, and a reflexive rule became a way of avoiding harder thinking. The real question was never about screen size. It was always about context.
The Origin Story of Mobile-First
In 2009, designer Luke Wroblewski published an article arguing that designers should start with mobile constraints and scale up, rather than build for desktop and scale down. The idea was genuinely important. Designing for a 320-pixel screen first forced teams to prioritize ruthlessly, cut the noise, and think clearly about what a page actually needed to do.
Google formalized it in 2015 with its mobile-friendly algorithm update, and again in 2019 when it switched to mobile-first indexing. By the early 2020s, mobile-first had become less a principle and more a checkbox. Design reviews opened with "what does this look like on mobile?" Strategic decisions got made based on whether something worked on a phone screen. Entire products were scoped around the smallest viewport.
The problem is that mobile-first answers the wrong question. It asks: what device is the user on? The question it should be asking is: what is the user trying to do, where are they, and what conditions shape that attempt?
Why Device Is a Proxy for Context, and a Poor One
Device type correlates loosely with context. A phone usually means mobile. A desktop usually means a workstation. But that correlation breaks down constantly in real use, and designing around it produces experiences that are technically responsive but contextually wrong.
Consider some of the gaps mobile-first thinking routinely misses.
The desktop user in a hurry
A procurement manager at a financial services firm opens your platform on a 27-inch monitor at 4:55pm to pull a report before a board call. She has five minutes and one specific task. Mobile-first design says nothing about her. She is on a desktop, so the assumption is that she has time and context. She does not. She needs the fastest possible path to a single action, and if your desktop experience is a content-heavy page designed to showcase features to someone on a discovery journey, you have failed her.
The phone user at a desk
A sales rep on a call pulls up a product detail page on his phone because his laptop is across the room. He is not commuting. He is not in a hurry in the traditional mobile sense. He needs depth. He needs to compare two models. He needs a data sheet. A mobile-first design that strips out detail and collapses every table into a single column to preserve thumb-friendliness is now a friction source, not a feature.
The tablet user in a meeting
A hospital administrator reviews an internal dashboard on an iPad during a department meeting. She is glancing, not reading. She needs at-a-glance status indicators, not a full data table. Her screen is mid-size. Mobile-first breakpoints give her a layout that is neither the compressed mobile view nor the full desktop view. It is the awkward in-between that was never designed with her in mind.
What Context-First Design Actually Means
Context-first design starts with a different set of questions. Rather than asking what the page looks like on different screens, it asks:
- What is the user trying to accomplish? Not what category of task, but the specific action with a specific goal.
- What conditions surround that attempt? Are they under time pressure? Are they interrupted? Are they comparing options or executing a known task?
- What do they need to succeed? How much information is required? How many steps? What might go wrong?
- What will they do if this fails? Will they try again, call support, go to a competitor?
Device enters the picture as one constraint among several, not the organizing principle. The output is not a mobile layout and a desktop layout. It is a set of intent-aware experiences that adapt to the conditions most likely to accompany a given task.
Mobile-First vs. Context-First: The Practical Difference
| Dimension | Mobile-First | Context-First |
|---|---|---|
| Starting question | What does this look like on a small screen? | What is the user trying to do and under what conditions? |
| Primary constraint | Viewport width | User intent, time pressure, environment |
| Design output | Responsive layouts at defined breakpoints | Intent-aware experiences that adapt to task context |
| Success measure | Renders correctly on mobile devices | Task completion rate across real use scenarios |
| Risk it misses | Desktop and tablet users in task-critical states | Nothing; context includes device as one variable |
| Where it works well | Content consumption, simple transactions | Complex tools, enterprise platforms, multi-step workflows |
The Four Contexts That Most Products Get Wrong
Context is a broad concept. In practice, most digital products encounter a finite set of user contexts, and there are four that most teams consistently underdesign for.
1. The completion context
The user has done this before. They know what they want. They are not browsing or exploring. They are executing. This context demands speed above all else. Minimal steps, persistent state, smart defaults, and a clear path to done. It is the most common context for returning users on task-critical platforms, and it is routinely sacrificed in favor of designs that assume discovery mode.
2. The comparison context
The user is evaluating options. They need to hold multiple pieces of information in mind simultaneously. This context demands density and structure, the ability to see two things side by side, clear differentiators, and easy movement between options. Mobile-first design almost always collapses this context into a serial, one-thing-at-a-time scroll that makes genuine comparison nearly impossible.
3. The interrupted context
The user is in the middle of something else. They are on a call, in a meeting, handling another task. They need to extract one piece of information quickly and return to their primary activity. This context demands extreme scannability: clear headings, visible answers, no buried content. It is common in professional tools and almost never explicitly designed for.
4. The high-stakes context
The consequences of a wrong action are significant. A financial transaction. A medical record entry. A contract submission. This context demands confirmation states, clear error prevention, visible undo mechanisms, and language that leaves no room for ambiguity. High-stakes contexts often appear on desktop platforms where teams assume sophistication, and they are underserved precisely because mobile-first thinking never prompted the team to ask what was at stake.
How to Apply Context-First Thinking in Practice
Shifting from mobile-first to context-first does not require discarding responsive design. It requires adding a layer of thinking before the layout decisions begin.
Map your real use contexts before you map your breakpoints
For each major feature or flow in your product, document the realistic scenarios in which a user would engage with it. What are they trying to achieve? What else is competing for their attention? What device are they most likely on, and why? This is not a persona exercise. It is a situational analysis. The output is a set of named contexts that your team can design for explicitly.
Design for intent states, not just screen sizes
Define the intent states your product supports: discovery, evaluation, execution, recovery, monitoring. Map each state to its most common context conditions. Then ask whether your current layout serves those conditions. A product that serves discovery mode beautifully but creates friction in execution mode is not a responsive product. It is a partial product.
Test in context, not just on devices
Usability testing on a device simulator in a quiet room does not surface context failures. Testing with users in realistic conditions does. This means remote unmoderated testing where users engage with your product in their actual environment, diary studies that capture how and when real use occurs, and task-based testing built around the specific jobs users come to your product to complete.
Use breakpoints as context signals, not just layout triggers
A tablet breakpoint is not just an instruction to reflow columns. It is a signal that the user is likely in a different context than either desktop or phone. Treat breakpoints as design opportunities to adapt behavior, not just geometry. Rethink what content is prominent, what actions are available, and what defaults make sense for the conditions that breakpoint most commonly represents.
Where Mobile-First Still Applies
This is not an argument against mobile design. It is an argument against mobile as the only organizing principle.
Mobile-first thinking still produces the right outcomes in specific categories. Consumer apps where the primary use case genuinely is a commuter on a phone. Content consumption products where a small screen is the dominant context. Simple transaction flows where task complexity is low and device correlation with context is high.
The discipline of constraint that mobile-first imposes is genuinely valuable. Designing for a small screen first forces clarity. That clarity should then be applied thoughtfully across the full range of contexts your users bring, not just assumed to transfer automatically at wider breakpoints.
The error is not designing for mobile. The error is stopping there.
The Organizations Getting This Right
The products that have moved furthest past mobile-first are largely enterprise tools where context failure has direct business consequences. Figma adapted its interface density based on whether users appeared to be in review mode or build mode. Notion adjusted its mobile experience not just in layout but in the actions it surfaces, based on how mobile users actually use the product relative to desktop users. Salesforce has spent years building context-aware interfaces for field sales that differ meaningfully from office configurations, based on the distinct use contexts of each environment.
What these products share is a habit of asking who is using this, where, and why, before asking what it looks like at each breakpoint. The layout decisions follow from those answers. They do not precede them.
Design for the Situation, Not the Screen
The mobile-first movement did what it needed to do. It pushed an industry that was over-designing for large screens to think seriously about constraint, clarity, and the reality of how people access digital products outside of an office.
What comes next is not a rejection of that work. It is a maturation of it. Context-first design takes the discipline that mobile-first introduced and applies it to the full complexity of real use: the enterprise user on a phone who needs depth, the desktop user in a hurry who needs speed, the tablet user in a meeting who needs a glance, the high-stakes transaction that needs protection regardless of device.
Screen size is one variable in a much richer equation. The organizations that design for the equation rather than just one variable in it will build products that work for users in the situations that actually matter.