This blog has been adapted from our Mobile Optimization Course … sign up for it here!

You may already be tired of hearing about “Mobile-First Development.”  But I believe the problem is not the amount of ink spilled about the development paradigm, but how it’s being discussed.

The phrase itself, “mobile-first,” is so pithy and easy to grasp that it seems to work against the idea’s adoption. It leads to oversimplification. When asked the question, “What does ‘mobile first’ mean?”, it’s too easy for project leaders to say, “Yeah I get it,” and, “No, we can’t do that,” before really grappling with what mobile-first development entails. It doesn’t help that not many articles on the subject go into great detail (though there are exceptions).

What Does Mobile First Mean? Let’s Start with What Mobile First is Not

Mobile-first is not about turning your development process completely upside down or neglecting the desktop experience. It doesn’t mean literally bringing an entire app through the design phase before considering what it will look like for a desktop. And it’s definitely not about extending mobile usability principles elsewhere, such as unnecessarily hiding crucial navigation on desktop formats.

So what is it?

Mobile-first is actually more about parallel consideration than about preferring mobile.  It could more accurately be called something like “unified cross-format development” — but of course, that’s not as catchy.

Developing mobile first really means considering all formats, including various phones and tablets — and yes, multiple desktop proportions — in the very first phases of sketching and wireframing.  Crucially, these sketches should be coupled with considerations for detailed grid layouts (i.e. the strategy for “content stacking”), as well as details like what navigation will look like on the different form factors.

From here, in carrying through from design to development you can revert whatever workflows you’re used to — so long as any iterations and alterations that crop up are accounted for across all designs.  Again, it doesn’t mean blowing up your process — just adding to it.  That’s what makes it tough, and rewarding.

But…Why?

The beauty of mobile-first may not manifest itself until you’re well into the project. Anyone who’s been through a web overhaul has seen how a host of stakeholders, including marketing, IT, development, management, and sales, can derail the delicate process with competing needs.  But making hard decisions early on through the mobile-first methodology will prevent at least some of these entanglements.

Namely, you’ll force all stakeholders to consider their input and ideas through the lens of the mobile user, which introduces natural limits. For instance, the marketing team might want to pepper each page with social media icons, which can slow down mobile performance and create problems for presentation by taking up valuable screen real estate with buttons.  A demand like this may lead to time-consuming and inelegant workarounds (or an indignant social media manager) if you’ve designed desktop-first. But if instead you force the stakeholders to reckon with how those icons will appear on mobile from the very beginning, the request will find a faster and more design-forward resolution, and perhaps even an easier one.

Considering all formats in an early phase is also key for content creation. For marketers, writers, and designers alike, being able to envision how text and graphics will fit in both mobile and desktop contexts can yield better-tailored content, and reduces the amount of retrofitting needed to make the content optimally consumable on different devices.

Don’t forget: consider the methods and services

A final note on mobile first: it requires decisions to be made early on what’s going to power and deliver your app.  Of course, you’ll be deciding early on whether to use RWD or a separate mobile web app (m.dot), but there’s more to consider.  You’ll be forced to look at what application optimization solution you’ll be using, and whether you’ll be using techniques like RESS (responsive plus server-side component).  Knowing what’s on the table in terms of actually delivering experiences to your users will make the potentially unwieldy mobile-first process a lot simpler. And it opens the door to more inventive designs — again if it’s known early on what’s available.