I’ve been helping different organisations to design and evaluate their services for many years.
One thing I’ve heard frequently and might sound familiar used to really give me the heebie-jeebies.
Picture the scene. You’re kicking off a new research project and a stakeholder says something along the lines of:
“Just make sure you don’t tell us what we already know!”
I understand why they say it but how on earth can you know what they already know?!
Ironically, if you ask an organisation to tell you what it knows it can be surprisingly difficult for them to tell you.
In reality knowledge is scattered across organisations in many different formats and getting hold of it can be really tricky.
So how can you get it out of people’s heads and into yours within the constrains of a typical project?
One simple approach I’ve used and found really useful is to run a workshop with people who know the service well, before starting your own research.
The aim is to uncover what they already know about questions like:
- who do we think is using the service?
- what do we think they are trying to do?
- what do we think they are feeling, thinking and saying?
- where do we think are the pain points for service users and staff?
- what do we think is working well?
- what do we think would make things better?
I usually run this remotely using something like Miro and prepare a template in advance that looks like a giant table which lays out the main stages of the user journey.
The columns of the table represent the stages of the journey and the rows represent the things we want to understand more about such as the questions listed above.
During the workshop you go through each stage/ column in turn and ask participants to add everything they know about relating to each row of the table.
Once they’ve finished each stage, you talk it through together to make sure you understand what they’ve shared.
The result is a surprisingly rich picture of what’s going on within the service in a relatively short period of time.
This is all well and good but there’s something really important to acknowledge about the information that people share with you – it isn’t all necessarily true.
Some of it will be things that people have directly observed for themselves.
Some will be things that they’ve heard from their colleagues.
Some will be their assumptions, beliefs or organisational myths that have simply become accepted as facts over time.
Despite this, what you will have collected is still useful because it gives you an idea of what your stakeholders believe to be true, which you can then explore further within your own research.
This has several benefits.
It gives you a foundational understanding of the service before you start talking to users, helps build rapport with the team and identifies gaps in knowledge that you can explore further in your own research.
And if your research confirms something stakeholders already knew, that definitely isn’t a failure on your part.
It is likely that you will have added evidence to that known issue, shown how widespread it is, understood its impact on different groups of people or helped to uncover the root cause of why it is happening.
I think that a real failure on the part of the researcher would be to spend time rediscovering an insight without adding anything new.
But there’s another benefit of this approach that is hugely valuable.
By bringing all of this existing knowledge together into a single place you start to create something that most organisations have never seen before – an end-to-end view of the entire service experience.
This is useful because people often know a specific part of the service extremely well, but have no visibility of what happens elsewhere due to organisational silos.
So the next time someone says ‘Just make sure you don’t tell us what we already know!’ give this method a try to ensure that your research builds upon existing knowledge, rather than starting from scratch
