Mobile First Design

011 min

Why designing the desktop first goes wrong

Picture a team that has built the account page of a subscription app on a wide desktop screen. The page has a long menu down the left side, a table of past invoices, and small tooltips that appear when the mouse pointer rests on an icon.

Late in the project, someone asks for the phone version. The team folds the menu into a hidden button and wraps the table. Then they find that the tooltips cannot work on a touch screen, because a finger has no way of resting on an icon without tapping it. The phone page ends up as a shrunk copy of the desktop page.

Most people who open this page want one of three things: change their plan, update a card, or pause the subscription. On the shrunk page, each of those is now several taps away.

The order of the work caused this. When the largest screen comes first, every item gets in, and cutting later is hard because each item already has someone who wants it kept. Mobile first design reverses the order. The team starts with the phone and treats each larger screen as an addition.

022 min

Where mobile first design comes from

The method has a known author, and it rests on an argument rather than an experiment. Luke Wroblewski, a product designer, published a post called Mobile First on 3 November 2009. No lab study proved the method. He reasoned from how quickly phone use was growing and from what phones are like to build for, and many designers found the reasoning convincing.

His post gave three reasons. The first was growth: phones were reaching more people than any earlier computing device, so a team that ignored them was ignoring a very large audience.

Wroblewski's second reason was that a phone screen, at the time 320 by 480 pixels, leaves room only for the most important data and actions, so the team has to rank them. Teams that start from the phone, he argued, end up with a product built around the key tasks people want to finish.

032 min

How mobile first works

Return to the account page. A mobile first team starts by asking what people open the page to do, and then ranks the answers. The three tasks from the first section go at the top, in a single column, each reachable in one tap. Everything else moves below them or behind a clearly labelled control, a pattern covered in progressive disclosure.

Once the phone version works, the team widens the screen in the design tool and looks at what the extra space allows. On the wide screen, the team adds the side menu and the extra settings back. The phone version is the core, and each larger layout adds to it.

This order is called progressive enhancement: a basic version that works everywhere, then additions for devices that can use them. The older opposite is graceful degradation, which starts from the full desktop version and removes parts for smaller or weaker devices.

How it shows up in the code

The same order is used when writing the page's CSS, the language that styles a web page. The rules written without any condition describe the phone layout. The team then adds media queries, which are rules that apply only when the screen is at least a stated width. The widths where the layout changes are called breakpoints.

MDN, the Mozilla web documentation, describes the common pattern as a simple single column for narrow screens first, then more columns once the screen is wide enough. Responsive design covers fluid grids, flexible images and media queries in full. Mobile first adds one decision to it: which size is written first.

042 min

Designing for fingers, thumbs and one hand

A narrow layout is half of the change. The other half is how people operate a phone. A mouse pointer can rest on an icon and show a tooltip, but a finger cannot rest on anything without tapping it. Anything that appears only on hover is out of reach on a touch screen, so mobile first teams remove hover-only controls and make every control something a person can tap.

Hands matter too. The designer Steven Hoober and a few other researchers made 1,333 observations of people using phones on streets, in airports, at bus stops and on trains, over two months that ended in January 2013. Of the people he saw touching their screens, 49% used one hand. The other 51% used both hands, either to type with two thumbs or to hold the phone with one hand while tapping with the other.

That split affects where controls go. A thumb reaches some parts of a screen easily and others hardly at all, which is the subject of thumb zone.

051 min

Mobile first indexing in Google Search

Mobile first has a second meaning in search. Google uses the phone version of a page, fetched by its smartphone crawler, to decide what the page contains and how to rank it. This is called mobile-first indexing. A site whose phone page holds less than its desktop page is ranked on the smaller amount.

Content that exists only on the desktop page

Suppose the account page team cut the table of past invoices from the phone version to save space. Google reads the phone version, so the table counts for nothing in search. Google advises site owners to make the phone version hold the same primary content as the desktop version.

The phone page does not have to look the same. Google's guide says a different design on mobile is fine, for example moving content into accordions or tabs. The content has to be there, though.

How long the switch took

The change was slow. Google began mobile-first crawling and indexing in 2016, and on 31 October 2023 it announced that the move was complete. Sites moved over one at a time, so for several years some were indexed from their phone page and others from their desktop page.

061 min

Mobile first and accessibility

A narrow layout also helps people who never use a phone. Some people with low vision zoom a desktop page to 400%. At that zoom, a window 1280 pixels wide shows the same amount of page as a 320 pixel window.

WCAG 2.2 success criterion 1.4.10, Reflow, treats a width of 320 CSS pixels as equal to a window 1280 CSS pixels wide at 400% zoom. A page whose base layout is a single column for a narrow screen already fits that width, so the same CSS serves the phone user and the person who zooms. The wider subject is covered in accessibility.

072 min

Where mobile first goes wrong

Suppose the account page team now ships the phone layout on every screen. On a large monitor the menu is a small icon in a corner and most of the page is empty. This has been measured on real sites.

In 2016 Nielsen Norman Group, a user experience research firm, tested 179 users on six sites: 7digital, BBC, Bloomberg Business, Business Insider UK, Supermarket HQ and Slate. Several desktop versions had borrowed phone patterns, such as a menu hidden behind an icon and a search icon in place of a search box. Nielsen Norman Group concluded in 2016 that the desktop versions of the sites it tested had suffered because they were likely built mobile first.

The firm's advice was that content and features can match across devices while the interface does not, because each platform has different capabilities. The lesson is not to avoid mobile first. Each larger layout is a design step of its own.

Those figures are StatCounter's page views across its own sample of sites. Check your own analytics before assuming. A tool people use at work may see mostly desktop visits, and then the wide layout deserves more design time than the method's default suggests.

081 min

Mobile first design vs. nearby concepts

Four neighbours are often mixed up with mobile first. They differ on one axis: the question each one answers.

A team can be responsive and mobile first, responsive and desktop first, or neither. The two ideas answer different questions, which is why they are used together so often.

091 min

Applying mobile first

Pick one product area and work through it in this order this week.

1. List the tasks people come for, using analytics or support tickets, and rank them. Keep the top three to five.
2. Design the phone screen with only those tasks, in one column. Put the most-used action where a thumb reaches it.
3. Set tap targets by use: at least 24 by 24 CSS pixels everywhere, and larger for the main action. Remove anything that works only on hover.
4. In the CSS, write the unconditional rules for the phone and add media queries for wider screens. Set breakpoints where the content starts to look wrong, not at the width of one particular device.
5. Design the wide layout as its own step. Ask what the extra space makes possible, and give wide screens the navigation that suits them.
6. Check that the phone page holds the same primary content as the desktop page.
7. Test on real phones with usability testing. A browser window resized on a desktop does not show how a thumb behaves.

The decision to make first is the ranking in step 1. If the team cannot agree on the top tasks, no layout will fix that.

?4 questions

Questions people ask

§13 sources

Sources