Our journey into UCD

January 21, 2009 (quite a long while ago…)

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.