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

I’ll say straight off the bat, we’ve got some great people here at Rightmove and a trusting management set-up. But there were some key things needed to gain buy-in and make sure we were using all the skills available to us. We identified the following things we’d have to do:

1. Learn more about the various UCD methods available and when it was appropriate to use them
2. Understand more about the teams functioning around us
3. Create a framework so we could set realistic expectations
4. Educate the business in what UCD is and why we wanted to change processes

Learn more about UCD

Read. A lot. And talk. To internal people and to other people in the industry. And do. Start now. You’ll only learn by doing and making mistakes.

Understand more about other teams 

What was important to us here was figuring out what each team was doing in each phase of the development process. What we found by identifying team roles in Agile was where there were overlaps, and hence where we could help each other.

We’d be mad (and very conceited) to think that we know best. Or that we could do all the research, designing and testing ourselves. Spreading the load means more knowledge and more people taking action.

Create a framework

We knew that involving users would  mean a better product. We also knew it would essentially slow down the design/development process. By creating a (small) suite of UCD toolkit, we set up a framework to help us decide which methods to use and what they would cost in time and money, allowing us to deliver estimates to the business (meaning realistic expectations are being set – very imporant!).

Educate the business

Key to getting business buy-in was showing examples of real people struggling with real issues.

We were extremely fortunate to be able to run some eye-tracking tests with users which management, project owners, business analysts, team leads, designers, developers, and marketing could all be involved in. This showed everyone the extent to which users were struggling with our site and really made people realise that we can’t design ‘in a bubble’. Once people had seen the problems, we gave a ‘What is UCD?’ presentation to show the business what we intended to do about it all.

We followed this up with weekly user-focussed training sessions where teams teach other teams about the techniques they use (e.g. paper prototyping, interviews, a/b testing) opening peoples minds to what’s possible.