I tried to answer the questions: How do different form factors, operating systems, and interaction paradigms inform the design of real I-want-to-use-it-every-day apps? How do you take the constraints (and opportunities) of differing mobile devices and design interfaces that, for the user, feel like they belong on the device and as part of their life?
And I've got the transcript below (to save you downloading it):
- I’m Rob. That’s me with your generic picture of the speaker sat on the beach, tanned, smiling, not a care in the world - as opposed to the pale, fidgety, bearded person stood before you, with a nervous smile... I come from a web background but I feel like I should boost my mobile credentials a little with people like Tom and James talking. So... I dabbled in mobile in 1998, creating a mobile gig guide in Auckland - a dynamic WAP site it was. I like to think the reason it didn’t do so well was it was ahead of its time. There wasn’t much of a market for WAP sites back then. I worked for Vodafone New Zealand for a couple year in the early 2000s. On the web team however. Interestingly, looking back, the mobile web was *never* talked about, let alone anything done about it. *Everything* was about text messaging. Before joining Ribot a year ago, I was design/UX Lead at Rightmove for 3 years, the property portal in London. One of the last projects before leaving was the Rightmove iPhone app (which just reached a million downloads the other week - I’m pretty geeked about that). So, those are my mobile credentials, if you like.
- Nowadays, I work for Ribot. Actually, if you know of Ribot you’ll know that, yes, we all have the Ribot logo as our Twitter avatar. I’m the purple-fuschia one. I like to think of us as being like Power Rangers or Ninja Turtles. Just without the costumes. We’re a small mobile-slash-touch-slash-interface *design* studio in Brighton. We do development as well (very well, I think) but our focus is definitely on designing or crafting great experiences for users of these mobile and touch devices. We do a lot of early-concept work with clients so it’s been nice to work on something that actually sees the light of day recently.
- Around the internet you can find me as @anucreative (you may recognise the bunny). All the normal social sites: Twitter, (the seemingly-defunct) Delicious, LinkedIn etc. So, that’s me...
- As you may know, Ribot recently designed a number of mobile apps for Tesco. And these are proper apps. Not just fancy catalogues but the full grocery-shopping experience: from booking a delivery slot, picking all your items, through to paying for it all. Here you see the four apps for Nokia, iPhone, a WP7 device and the big, delicious iPad. If you’re in the front row, you may be able to see that the design is rather different between the various platforms. Don’t worry if you’re not in the front row, I’m going to zoom in on each screen throughout the talk. So I’m going to discuss why there’s so much variance in the designs - how the device differences inform the design of apps.
Let's get started
- Why are these things important? Well, we want to provide the best user experience possible naturally. But improved engagement helps a business's bottom line as well. Some stats... The Vanity Fair app is averaging more than 200 minutes per issue, compared with the 65 minutes per issue that readers spend with the print edition (MediaWeek); The eBay iPhone app has higher engagement rates than the [PC Web] site, and [in particular, they] are seeing average buy sizes 50 percent higher on the iPad than on PCs (Mobile Commerce Daily)
- This is all basic UX stuff. Trying to minimise uncertainty or second-guessing. DON'T MAKE ME THINK.
- On the web, we know where search boxes go, where the basket should sit. And the logo. We know where the back button is in any iPhone app. This is really important. By re-using interactions and behaviours that people are already undertaking every day we make things easier for them. They don’t have to search the interface for the back button. Or learn a whole new navigational paradigm. They can just get on and do what they came to do. For mobile this also means respecting the soft keys, respecting the hardware keys. I will, of course, contradict myself later and show where this is not the case...
- People spend a lot less time performing functions on their mobiles, dipping in for short periods to perform small functions, consuming relatively small bits of information. Little and often. An interesting insight we got from the Tesco team (their Insight team funnily enough) is that many customers log in, choose a delivery slot, add some milk, *check out* which confirms their slot, then go back throughout the week adding to their order before it’s delivered. You can see how this plays out on mobile: While you’re on the bus home you add a few things to your order, you remember you need coffee while you’re in the Laines... These are all the same issue at heart: if a user is only using your app for a short period of time you want to ensure that the interface is simple and laid out as they expect so they can get on and do what they want quickly.
- I don’t know the *exact* numbers but I’d say there are, let’s say, a *lot* of people doing their grocery shopping online. And, as people become increasingly time-poor and as mobile access becomes more ubiquitious, this sort of functions continues to move to our mobiles. When designing for mobile, however, we can’t just take a desktop site or webapp and ‘shrink it down’. Anyway, onto the experience we were tasked with moving to mobile...
- This is the Tesco homescreen for shopping (once you’ve logged in). Now, I want to say that Tesco have a huge job on their hands here: they’ve got a mind-boggling number of customers and huge range of customer types whose needs they have to cater for. There’s a lot going on here but there’s a lot going on in your local supermarket too. And all the supermarkets are the same - they’ve got a lot of functions and information they need to get in front of their customers. Nevertheless, we have: • 22 links for actions that are immediately relevant to my shopping • 4 links for actions that are vaguely relevant to my shopping • 14 links that are promotions or have nothing to do with my shop at all • Plus my basket on every screen • And all this this is before I even start scrolling... We’ll want to simplify this...
- Shopping ends up being a reasonably simple process: 1. Reserve an available delivery slot 2. Find the products you want and add them to your basket by... 3. Once you’ve added everything you want to review your basket 4. Then pay for it all That should do us. That’s about defines our IA right there. So I want to focus on how we dealt with navigation - for the user that means how do I make my way through this 4-step process? We’ll look at each of the four platforms now and see how we’ve designed: 1. The global navigation 2. The ‘in-screen’ navigation (how do we browse through 3 levels of categories?) 3. Back buttons (once I’ve reached a dead end, how do I go back?)
- Nokia (S60 5th edition)
- Now, you remember about 3 slides ago, I said ‘re-use learnt behaviours’? We didn't *entirely' do that. Yes, I'm contradicting what I said earlier but there are a couple elements at play here: • Nokia apps have a habit of hiding functionality behind a soft-keys - we wanted to make that key functionality more accessible to the user. And to help them reinforce their mental model of the shopping process • We felt expectations had been raised by other mobile platforms (you can guess which ones) • There was an emerging breed of apps (such as Facebook shown here) improving the user experience and, in doing so, creating new defacto standards In the end, our global navigation is quite iPhone-like: you have access to the shop, your basket and checkout, and from the homescreen you can book your delivery slot (or start adding to an existing order). But these functions are always visible, as opposed to being hidden behind a ‘Menu’ button.
- iPhone/iPod touch
- I don’t want to focus on iPhone. Every UX or design talk goes on about iPhone. And I’d suggest 80% of the people in this room have one. So you all know where navigation goes on the iPhone (at the bottom). You all know where the back button is (top-right). So, for the Tesco app, our navigation is at the bottom, the header at the top. It *looks* like an iPhone app. It behaves like an iPhone app. A small note on the global nav: because we have a little more horizontal room on the iPhone compared to Nokia, we can surface the Favourites section which is first stop for a lot of users.
- Windows Phone 7
- As you’ve seen from James, WP7 has some really interesting interactions and layouts with the panorama and pivot - the panorama in particular bringing a lot of deeper information up without busying the interface too much. We really wanted to take advantage of these so people could flick through and get a real good overview of their current shopping status, if you like. (There were some early difficulties given native frameworks weren’t available, nor devices in the early days.)
- iPad, admittedly, is different: the experience is more explorative and relaxed, people spend more time on them, and designers and developers are creating new paradigms. (The newspaper and magazine products that are coming out I find particularly interesting.) There's plenty of effort being put into removing unnecessary info from the interface to allow the content to flourish. This is what we tried to do with Tesco on iPad. I’ll talk more about this in a minute...
Compare: Global navigation
- Nokia: In the end, our global navigation is quite iPhone-like: you have access to the shop, your basket and checkout, and from the homescreen you can book your delivery slot (or start adding to an existing order). But these functions are always visible, as opposed to being hidden behind a ‘Menu’ button. iPhone: And our iPhone navigation is also quite iPhone-like. Erm, not too much to say here...
- WP7: For WP7 we used the ‘panorama’ control to give users a nice overview of the app. So across the top you can see Welcome and the ‘F’ of Favourites. Swiping across shows the users’ favourites, swiping again takes them to the shop, then basket. Swiping again loops back round to the welcome screen. It’s fluid and follows the WP7 guidelines nicely. iPad: There were plenty of design iterations around the iPad. We started out with something more traditional with the bottom navigation and back button in the header but felt the chrome was really getting in the way. Removing these and allowing the header to flow into the page makes the whole experience more immersive. In hiding some fairly key elements (like the global nav) we needed to provide hints throughout the app like the 'Tap for menu' you see in the header (which you can’t see right now). These show until the required gesture is performed then are hidden. This is very much like the hint on your iPhone lock-screen. You remember how much you enjoyed that the first time you saw it...
Compare: Delivery slots
- Nokia: For choosing a delivery slot we use tabs in the Nokia app, choosing your week first, then your day, then time. Note the blue back button at the bottom there near where the 'Back' softkey would normally be. iPhone: We use a variation of the datepicker control where you first choose the day, then the time for your delivery. Again, a common interface element for iPhone.
- WP7: This is a ‘pivot’ control which is just a tab system but one which you can swipe through horizontally. Choose your week, then day and the times open up inline. iPad: We’ve got a lot more room here so can display a full matrix (which scrolls down through the popup). Beneath the header we’ve got the week filters (which effectively work as tabs). Given this is a dead-end, the close button top-left acts as the ‘Back’ button.
Compare: Inline navigation
- Nokia: A scrolling list. iPhone: Again, a simple scrolling list here also. As you tap, the next level of navigation slides in from the right.
- WP7: We use imagery in a WP7 style way here whereby as you're scrolling through the top-level panorama, when you reach Shop, you can swipe through the categories horizontally, then when at the end, you continue swiping to move onto the basket iPad: Again, we want to make use of the room we have by using bigger images. The browsing is quite special and I can't really show you in a presentation like this. Come up after the presentations and you can have a play on the iPad up here if you like.
- Nokia: With our product lists we have customised filters at the top. Items in the list you just click. Note how all tappable elements are blue. iPhone: Here we use the default iPhone filters but again, tappable items are blue.
- WP7: WP7 has a real focus on typography so you’ll notice there are no dividers in the case of lists like this and the filters are text rather than tabs or buttons. Again, it was a pleasure to design for, creating screens that feel particularly clean and light. iPhone: Big nice scrollable grid of products. Filters are off to the right but, like WP7, are just text, rather than buttons.
Compare: Navigating back
- Nokia: When you do reach a dead-end, the back button is placed bottom-right, close to where the soft-keys would normally appear. Again, note that buttons, being tappable, are also blue. iPhone: Again, not much comment needed. Back button goes top left...
- WP7: WP7 devices, by dictate of Microsoft, must have a hard back button. So, once I reach a dead-end, I hit the back button and there’s a nice transition back to my list. The hard back button makes life easier for us as interface designers because it means we can have one less button in our screens. (Admittedly, it took me quite some time to figure out to use the back button when in Internet Explorer. Every other app it felt perfectly natural, but in the browser I kept looking for a back button on-screen.) iPad: Firstly, you can swipe through products in the list that you’ve come from as if they’re enormous cards. This isn’t obvious for users so we put little hints on the edge of the popup with a nice animation tempting them to ‘Swipe...’. Once they’ve swiped once, we remove the hint and let them get on with playing with the swipe. It’s fun. Simple pleasures... To get back to your list we go to top-left again for the close button.
- We’re not starting from scratch each time: we’ve got a solid IA and we’ve got user feedback and observations. But each platform is different and so, because we want the app to feel as native as possible, because we want to reuse learnt behaviours, each app is different. And each project can inform the next as well to an extent. Throughout the WP7 project in particular, we really liked the focus on typography and reducing the number of overt buttons in the interface. And so you can see hints of this in the iPad app. ----- After each project you move to a different platform and have to get your head around different paradigms and ways of doing things.
- Wrapping up
- UX is an art and is hard Minimising the number of subconscious questions the user needs to make
- Any questions