It sometimes feels like all of my adult life, people have been telling me that “next year” will be the big year for mobile phones. In the early 2000s, I even taught myself WML, a primitive form of HTML that could make web pages appear on the first web-connect phones, expecting to become rich as the year of the mobile phone dawned. In the end, I think people had talked about it for so long that we didn’t actually notice when it happened.
During the London Olympics in 2012, more people were accessing the event’s website via their phones than via desktop computer, and that, to me, was a final indication that things had tipped. A newspaper like the Mirror now sees more traffic at the weekend from people on their phones than people sitting at computers, and on a weekday, titles like the FT and the Guardian at peak commuting times, have more mobile users than any other type of platform. As publishers, we just have to accept that this shift in consumer behaviour has happened, and get on with designing for it.
Over the years, I’ve had the opportunity to design interfaces and services across a range of phone and tablet devices, and along the way I’ve picked up some key lessons in what to do, and what not to do, in order to produce an excellent user experience on smartphones.
A quick step back - what is user experience?
“User experience” is one of those perplexing terms if you don’t actually work in the design industry. It sounds both vague and all-powerful at the same time. I like to describe it this way - the “user experience” is what someone feels about your product. The visual design is colours and typography and the way it looks. The interaction design is how things behave when you tap them or press them or click them. The information architecture is how the information is described, organised and presented to the user. And the content strategy informs the type of content that the user has access to. But the “user experience” is the sum of all those parts, and more. Does an app load quickly, does it feel snappy when you swipe down or scroll, does it respond quickly to the user? All of these things add up to whether a user will enjoy and recommend your product, which should be the ultimate goal of most digital projects.
So, what should a business look for when designing apps and services for smartphones. I think these five aspects are crucial:
1. Simplicity
Life is complex. Technology is complex. Our phones are little super-computers in our pockets, with processing powers that the scientist who sent man to the moon in the 60s could only dream of having. And so the temptation to over-complicate applications, products and services is ever-present. It needs to be resisted at all costs.
If you think about the apps that you use most often on your own smartphone, you’ll almost certainly come up with a list of apps that do one thing, and do that one thing very well. On Apple’s iOS platform, Mail, Contacts and your Calendar are all separate apps, with entirely separate functionality. Compare that to the scattergun desktop approach of Microsoft Office, which wants to manage all those things, and has a “to do” list task management function bundled into it as well.
A major trend in web design over the last couple of years has been “responsive web design”, where the new technical capabilities of HTML5 allow us to detect the size of the screen that a page is being viewed on, and display a version of it sized and adapted accordingly. It marks an end to the idea of having a separate “desktop” and “mobile” version of your site, and I have found, as a designer, that it has become a very powerful tool.
If you design for the smaller phone screen, you know you only have a limited amount of real estate to play with, a small number of pixels you can shape. You simply can’t put 17 buttons into an interface, and link to every section of your publication. You are forced to choose. I love this. As soon as you are forced to choose one or two features or one or two sections as being more important than any other, you can begin to address the extent to which you really need to build these features into your app or service. It can certainly help you prioritise the effort you put into building them, and the order you want your technical team to deliver them.
2. Download sizes… and download continuity
One thing that needs to be considered in technical planning very carefully is the size of downloads that you are expecting people to have delivered to their phones.
Responsive design means having one set of code delivered to all devices, but if, for example, you are using smaller versions of images for the phone than the desktop, you are wasting bandwidth by delivering the high resolution versions. That is probably delaying your page displaying over poor connections, and possibly eating into your user’s data allowance and costing them money unnecessarily.
If you are shipping an app, work out how much data can be included in the app. I remember downloading an app to follow Euro2012, and opening it up for the first time on the London Underground where I had no data connection. The app had been delivered without any of the actual fixtures for the tournament included in the code. It wanted to connect to the internet to download a bunch of data. Well, as a user, the reason I had opted for an app was to have it as a self-contained unit on my phone. If I had the internet online, there were a million places I could go for the fixtures.
Don’t just think about what happens on the first run, also think about what happens to your app if there is limited or no connectivity. Some apps stop you at the front door if they can’t get online, as their performance relies on this. Be careful of making this too aggressive though. The Sky Sports Football app frequently tells me it doesn’t have an internet connection or enough bandwidth to function, when other apps and the web browser on my phone are working fine.
3. Apps within apps within apps
How often do you follow a link from your email? Or Facebook? Or Twitter? When you do it on your smartphone, the chances are a lot of the time that you end up viewing the content framed as a “web view” within the app you were originally using. You might think you are designing for an iPhone screen, but actually a lot of the time you are designing for around four-fifths of the iPhone screen. The rest will be taken up with furniture put in place by another app to help the user navigate back to what they were doing before they visited your site.
This has a couple of implications. First of all, be careful of trying to use fixed layouts with navigation anchored to the top or bottom of the screen. This might make sense to you when your site is viewed in isolation, but in the context of someone else’s app, it is yet more furniture taking away from the main content area.
Another thing to beware of is using splash pages to urge the user to download your app instead of “merely” visiting your website. I can’t count the number of times I’ve clicked a link included in a LinkedIn email whilst using the Gmail app on my phone, only to find myself faced with an advert for the LinkedIn app (which I already have installed), framed underneath the Gmail “back” button. And once you bypass it, you have to sign in, and then the website has lost the context of the link you originally clicked. Think about detecting when your site is being visited from within an app, and respond accordingly, dropping any promotional interruptions.
4. User experience also means customer service
You’ve probably got some kind of customer service department. They probably deal with lost payments or, as I once heard Mary Beth Christie of the FT say, handle people upset because their newspaper arrived a bit soggy. Digital customer service is a world apart from that. Mary Beth is head of product management at the FT, and she said now they have to be equipped for people calling and saying that “I can’t get your web video to work on my iPhone 4S which I’ve recently upgraded to iOS7”.
If you are truly serious about providing a great user experience, then users need to have a great experience when things go wrong - or at least something that doesn’t aggravate them further. This will need to be cross-channel. People expect queries to brands via social media channels like Twitter or Facebook to not only be acknowledged, but acted upon. And quickly.
5. Everything has to work on phones
Finally, the key for me is that absolutely everything has to work on phones. And I mean everything. It is no good saying that things are too tricky to design or code, or that “nobody will ever want to do that on their phone”. Frankly, they will want to do it on the nearest device to hand, and sometimes they will have no choice but to use their phone. You need to test applications and websites on a wide range of platforms and devices to ensure that you aren’t excluding potential customers or readers through poor design or coding.
For a lot of 2013, I was working on a project called UsVsTh3m for publisher Trinity Mirror. We insisted that everything we did, whether it was a blog post, quiz or interactive game, worked on phones. It was a pain for our developers, and more than once, the fact that mobile was making up much less of our audience than anticipated caused people to question the strategy.
But, in November, we had a massive viral hit with our North-o-meter, which quizzed you on how northern you are. The peak time of usage was 11pm on the Friday night it launched, over 60% of the audience were on their phones (and possibly just leaving the pub), and nearly all the sharing was coming via Facebook. If we hadn’t spent all that time optimising for that situation, we would have thrown away over half our audience at our busiest time. Don’t throw away your mobile audience.
6. Always be testing with real users
OK, I said five things. I lied. Here’s a sixth. Always be testing with real users. We know our businesses. We understand how we structure our information. We have expectations of user behaviour. And yet every time I watch someone using something I’ve built or designed, I learn something more about the possibilities for behaviour that I’ve created. The set of assumptions and fresh eyes that a bunch of users bring to your site or app is going to be totally different to the way that all the people on a project think about it. It can be enlightening, help you solve problems, and sometimes even save you money. I ran one set of user sessions last year that convinced us that some expensive-to-build advanced functionality was simply unwanted by the target audience. So we saved time and money by ditching it before we’d invested in developing a feature that nobody would want.
What’s next?
One of the joys of designing for digital is that there is always something new around the corner. And one of the pitfalls of designing for digital is… well, you can see where I am going here. It is that there is always something new around the corner. I’m already starting to think about what kind of designs and user experience will publishers want to develop and deliver to audiences who are wearing computational devices like Google Glass and smartwatches.
