A Real-world Survey of “Mobile First”

The web in undergoing a revolution, and the future is going to be mobile. Disruption, smartphones, native vs HTML5… yeah, we know, welcome to 2009!

By now, the mobile web has been so thoroughly written about by pundits that it’s hard to think of something original to say about it.

Similarly, the technical side of thing is also well-covered: you’ll find guides on how to make pretty much anything responsive and mobile-friendly, even email newsletters.

But although there’s no lack of editorials or tutorials on the subject, this still doesn’t tell us what people are actually doing.

Are these techniques well on their way to becoming mainstream among designers? Or are they still the exclusive domain of early adopters?

Mobile First

To find out, I asked designers on Folyo and Twitter to answer a short survey. Specifically, I wanted to find out if designers have adopted “mobile first” design, and what kind of mobile strategy they usually employ.

In case you’re not familiar with it, mobile first advocates starting from the mobile version, and then extrapolating the desktop version from it (instead of condensing the desktop version into its mobile counterpart like it’s usually been done).

The rationale is that by focusing on the mobile version first, you’re forced to make hard choices towards simplifying the design, and those choices will benefit the desktop version as well.

The first question I asked was simply if people are familiar with the concept of “mobile first”. As you can see, the overwhelming majority of respondents are somewhat familiar with the concept:

Are you familiar with the concept of “mobile first”?

So if designers know about it, the natural follow-up is to ask if they practice it:

In what order do you design the multiple versions of a site or app?

The results didn’t really surprise me: when asked if they preferred a “mobile first” or “desktop first” approach, the majority of people answered that it depended on the project.

Which is the only answer that really makes sense, when you think about it. “Mobile first” might make a ton of sense for a photo-sharing app, but what about a database administration app?

So I think the mobile first movement has its role to play in counterbalancing the “desktop first” philosophy that has existed by default up to now, and leveling the playing field a little.

But it shouldn’t be taken literally as saying all sites and apps need their mobile versions to be built first.

Mobile Strategies

But whether you go mobile first, last, or something in between, the question still remains of knowing which mobile strategy to pick.

There are currently four main mobile strategies:

  • No mobile version
  • Responsive site
  • Separate mobile site
  • Native app

(Note that these strategies are not incompatible. For example, you could have a responsive site, and a native app too)

So I asked designers which strategies had been most commonly employed in the projects they’d worked on in the past two years.

Here they are, from least to most frequent (a low score means more frequent):

How often did projects use a native mobile app?

The least used strategy is native mobile apps. This might come as a surprise, but a very important fact usually lost in the “HTML5 vs native apps” debate is that developing a native app requires a vastly different skill-set from building a website, which means one more person to hire.

So the fact that native apps are not often used shouldn’t be seen as a reflection on their worth as a mobile strategy, but simply a consequence of the amount of resources needed to build one.

How often did projects use a separate mobile site?

Full-featured mobile sites seem to be on their way out: although they’re usually simpler to develop than native apps, from a design point of view they require almost as much time and effort, and sometimes more since they can’t rely on native UI elements.

How often did projects use responsive design?

On the other hand, I believe responsive design is gaining acceptance as the minimum mobile design strategy.

And while designers often complain about the amount of extra work required to make a site responsive, it’s still a lot less work compared to the previous two strategies.

How often did projects have no mobile version?

Of course, the most common strategy by far is simply having no mobile version at all. I don’t think this means companies don’t see the value of a mobile version: it just means they often don’t have enough resources to build one.

After all, the biggest obstacle to the adoption of new techniques is usually the amount of extra work it takes to implement them, independently of their inherent advantages.

So I think this is why it’s so important that thanks to responsive frameworks like Twitter Bootstrap and ZURB Foundation, and grid systems like Gridpak and Susy, responsive design is becoming easier to implement every day.

And of course there will always be the question of knowing if you need a mobile version at all: having a mobile version is still often more “nice-to-have” than “must-have”. Don’t believe me? Just take a look at the Apple site on your iPhone!

What About You?

There’s also a lot of questions left unanswered: which tools do you use to help you implement these strategies? And when is each strategy appropriate?

And the biggest question of them all (which will be the focus of another article), how do you charge for all this, and how much? For example, should a responsive site cost as much as a mobile and desktop sites together? And are clients ready to pay for it?

I would love to know how you deal with these problems yourself, so please give me your opinion here in the comments or over at Hacker News.

Oh and if you’re reading this on a mobile device, sorry about this blog’s somewhat ironic lack of a mobile version. It’s coming soon, I promise!