User research, not user testing

I’ve now been at the Co-op for a couple of months. In that time I’ve met lots of people, seen lots of work going on and talked about what I do with many, many people. I’ve even written my first CoopDigital blog post about user research at the Co-op.

One thing that I know we still need to work on is sharing wider what user research really is and how it should be used to influence what we do and how we do it. This is fine, it’s part of our jobs as experienced agile people and experienced researchers. It’s one of the reasons we’re hiring so many good people.

In my previous place of work, if someone called what we do ‘user testing’ there would almost always be someone who’d jump up and say ‘User Research NOT User Testing!’. I was always fairly relaxed about it, I knew what they meant, the person uttering it knew what they meant and it always felt like a bit of an over-reaction to me, personally, I’d just smile and let it go.

Moving to somewhere where it is a less familiar concept I’m beginning to realise why people did it.

I’m finding that, for some people, ‘user testing’ is something you do near the end, you’re fairly convinced you’ve got it right, you’re fairly convinced it’s going to work and it’s going to go down well. What you might get is some feedback or minor tweaks to make it even better. I think the issue is the word ‘testing’, where testing is generally done just before you go live to spot bugs and defects.

That’s not what user research and agile development is, what it’s for and what it’s brilliant at.

A picture of one of the CoopDigital product teams

User research is invaluable to us to help decide if we should build/release something at all, what that something should be and how it should work. It shows us how the thing we make will fit into users lives. It gives us insight into the language people use and how they view the world. It also helps us understand the problems in their lives they’re trying to solve, the tasks they’re trying to achieve and how what we build can help solve that problem or complete that task.

There is also the issue of what we’re testing when we do research: we’re testing our designs, we aren’t testing our users. The user doesn’t pass or fail, the design does.

Simon Hurst
User researcher

User Research at CoopDigital

Hello, my name’s Simon and I’ve just joined the team at CoopDigital as a user researcher.  I’m really excited to be here and help the team build some world class digital services.

Picture of Simon Hurst - user researcher
Simon Hurst – user researcher

What does a user researcher do?

User researchers fulfil several roles for a team, we’re there to help them understand:

1) Who the users of our services are and understand what they need from the service. To build great services you need to truly empathise with your users.

2) What’s the problem the user is trying to solve, what goal are they trying to achieve? How can we support them to achieve their goal?

3) Whether the solution we’re looking to provide works well and how can it be better?

Meeting real people

We do this by getting out of the building and meeting real people, talking to them and trying to understand their lives, watching them trying to complete their goals or use things we’re building.

We work with a huge variety of people, this includes those who are just learning the ropes, people who have maybe been bought a tablet by their children, or people who use a screenreader to interact with their device because of a visual impairment.

Bringing the team along

It’s even better when you bring members of the team with you, getting people who are building the service and writing the code to see users actually using the thing they’ve built and to see them struggling can have a tremendous impact on how they tackle problems. The result is a team who care about what they’re building and are absolutely committed to making it the best it can be.

User researchers are interested in if people can use things to complete a task, user research isn’t about asking people if they ‘like’ what we’ve built, or what they think of the colours.

It can be frustrating for people to see something they’ve designed and built not working, to see people struggling to understand the words they’ve used, or to interact with the clever little interface they’ve made. However, the sooner we can recognise the issues, the sooner we can fix them, it’s better to find this out before you release the thing.

It’s even more important to understand why we are building something in the first place, is it needed by people? Is it helping them to achieve a goal or to solve a problem? If it isn’t we end up building something that could be the most beautiful designed and usable product or service, but if it’s not needed then no one will ever use it.

We’ll be looking at how we get involved with users more and more in the near future and we’ll be sure to blog about how we’re doing it and what we’re learning along the way. We’ll also be working hard to try and understand how user research applies in an organisation as diverse and varied as Co-op. There’ll be plenty more blogs to come from us on that.

Simon Hurst
User Researcher