Designing for mobile first

Reading Time: 3 minutes

We recently released a Beta version of our export health check diagnostic.

It’s a simple thing that asks you 7 questions with yes or no answers. You can run through it in 2 minutes.

We know this, because we tested it through a rapid series of iterations. We made a prototype, put it out for testing and changed it the next day based on what we had learned the night before.

In the space of a week we had something we knew worked well, that people could use comfortably and delivered something of real value.

Thing is, when we prototyped it, we did it for desktop. And we developed the beta for desktop first.

When we came to adapt it for mobile, we realised we’d made a mistake.

Text that fits comfortably on a desktop screen overflows on mobile. The context is different, so some of the instructions on how to use it don’t quite make as much sense. Headings are way too long. Graphics that are helpful on a big screen just get in the way on a small one.

As you can see, on an iPhone 5 (the modal mobile device on scottish-enterprise.com), the yes/no buttons are not immediately visible on some of the questions.

So we’ve given ourselves a load of rework to do, because it is much easier to scale up from mobile to desktop than it is to work in the opposite direction.

So, OK. We goofed, we’ll learn and do it differently next time. Question is, why did we goof this time?

It’s not like mobile first is a new idea – Luke Wroblewski proposed it years ago, we immediately recognised it as a completely sensible idea and all agreed that we should do this, then promptly didn’t.

Why?

I think it’s just habit. I’ve been working on the web for more than 20 years, almost since it was created in 1990. Desktop was all there was back then, and for most of the intervening time.

At work, and at home, I sit in front of large, clear screens and it just seems obvious to develop stuff for them.

All our digital staff are in similar positions. We design for desktop first because, well, it’s there, right in front of us.

But the web is changing, and changing faster than I think any of us really appreciate. I’ll let Luke Wroblewski illustrate it himself.

seriously? pic.twitter.com/8GoI0h6Wye

— Luke Wroblewski (@LukeW) September 17, 2015

So there we are. Designing for mobile first is an absolute no-brainer: it’s where the web is going, and going like a rocket. It also means less work adapting for desktop than the other way round.

Lesson learned.

Step away from the desktop

We need to get away from our desktops and laptops. The mobile web is a much more ascetic place; screen real-estate is small, bandwidth may be minimal, the context can be more influential.

We need to start from our phones (should they even be our phones?).

What is this like when I’m on a train and it goes into a tunnel?

How does this feel when I’m in a coffee shop?

How quickly does this load on an Edge network?

Can I do this on a bus?

This perspective forces us to make hard choices early on.

Can I shorten this sentence? Do we need it at all? How can we squeeze this heading down to 2 lines?

Is this image really necessary? Can we optimise it better? Do we actually need it?

Is all our javascript gzipped and minified? Could we use a CDN instead of serving it ourselves? Can we live without this or that library? Is our markup overly verbose, or can we tighten it? Can we identify critical CSS and include it inline?

Do I really need to gather this information in a form? Can I live without it? How few questions can I ask, not how many do I think people will put up with.

What capabilities of this device can I use? Can people speak their input to a form rather than type it?

It’s been interesting in the last few days, working with colleagues who are not used to thinking this way. You can see lights go on. The “nice-to-haves” quickly evaporate.

You become ruthless as a designer. We don’t need this: lose it. What’s the minimum we need? Do that.

If we ask these questions now, we cause ourselves a lot of pain. But it saves us from a whole lot more pain later.