I was recently asked to talk at the annual Visiting Service Stakeholder Conference about the research I’d done as part of the Discovery stage for the Visiting Service Digital Project.
As I thought about what to tell an audience not familiar with agile methodology, I realised that the challenge wasn’t just sharing what I’d learned but also to showcase the importance of user research and why looking at the problems is not a problem.
Discovery is all about finding out what problems users are facing
First of all and let’s be clear on this - Discovery is about problems and not solutions and that’s what users researchers spend their time looking at. Solutions come further down the line. It’s the role of the user researcher to understand what’s happening from the user’s point of view. In essence, we are trying to find out what problems users are facing, either when using an existing service or trying to manage in the absence of a service.
Talking about problems can sometimes make us sound like we are the harbingers of doom but consider the following statement:
“You cannot improve something if you don't know what’s wrong with it and if you want to find out what’s wrong with something - ask the people that use it.”
Understanding the problem
Defining the problem is the starting point for any Discovery piece. For me “problems are needs turned inside out” - once I understand the problems, the needs follow.
The real value a researcher can bring is the critical analysis of these problems. This means we develop and build solutions that solve the right problems in the right order without – and this is crucial - creating further problems elsewhere.
Problems aren’t neat little things
Having defined the problem - I learn as much about it as I can. I speak to all user groups to learn more and see what research has been done already.
Then I ask myself 3 questions:
1. Why is this happening? (I look for all the reasons why the problem exists)
There are usually multiple reasons why something is a problem. If we don’t identify all of these reasons we run the risk of developing a solution that only solves part of the problem.In addition, when we identify all causes of a problem we can prioritise which bits we need to fix first - you wouldn’t put brand new tyres on a car when the engine isn’t working!
2. Who is it a problem for? (Don’t assume that everyone sees the problem in the same way)
What may be a problem for one user may be an essential for another user. If we look at problems in isolation of the wider context of the service, we are in danger of fixing something but causing further problems elsewhere.For example, tightening up access to customer data may solve issues around security but cause a massive problem for staff on a customer service desk who need to access files for customers
3. What’s the impact? (Who does this affect and how?)
Usually the impact is clear, especially when it affects the business but be careful not to ignore the emotional impact of a problem. A poorly designed digital service may mean people don’t provide the information they need to which is bad for business but, it may also cause the user anxiety and stress using that service.
So when people ask me about user research in Discovery I’d call myself a problem finder whose research helps the team to become the best problem solvers and ultimately help us provide better services for our users.