(Feb ’24) ‘Discovery’, ‘Understand’, ‘Explore’ – the different organisations I work with refer to this stage of research using different terms, but it’s the same idea: A process to identify the problems that cause the business & user pain.
I’ve run a number of Discoveries and I have found it useful to think like a detective – my alternative career, in another life 🙂
Imagine a crime scene. Evidence is scattered and needs to be drawn together. The team has a notion of what took place, but its messy and unstructured. As time goes on, the pieces of information click together and a story is formed…
- Be open minded – do not be drawn into the existing hunches and beliefs of the witnesses
- Be flexible – be ready to explore avenues that may lead nowhere. The plan at the start will usually adjust and expand. Sometimes, you don’t find all the evidence you need.
- Apply strategy – ensure you are clear as to the vital evidence of the situation
This mindset keeps me in the right mode, especially as Discoveries come in different forms, just like crimes. (Okay, I’ll drop the crime analogy now).
Some Discoveries involve many scenarios with lots of working parts – different organisational disciplines, many user interactions, complex analytics and data sources. These may take many months to complete. Others are more focussed, with limited time and scope to gather information. They take less time to gather information and feel more manageable. But the process of discovery broadly remains the same.
In terms of running a Discovery, there are typically four stages I go through: Planning, gathering, synthesising and visualising.
1, Planning
It’s important to understand the scope and strategic requirements in planning. What evidence exists that might be causing the problems? What are the hypotheses? What are the business aspirations? What is not in scope?
When this is understood, the research plan will be simpler to devise. You can draw on existing (secondary) data, identifying the gaps that will require primary research. This planning should indicate the time, budget and resource you’ll need.
There is an infinite number of sources – however, the researchers’ expertise will limit what can be done personally – a team comprising researcher, designer and business analyst is a good approach.
2, Gathering
Collecting your evidence is enjoyable. This stage involves lots of stakeholder involvement, chasing down information, setting up and fielding primary research. Data gathering requires patience as blockers are experienced. Gradually you will feel like the story is forming but be prepared to reframe your understanding as new evidence emerges.
Whilst you gather your evidence hypotheses may be proven or disproven. New hypotheses will emerge, and the direction will change. It’s important to remain flexible and even suggest new research to dive deeper.
Discovery is not intended to provide solutions. We are interested in understanding the problems. However, in my experience, there is merit in creating potential solutions and testing them with users.
The reason for this is that, by throwing in solutions (for example, prototypes), hunches are tested. I’ve found that doing this means you go deeper into understanding the shape of the problem. The alternative is waiting until after discovery, only to see ideas fail due to lack of evidence.
Recording and visualising this evidence is important. Include periodic research downloads to the team. Teams often create a digital location that allows visual linking between the data.
3, Synthesising
Having gathered the data, the discovery team will be feeling a little stressed. This is because there is no story to tell yet. All the information (some that may be conflicting) needs pulling together, drawing on evidence to prove and disprove hypotheses.
Usually, everything is known, it just needs to be stated, debated, and agreed. It’s a good idea to get a room for a day or two. Give the team space to devote time and energy to exploring all the data. If it isn’t done rigorously enough, rest assured that a clever stakeholder will pick holes in it.
4, Visualising
Discovery documents can be big, but the outputs should demonstrate the approach, core insights supported with evidence, and actions. Using a visual tool such as Figjam is best.
Ensure the artefact clearly sets out the business issues and problems. Use data to support the issues – customer contact, complaints, sales, market share, competitor performance or innovation.
Move into your strategy for exploration and reveal the evidence gathered. Move the sense of exploration onto insight and reassurance. The intent is to communicate that you have explored and understood what is happening and why.
Finally, it’s good to communicate the outputs using a range of problem statements and ‘how might we’ statements that clearly show the specific needs for solutions that are to be developed.
What next?
Usually, a brief pause. Feedback from stakeholders. Politics emerge. Priorities are agreed on.
Then follows a period of ideation or incubation based on the discovery – the discovery artefact is used heavily to guide teams and is often revisited, forming a core focus for the project team to plan their product development.
If you’d like me help with your discovery, please get in touch.