‘Discovery’, ‘Understand’, ‘Explore’ – the different organisations I work with refer to this stage of research using different terms, but it’s the same meaning: A process to identify what problems are causing business issues.
It’s like a crime scene. Evidence is scattered and need to be drawn together to form a story. The team has a notion of what the outcome will look like, but it feels messy and unstructured at the start. As time goes on, the pieces of information click together.
I like to think like a detective:
  • Be open minded – do not be drawn into the existing hunches and beliefs of the incumbent team
  • Be flexibile – be ready to explore avenues that may lead nowhere. The research plan at the start will usually adjust and expand. Sometimes, you may never find all the evidence you need.
  • Apply strategy – ensure you are clear as to the scope and measures relating to the business issue

The format of discovery research

Discovery projects come in different sizes. Some involve an entire journey with many 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 together and feel more manageable. But the process of discovery broadly remains the same. I think of it in four stages: Planning, gathering, synthesising and visualising


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? (you may need to write them). 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 analyst is the very minimum.


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 wall, or digital location that allows visual linking between the data.


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.


Discovery documents can be big, but the core story should run to around 30-page document for sharing with supporting data in appendices. Using a visual tool such as MIRO or Prezi is worthwhile.
Ensure the document 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 a period of ideation or incubation based on the discovery – the discovery document is used heavily to guide teams. It is often revisited and forms a core element for the project team to base their development.
If you’d like me help with your discovery, please get in touch.