The article appears in the April 2011 edition (#213) where I step through how we took Jerome‘s lovingly-crafted design to create the tasty, swipeable interface on Just One More.

Over the next couple months I’ll be adding a few more articles here about Sencha and PhoneGap – little things that tripped me up or took me a while to figure out.

As for the article itself, if you squint your eyes you can just about make out the first page here. Otherwise you’re going to have to buy a paper copy or digital copy via Zinio.

Update: Apple features Just One More in New & Noteworthy

This won’t work:
.mydiv { background: rgba (0, 0, 0, 0.5) }

(Note the space after ‘rgba’). Strange but true.

And I’ve got the transcript below (to save you downloading it):

1. Hello

2. Introduction

3. 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.

4. 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.

5. 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…

6. 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.

7. Let’s get started

8. 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)

9. This is all basic UX stuff. Trying to minimise uncertainty or second-guessing. DON’T MAKE ME THINK.
10. 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…

11. 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.

12. 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…

13. 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…

14. 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?)

15. Some examples

16. Nokia (S60 5th edition)
17. 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.

18. iPhone/iPod touch
19. 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.

20. Windows Phone 7
21. 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.)

22. iPad
23. 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…

24. Compare: Global navigation

25. 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…

26. 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…

27. Compare: Delivery slots

28. 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.

29. 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.

30. Compare: Inline navigation

31. 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.

32. 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.

33. 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.

34. 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.

35. Compare: Navigating back

36. 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…

37. 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.

38. 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.

39. Wrapping up
40. UX is an art and is hard

    Minimising the number of subconscious questions the user needs to make

43. Any questions

UCD methods list (click to embiggen)

Download

• UCD methods list (188KB png)

All this is about setting very clear expectations before any design work is undertaken. It ensures the business knows why we’re taking a UCD approach, how long it will take and what it will cost.

Transcript

1. User-Centred Design:

   Building an effective, efficient and engaging user experience

2. What is User-Centred Design?
   An approach that involves the user throughout the design and development process
3. Understanding users’ needs
   By understanding user’s needs we can design products that are:
   • Usable: Effective, efficient and satisfying to use
   • Desirable: If a product is desirable to a user, they will be motivated to learn how to use it
4. Involve users early
   By involving users early in the process we aim to ensure we build the ‘right’ things and minimise the need for high cost changes late in the project
   Build the right thing. Build the thing right.
5. What are the benefits?
   • Development: Reduce time and costs
   • Usability: Improve efficiency and effectiveness
   • Conversions: Increase benefits to agents
   • Overall value: Improve user experience

6. How do we ‘do’ UCD?

   How will we test? When will we test? Who will we test with?

7. Make sure we’ve got the right tools
   There are various methods we can use to talk to, observe and interact with users throughout the design process.
8. [Picture of UCD methods list]
   We’ll talk about some of these methods at the end. A full list of methods and their application is on the Design Twiki
9. Which methods do we choose? 
   The recommendation engine allows us to create recommendations for your project
   Working with BAs and BOs we’ll generate two options with costings and timeframes
10. [Picture of recommendation engine]
11. How do we find users?
    • Internal users: Marketing, CST
    • Existing users: Rightmove Improvement Program
    • New users: Trade shows, cafes, external agency
12. Who’s involved?
    • Design
    • Marketing
    • Business Analysts
    • Analytics & Optimisation
13. How do we measure success?
    • Conversion rates
    • Development time & cost
    • Confidence (Are we certain the product works well?)
    • Customer feedback
    • System Usability Scale (SUS)
14. So, what are we actually doing?
    • Bunnyfoot: Usability testing on main flows with eyetracking
    • Beta feedback: Analyse comments to inform future projects 
    • Trialling recommendations and methods on upcoming projects

15. Preparing for UCD

    How we’re getting Rightmove ready for UCD

16. Training programme
    • 1-hour intro to User-Centred Design
    • Weekly practical sessions on methods for user testing: Paper prototyping, user observation (including Silverback), interviews, surveys, multivariate testing
17. Rightmove Improvement Programme
    • We’ve contacted registered or active users in 12 key locations
    • As part of the programme they will help us with surveys, usability tests and preview beta functionality
    • If successful, we’ll widen the net to include non-Rightmove users

18. Let’s look at methods

    A quick overview of key methods, their strengths and weaknesses

19. Paper prototyping
    • Lo-fi mockups on paper with key interactions
    • User interacts with the paper mockups, verbalising their thoughts and what they’re looking for
    • Used early in design phase as quick changes can be made with minimal development
    • Users feel they can still have input into the design
20. User observation
    • Otherwise known as ‘usability testing’
    • Users interact with a working version of the site using the ‘think aloud’ protocol
    • Used during or after development phase
    • Users are interacting with real data and can use real tasks
21. Cognitive walkthroughs
    • After compiling a task analysis, tasks are broken down into sub-tasks and the project team questions each step
    • Used in the research phase to compile potential issues 
    • Generates results quickly for very low cost
22. Expert reviews
    • Measure each page against accepted heuristics (rules of thumb)
    • Conducted by ‘expert’ not working on the project
    • Used in design or development phase
    • Very cost-effective but users are not directly involved
23. Multivariate testing
    • Develop multiple versions of the same page or interaction and measure key metrics to see which is most effective
    • Used in release phase but must be developed in design and development phases
    • Absolute, quantitative data on usage
24. Build the right thing. Build the thing right.

What is it?

Two timelines showing the steps we intend to take, the costs involved and how long it will take, based on the two recommendations we’ve come up with. You can see an example below:

Screenshot of UCD estimate (click to download Word doc)

How do I use it?

This should be quite straightforward: for each recommendation just add your chosen methods to the Word doc with their duration and costs, and add your normal design tasks (sketching, creating lo-do mockups etc) in between. Add it all up and present these to the project owner. This transparency helps them understand what steps, costs and time are involved.

Why two estimates?

This begins a better conversation with the project owner: “Would you like to involve users in this way or this way?” rather than “Would you like to involve users?” (which is all too easy to say no to). The question should not be “How much money or time do we have?” but “How important is it that we understand our users and we build the ‘right’ product for them?”.

Download

• UCD estimate (24KB Word document)

Previous iterations

Our first iteration just listed the time and money costs without showing the traditional design tasks (such as creating hifi mockups). This made the timelines ambiguous as the user involvement was being taken out if context of the design process as a whole. So we added these traditional tasks in and now the whole thing is a lot clearer.

Okay, it’s just a spreadsheet. And it doesn’t even have any macros. But we find it very, very useful. It just lays out the cost in time and money for each of the UCD methods.

The columns are as follows:

• Method
• Source: Who’s involved in the test. This can be:
  • Internal: We do it with internal Rightmove staff
  • In-house: We do the research in-house but with real users
  • Agency: We let an agency do the work for us
• Users: Number of users covered by the cost
• Cost: Includes things like the monetary incentive for users (well, vouchers)
• Days: Number of human-days involved including preparation, administration, facilitation, evaluation, and analysis
• Duration: How long it will take from beginning to end (recruiting to analysis)

Note:  All prices are in GBP. And some pricings are guesstimates but it’s enough to start a conversation.

How do we use it?

When we have two recommendations and know which UCD methods we want to use for a project (using our UCD recommendation engine), we refer to this spreadsheet to work out what the costs will be. For example, say we decide we’ll need to do some paper prototyping with external users. The spreadsheet tells us this will cost:

• £300 in incentives
• 6 days of work
• over the course of 4 weeks

Download

• Costs of UCD methods (16KB Excel doc)

What next?

Given the recommendations and the costs involved we can then create our UCD estimates at the beginning of a project and start setting expectations with the project owner.

The UCD recommendation engine. Okay, so the name is horrible. It conjures up images of enormous computational machines with punchcards and geeks in white labcoats.It was one of those cases where the first name given to it stuck.

It’s much, much simpler than that though. It’s three simple questions to make sure we include users in the right way for any given project. As with so much in the UX field, a lot of this is just common sense.

UCD Recommendation Engine (click to embiggen)

How do I use it?

So, the basic questions with respect the upcoming project, are:

1. Do we understand our users’ needs?

   Hint: Unless you’ve done reasonably extensive user research earlier, the answer will be ‘non’. But that’s not necessarily a bad thing – it means you have the opportunity to get out and talk to your users.

2. Does the functionality exist already?

   This can be your own product, a competitor’s, or something from an unrelated industry. For example: A login flow – you can test working version of your own login, Amazon’s, Facebook’s or any other sites that users of your product would likely encounter.

3. Are there multiple, or complicated, solutions?

   This time the answer will most likely be yes. But it’s good to ask so you know you’re focussing your (likely scarce) user involvement resources.

Answering each of these questions we choose from the menu of UCD methods listed below it. You’ll notice the recommendations part is broken into two:

• Recommendation A are the preferred methods to use; 
• Recommendation B are the bare minimum.

Choosing between them we ask ‘How important is this project to the business?’ – the answer should determine how much resource (time and money) you’re willing to use.

Earlier versions

Of course, this diagram also went through a few iterations. You can see these here (click to embiggen).

What next?

When we’ve decided which methods we want to use, we look look up the costs of these UCD methods.

• UCD methods list
• Choosing which UCD methods to use
• The costs of UCD methods
• Creating a UCD estimate

And, in sharing knowledge, teams have been encouraged to learn more about the different ways we can involve users:

• Identifying team roles in Agile 
• User-focussed training sessions
•  ‘What is UCD?’ presentation