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.

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.