Answer 35 of 50
Does Mobile-First Design Compromise Desktop User Experience
It can, when teams carry mobile patterns onto desktop instead of designing for the extra room and input desktop offers. Nielsen Norman Group’s 2016 study found exactly that: on sites built mobile-first, people used navigation less on desktop than on mobile, and the researchers traced the gap to patterns ported from mobile, concluding that “the desktop user experience suffered significantly.” Mobile-first as a method is sound. Mobile-only as an outcome is the problem.
What mobile-first was meant to do
Luke Wroblewski’s November 3, 2009 post Mobile First argued that sites should be designed for mobile before desktop, partly because “Mobile devices require software development teams to focus on only the most important data and actions in an application.” The constraint was the point: a small screen forces a team to decide what matters. Nothing in that argument says desktop should then get the phone layout stretched wide.
What happened when mobile patterns moved to desktop
In Mobile First Is NOT Mobile Only, Raluca Budiu and Kara Pernice report that navigation on the sites they studied was used significantly more on mobile than on desktop, even though overall mobile navigation use was “only a modest 63%”. Their reading: the desktop designs were worse because they “were ported from a different platform”, namely mobile. The article lists the mobile patterns that made the trip:
| Mobile pattern carried to desktop | Desktop alternative |
|---|---|
| Hidden navigation behind a menu icon | Visible top-level navigation, with a menu only for overflow |
| Navigation repeated at the bottom of the page | One clear navigation location at the top |
| Menu icon in the top-right corner | Navigation where desktop users look for it |
| Search icon instead of a search box | A visible search box |
| A "More" tab like a phone tab bar | A navigation bar that uses the available width |
On the search icon, the authors write: “we’ve heard countless users complaining about having to locate a tiny icon on a large screen.” How hidden navigation performs on phones themselves, where the trade-off is different, is covered in is the hamburger menu the best mobile navigation solution.
Same content, different presentation
Mobile-first should mean the same content on every device, presented for each screen. A data table can show its most important columns on a phone with the rest already in the page and revealed on demand, more on a tablet, and all of them on desktop. Secondary details can sit behind an expandable section on a phone and inline on desktop.
What must not happen is content that exists on only one version. Content missing from the mobile version is also missing for search: Google’s mobile-first indexing guide says Google “uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.” The same guide asks sites not to lazy-load primary content on interaction, because “Google won’t load content that requires user interactions (for example, swiping, clicking, or typing) to load.” So what matters is when the hidden columns load: columns already in the HTML and only hidden until a tap need no interaction to load, while columns the page requests from the server after a tap do. What a site needs to work on phones at all is covered in can a modern website succeed without responsive design.
Add hover back, and detect it correctly
Teams that design for touch first can forget to add hover feedback back for mouse users: link and button states, submenus, image captions. Add them as an enhancement, and never put an essential action behind hover alone.
Detecting hover takes care. The W3C Media Queries Level 4 specification says the hover and pointer features describe the primary pointing device, while “any-pointer and any-hover can be used to query the properties of all potentially available pointing devices.” In practice:
@media (hover: hover)matches when the primary input can hover, such as a mouse on a laptop.@media (any-hover: hover)matches when at least one available input can hover, such as a tablet with a trackpad attached, even if touch is its primary input.
Andrés Galante’s 2017 CSS-Tricks article Touch Devices Should Not Be Judged By Their Size makes the same point about the hover query: “It’s important to notice that it only evaluates the primary input mechanism.” Use these queries instead of guessing input from screen width.
Use the width: panels and density
A phone email app shows the inbox or a message; a desktop email client shows both side by side because there is room. Mobile-first work that never adds a desktop layout ships the phone version scaled up, one thing at a time on a screen that could show three. Desktop enhancements worth planning:
- Multi-panel layouts, such as a list beside a detail view.
- Denser overviews, such as dashboards and comparison tables, for people who want to scan rather than drill down.
- Persistent elements that mobile collapses, such as sidebar navigation and preview panes.
- Keyboard support thorough enough that a mouse is never required, including shortcuts for frequent actions.
- Wider containers that keep line length readable, using columns rather than stretched lines.
Tablets need their own decisions
Tablets combine touch input with more room. Stretching the phone layout wastes the width; serving the desktop layout gives touch users hover menus that need a tap to open and another to act. Treat tablet widths as their own breakpoint, keep touch-sized targets, and test hover-dependent menus on a real tablet.
Choose the baseline with care
In mobile-first work, the phone version is the baseline and everything else adds to it. If the baseline is stripped too far, the desktop version feels like a restoration rather than an enhancement, and the phone version is worse than it needs to be. Simple marketing sites can start from a minimal phone layout; complex applications may need a richer baseline.
Progressive enhancement, which starts from a working baseline and adds capabilities, fits mobile-first. Graceful degradation, which starts from the full version and removes what a smaller context cannot support, fits desktop-first. A product can use both: core flows designed mobile-first, and advanced desktop features such as data-heavy tools designed desktop-first and then adapted.
Let your own data set the priorities
Aggregate device statistics say little about your users. Look at your own device split, and at conversion and task completion by device, by journey stage rather than overall: people may browse a catalog on a phone and configure detailed settings on a computer. Where a feature is used mainly on desktop, designing it mobile-first may create friction for the people who use it.
Test both directions
Mobile-first teams can end up checking desktop on one laptop just before release, which repeats the old mistake in reverse. Test in proportion to where your users and revenue are, but never ship a layout state nobody has checked on a real device: phones, tablets, small laptops, and wide monitors. Browser resizing does not reproduce device behavior such as touch input or high-density screens.
Questions teams ask
Our analytics show 85% mobile traffic. Do we still need to care about desktop?
Check conversion and task completion by device before deciding. If desktop visitors complete purchases or high-value tasks at a higher rate, the smaller share may carry a larger share of revenue.
Where should we invest design time, mobile or desktop?
Where users struggle and where they convert. If the mobile experience works and desktop feels like a stretched phone, fix desktop, whatever the methodology says.
Should we design mobile first or desktop first?
Mobile first works well for deciding what content matters. Desktop first can suit complex interactions that will need simplifying for small screens. In practice, you can consider both from the start rather than follow a strict sequence; what matters is that each platform gets a design made for it.
Design mobile-first to decide what matters, then give desktop a layout of its own: visible navigation and search, hover detected with the right media query, panels that use the width, and testing on real devices in proportion to where your users are.