Designing Responsive Experiences

Today, I’m going to be talking about designing responsive experiences. More specifically, I’ll be talking about how can we go beyond just making a website responsive? Because let’s face it: if a website isn’t responsive in 2015, it’s probably broken. I’ll be looking at how we can design experiences that perform exceptionally, everywhere, on any device, on any screen.

What Does Responsive Really Mean?

First, what do we actually mean when we refer to responsive design? Usually we’re referring to the use of media queries, the use of fluid grids and the use of flexible images. We use these techniques to deliver an elegant visual experience for website layouts across just about any device. Of course, these techniques are very important; they certainly go a long way to improving the experiences people have across different devices, and as designers we love them because we get to stretch our browser window around and look in wonder as our designs stretch and adapt accordingly.

Now, we could easily stop at this point and high five ourselves. We’ve sprinkled some media query magic dust on our designs, and now our design looks awesome everywhere. Job done, right?

Well, not quite. While applying media queries, fluid grids and flexible images goes a long way to improving the experience people have across their plethora of devices, there’s still a lot more that we need to consider to create responsive experiences that perform exceptionally, everywhere. I think the true challenges of responsive web design go beyond media queries and making everything stretchy. Again, that’s a start, but won’t solve a whole bunch of other problems we’re still going to face.

Namely, it’s not going to necessarily help:

• Improve our content strategy
• Make our websites perform better and faster
• Guarantee that we’re future friendly, for the inevitable influx of new web-enabled devices that will enter the market in the coming years

Here's just a few of the web-enabled devices we have to keep in mind for design. 

Why Should We Care?

Well, I could blind you with graphs showing how mobile web usage is catching up and already overtaking desktop web (fixed line) usage. I could harp on about the fabled “mobilegeddon” update and how Google says this stuff matters to how well your site ranks. I could even talk about how the landscape of who and what we’re designing for has seismically shifted in the past five years, and that it’s not finished shifting. Instead, I’ll channel Karen McGrane when I say, the reason why this stuff matters is that we simply do not get to decide how people access our content.

Content Strategy

This leads me onto the first area of focus of improving our responsive designs: content strategy. Kristina Halvorson has come up with probably the best, succinct description of content strategy:

“Content strategy plans for the creation, publication, and governance of useful, usable content. Define not only which content will be published, but why we’re publishing it in the first place."

Assumption: The Enemy of Content Strategies

For me, it’s the why part there that’s crucial. The reason is, much of our content exists purely because of assumption. Assumption is the biggest challenge we face when creating an effective strategy for any website, whether it’s responsive or not. The trouble is that it’s really easy for us to make assumptions about our users, especially when it comes to mobile.

Mobile users only need a lite version of websites because they’re ‘on the go’, right?

 For example, there’s this particularly pernicious idea that people only use their mobile phones when they are in a rush, or on the go, or are strapped for time. Now, whilst that may be true some of the time, research studies have found that 60% of smartphone data is used indoors. People could be just as likely using their mobile phone whilst sat at their desk, or chilling on their sofa, or even while sat on the toilet. One study found that 4 in 10 of us regularly use our mobile phones in the loo. (Now, I’m either one of a weird minority, or some of us just aren’t being honest about our restroom habits!)

So ultimately, the point is that it’s really easy to get your content strategy completely wrong if it’s based entirely on assumptions.

XKCD compares what users are looking for against what they're presented.

You’re probably familiar with the (above) XKCD comic that shows a Venn diagram of what’s usually on the front page of a university website compared to the things people go to the site looking for, with the only unifying piece of content being the name of the school. We’ve probably all been to a website like this before: full of irrelevant content, and the genuinely useful content is hidden away or not there at all.

This is why content parity is also so important. We need to get out this habit of assuming what a user will or won’t need – or do – based on the device they’re using. Instead we need to ensure our core content is available across any platform. So, no more proverbial slammed doors in the faces of our users, forcing them to download our app, or telling them that their screen isn’t big enough. No more presumption about what content people might find useful or usable on their phones.

Chances are, if I’m looking for a ‘help’ page, for instance, I’d quite like to access that on my phone, rather than just on a ‘full HTML site version’, whatever that means. (Credit: wtfmobileweb.com)

How Can We Avoid Assumptions?

How do we ensure our content for our responsive website is actually useful and usable? The obvious starting point for challenging assumptions about what users really need is to speak to them. Conducting research by speaking to our users, observing them, and analysing any data we have available to us begins to strip away at this veneer of assumption.

From this we can begin mapping out user journeys based on the types of tasks they come to our website to complete. Based on these user journeys, we can begin to plan what content we need and how should communicate it (our tone of voice). Chances are that we have some of the content we need already. By conducting an audit on our existing inventory of content and framing it against what content supports both our users’ and businesses’ goals, we can begin to define what content we should keep, and what content we’ll need to create.

Mobile-First Content Strategy

When we talk about responsive design, much of the time Mobile First by Luke Wroblewski is quite rightly touted as a sensible way to approach the design canvas. However, I think we should go further and consider content strategy, mobile first.

Starting with a smaller canvas gives us focus.

It allows us to focus on what content really matters and what is core to the user experience. When we start with a huge desktop canvas, because we’ve got all of this extra space to play with, we find it too tempting to keep shoving more and more content onto our canvas, eventually bloating it, regardless of how much value it adds. We end up reducing the value of our core content by surrounding it with content that, for the majority of users, probably isn’t relevant. The result is interfaces so full of noise that users struggle to identify and use the parts that are genuinely useful.

I just wanted to know what the weather forecast was, Accuweather…

As Mark Boulton rightly points out, knowing our content structure will ultimately shape our designs. Of course, there’s an important distinction to be made here. By content structure, I don’t mean you should have every single piece of content in place before designing. That wouldn’t be realistic. What I mean is you should at least know what your content is made of, what types of content you’ll need.

Because the landscape we’re designing for is constantly shifting, our content is also going to need to be more flexible than ever. We’re going to need to create it with portability in mind from the outset, because our content is going to need to reach more places and platforms than ever before.

Performance Matters

We come to our next key challenge of designing responsively: performance.

The web today.

Now, over the past couple of years, it’s fair to say that the web has had a bit of a weight problem. Since 2010, the average page size has ballooned from 700KB to just over 2,000KB (source). This roughly translates to a 185% increase in just five years. If it continues at this rate, in the next five years, in 2020, the average web page will be over 5MB – a rather scary thought.

It’s counter-intuitive as well, because research has found that 71% of mobile web users expect websites to load as quickly, if not faster, on their mobile phones compared to their desktop PCs.

Unsurprisingly then, our mobile users are impatient and don’t want to have to wait around for pages to load. Speed can and does have a massive impact on conversion rates and whether people stick around, or are driven into the arms of competitors. So, as Brad Frost says:

“It’s time for us to treat performance as an essential design feature, not just as a technical best practice.”

If we put performance at the heart of each and every design and technology decision, it’s easier to make our site faster than if we try to optimise a design later on that’s had little or no consideration for performance.

Setting Performance Budgets

One good way of making performance a priority is to set a performance budget early on, to keep the whole design process in check. The performance budget could be the maximum time it takes for a page to load; it could be the number of HTTP requests the page makes; or it could be the overall size of the page.

A good starting point for creating a performance budget is to calculate how much your site already costs for users on mobile data plans. If you already have a website, I recommend you head over to whatdoesmysitecost.com to find out – you may be surprised. Then, when you’re actually writing your performance budget, I thoroughly recommend you check out the fantastic tutorial Dan Mall wrote on creating performance budgets.

The other thing we need to consider in our designs is the perception of speed. How fast our users perceive our websites to be is as important, if not more, than the actual speed of loading itself.

As an example of this, Houston Airport found themselves facing many complaints from customers about the waiting times at the baggage carousels, despite these waiting times being well within acceptable industry limits. They found by increasing the length of the walk from the arrival’s gate to the baggage collection area by six times, their complaints about waiting times dropped to zero. This is because, despite it taking roughly the same amount of time for people to get their bags, they felt like they didn’t have to wait as long.

So we should consider how we could make the initial render of the page load faster, compared to the fully loaded page. Can we get away with delaying the loading of elements like web fonts, or advertising, or tertiary content, until after the initial render? As suggested by Google’s PageSpeed Insights, we should consider optimising our HTML and CSS so that we literally only load critical content that is visible to the user on first page load, making that first load feel as rapid as possible.

Future Friendliness

The future is already here …sort of.

When I was originally writing this, I was going to say that, in the future, people are going to be using the web on all sorts of weird and wonderful devices, and that’s why we need to think future friendly. Then I realised that the future is, in a way, already here:

People are already using the web on a myriad of different phones, tablets, laptops, desktops, watches, televisions, gaming consoles, eReaders, and even in their cars. All of this variability can make the web a pretty hostile environment to design for; we have to contend with varying browser capabilities, unreliable or slow connection speeds, tiny screens right through to huge screens, retina and non-retina displays, and different inputs like touch, gesture and even voice.

If we want to be future friendly, we’ll need to embrace all of this unpredictability – the fact that the web is universal by design – rather than trying to silo off and control how people access our content. We should constantly remind ourselves: We do not get to decide how people access our content.

Thinking Progressively

Now, does this mean our websites need to look exactly the same in every browser? Well, no, of course not. Instead, this is where progressive enhancement comes in, looking at how we can make our content available in as many locations as possible, and then enhancing and optimising the experience for our users wherever we can. To borrow from Christian Heilmann, we need to be designing our websites like escalators. Without movement, an escalator is simply a set of stairs.

How can we design with progressive enhancement? Here are a few considerations:

1. Design for touch by default – regardless of the size of screen. Screen size is not a reliable method for determining if a screen is touch-enabled. Therefore we should always, by default, make our buttons and calls to action nice and big, and with enough space between them, to accommodate our clumsy fingers and thumbs. From this base, we can then even consider enhancing the experience for touch screen users by using touch gestures like swipe, drag, or flick, where appropriate.
2. Use input types and attributes – to improve the experience of filling in forms on touch screens. Using the correct input type, such as “tel” or “email” loads the relevant keypad, and makes the form just that little bit easier to fill in.
3. Employ CSS3 for animations – to make the experience richer for browsers that can support it, while older browsers still get the functionality, if not the eye candy.
4. Consider location – as an opportunity for enhancement; can we tailor our content based on where the user is? For example, on Can I BBQ?, a fun side project we made, we determine based on the user’s location if the weather and temperature make for good barbecue conditions.
5. Conditional loading – is a great way to implement rich content like video or maps. Starting off with a link, and then only conditionally loading and embedding the full video or map interface if the browser or screen can support it, means we still have content parity. For example, on mobile phones, the content can still be opened, and the user will have the choice of whether to open in their browser or in a native app (such as YouTube or Maps) that’s better suited to handling that content on a small screen.

In Summary

The landscape we’re designing for is constantly evolving, and we’ll need to adapt to keep up with these challenges. The true challenges of responsive design go beyond media queries and fluid grids. If we want to create responsive experiences that are exceptional everywhere, we’ll need a solid content strategy, performance at the heart of all design decisions, and to think future friendly whenever and wherever we can.

Only this way can we design truly responsive experiences that we, our clients and, most importantly, our users will love.