Discovery Research

Discovery Research explores the problem space to gain an in-depth understanding of the people who might use a product or service. So, it's about getting to know the problem that needs to be solved, including the users affected by this problem.

We start early with user interviews and Uster testing. We rely on the double-diamond model as the basis for this, because it clearly separates the problem from the solution. Imagine the scenario of people constantly falling into a river. At an intuitive level, people immediately try to find a solution, e.g. a piece of equipment that can get people out of the water as quickly as possible. But perhaps the real reason for people falling into the water is a broken bridge. This example confirms that we initially need to ask more questions so we can crystallise the problem more specifically. The discovery phase is therefore a central component of a successful design phase. Because the chance that a product is really needed on the market is 75% higher if the solution solves a real problem.

A clear problem statement. We develop this together with the customer with specifically prepared 'wh'- questions: Who is affected by this problem? What are the effects of this problem? Why is this problem important? For a workshop we can prepare a template that we can fill with the views of the various stakeholders. Competitively inspired solutions can also be questioned: Is this really central to your audience or end user? Finally, the points that have been collated can be formulated into a short problem statement (at most 4-5 sentences) that focuses on ONE existing problem without including a proposed solution. This will sharpen the shared vision for the project.

It is completely normal for us to keep coming up with ideas for solutions while dealing intensively with a problem. We don’t want to ignore these ideas completely either, but they shouldn’t affect the process for defining a problem statement. So, what do we do with our ideas? We write them down and put them to one side in a “cooler” so that we can take them out again at a later stage in the solution finding phase. And what exactly belongs in a discovery process?

1. Desk Research: Existing research into users and customers is viewed and analysed. Existing solutions will also be reviewed.
2. Stakeholder interviews: An example of this takes the form of a workshop, where we learn about the customer’s most important business objectives, we gain insight into existing data about the problem and learn about solutions that have already put in place. For us, the user-centric approach is crucial and so we keep asking ourselves: Who else should we interview?
3. User Research: In user testing we find out what the end users need and where they are looking for information in a potential application. This helps us to create wireframes later, test them again in a second iteration and later assemble them into a workable solution.

A design phase can be a chaotic process and must be designed individually for each project. After filtering out the specific problem statement and knowing the needs of the end users better, the main issue is processing the information that has been collected. This is the transition point into finding a solution. How Might We’s (HMW’s) are used to create potential solutions. So back to our example with the broken bridge (= defined problem) we ask ourselves: How can we stop people falling into the water all the time? The HMWs are a written response to something we learned in the discovery process, formulated positively and with a focus on the desired outcome. We then formulate a change statement: We want to change the current situation to achieve the desired result. This gives us the mission that helps us create a solution that really solves the problem that the end user has.