Lessons in making change happen: Stop, look, listen!
How user research helped us build a better digital tool.
Leaving Well is a web app that puts care leavers at the heart of decisions about their future. It’s a tool used collaboratively by care leavers and their case-working teams to get an understanding of how care leavers are doing and provides a framework for planning goals and ambitions for the future. We have been developing the tool through our Impact Incubator over the past few years.
As the product team working on the Leaving Well tool, we wanted to help to spark more genuine conversations between workers and their young people; streamlining the process so that more time is spent on support, and less on paperwork. A digital product team like ours comprises several disciplines such as development, design, and user research, and each has a key role to play.
In our Making Change Happen report, we stressed the importance of understanding the problem, and user research is a key part of helping us to understand our users, their needs, behaviours and motivations. It helps us create things that are actually useful for the people using them.
It can be tempting to skip user research and get straight to designing and developing the product. User research costs time and money, and it can feel like a leap of faith for teams and organisations to put resources behind it. This is especially tough if we have preconceptions about how people interact with our product or service, which can lead us to overestimate our ability to predict our users’ behaviour.
But that’s the reason we do user research; we are not our users, and we cannot accurately predict what they need without listening to them.
We also said in the Making Change Happen report that you must learn as you go along — and so we are committed to continuing to be shaped by feedback. Here are some recent examples of how the Leaving Well team — past and present — has researched with our awesome users to understand where our designs needed improving.
Notifications
When we designed the tool, we imagined that in-app notifications would be sufficient to alert users that something had been updated. When we tested the tool, we realised this was not the case.
As a team manager, for example, you have several different systems or tools to use, your day is packed with meetings or visits, and you need to support your team in their practice. It’s fair to say that most of your days can be pretty hectic! And while your caseworkers might use the tool more regularly, as a team manager, your interaction with the Leaving Well tool might be more intermittent.
What this means is that when you get an important in-app notification on Leaving Well, you might not see it for a few days. In a context where work needs to happen fast, this is a problem.
So, what next? As user researchers, we explored alternatives with users. We talked to our team about how to balance this with tech constraints, and together we devised a solution; email notifications. This allows users to receive notifications where they will actually see them and enables them to take action. This is a change that our developers have been working on and are about to release: watch this space!
Voice
In the Leaving Well tool, both young people and caseworkers can enter information. This allows young people leaving care to own their narrative, to talk about their context in a way that represents them.
In testing the tool with our caseworkers, we found this was one of the things they loved most. However, we also learned that there was a need to distinguish between the young person’s voice, and the caseworker’s. We had designed the tool with collaboration at the forefront, but in that, we had lost the distinction between who was saying what.
To solve this, we added ways of formatting text in the tool. This maintained the flexibility for users to choose how and what they inputted, but also gave them a way to distinguish voices.
Language
One final example shows how user research can set you back on the right course.
There is a section in the tool called ‘overview’ that allows users to write a summary of the other information that they have included in the tool. We felt that the word ‘overview’ wasn’t quite the right fit for what this section did, so we tried out the word ‘summary’ instead.
What did we find? That ‘overview’ actually aligned better with our users’ understanding than ‘summary’ did. Testing out this variant let us know which word made the most sense for the people using the tool, helping us ensure that people can move from one section to another with greater ease.
Overall, what have we learned?
We’ve had a healthy reminder of the importance of not relying on personal heuristics when designing, and learnt a lot more about how our tool is being used on a daily basis by our users. We’ve also had the exciting opportunity to refine and adapt the tool as a team, to make it more useful, and to ensure its value to our users.
It’s an important step towards making change happen, and we look forward to continuing to ensure it works for the people we seek to serve.
