A discovery is about understanding the problem you are trying to solve. A discovery is not about jumping to a solution. It is about understanding your users and their needs.
I have delivered many discoveries. I wanted to capture my key learnings here.
What key questions should you consider in a discovery?
- Who are your users? What are their needs?
- What is the problem? How big is the problem? What is the impact of solving / not solving this?
- What lessons can you learn from others?
- What is your riskiest area?
- What are your constraints? How do they affect the landscape you are operating in?
- How will you measure success?
- Is it worth proceeding to alpha? If yes, what does this alpha look like? What is the recommended scope?
What does a discovery look like?
A typical discovery can be around 6-12 weeks, and can cost anywhere between £50-150k. The Ministry of Justice once did a talk on how they conduct discoveries. I loved their approach so I follow many of the things they suggest.
Here’s how I structure my discoveries:
1) Plan
In the first two weeks, I want to establish ways of working, understand the context we are operating in, understand what we know, identify any glaring gaps in our understanding and start recruitment of users.
Tasks to consider:
- Review existing research and data
- Review existing business processes
- Engage with key stakeholders
- Plan and kick-off recruitment for primary research
- Plan initial workshops
- Understand existing technical systems
- Understand measures of success
Deliverables:
- A stakeholder map
- A risk/decision log
- An initial ‘as-is’ user journey with key moments, pain-points, processes, technology and data points
- Confirmation of outputs e.g. problem statements, journey maps / service blueprints, and personas
2) Discover
In the next 2-6 weeks, we are speaking to users to develop a more nuanced understanding of the problem space, and to learn more about what we don’t know.
Tasks to consider:
- Confirm research schedule
- Plan and run research sessions
- Map out the processes
- Capture business needs through stakeholder interviews
- Engage with technical stakeholders for other systems
- Map out the technical data flows
- Research existing technologies for specific processes
Deliverables:
- User research documentation
- A developing ‘as-is’ user journey with key moments, pain-points, processes, technology, and data point
3) Define
In the final 2 weeks, we analyse our research data and translate it to high impact outputs. We will transition from the ‘as-is’ state (how things are now), to exploring the ‘to-be’ state (a range of desired futures). This will include a process of prioritising opportunities and establishing recommendations for next steps.
Tasks to consider:
- Analysis of interviews
- Synthesis of findings into various maps
- Synthesis of findings to help frame the problem and opportunities
- Visualising the technical environment and tying this in with the user research
- Facilitation of a prioritisation process
- Development of initial prototypes
Deliverables:
- ‘As-is’ service map, including needs and pain points
- ‘To-be’ service maps
- Delivery of all other agreed outputs
- Suggest technical architecture to validate further in alpha
What does a typical discovery team look like?
- Product Manager / Delivery Manager (me)
They help to set the project’s strategic direction.
- Service Designer
Helps the team to build up an understanding of the end-to end process or service.They help to understand the existing user experience and use this to set the strategic direction.
- User Researcher
Plan and facilitate the user research. They also take a lead in facilitating synthesis sessions and work with the wider team to deliver high-impact outputs.
At a minimum, you should have: Product Manager, Service Designer, and an User Researcher. Depending on the needs of the project, I’d suggest considering other roles. For example, if working on a technical project, I’d consider a Technical Lead and a Business Analyst. On a content heavy service, I’d suggest having a Content Designer.
Reflecting on my experience
- Discoveries are hard because you are venturing into the unknown. Embrace the uncertainty. Discovery is the perfect time to ask questions.
- When exploring constraints consider: existing processes and systems, legislation, the political landscape, and legacy technology. Having an embedded Subject Matter Expert in the team means you can focus rather than going down rabbit holes.
- The act of mapping is a powerful way to get buy-in from stakeholders. Use your map to understand what your stakeholders' needs are. Use it as a way to communicate the work you are doing. In discovery, I often describe this as the ‘product’. It helps build a shared understanding.
- In a non-government context, it’s rare to do a deep 6-8 week discovery. I found with most private sector clients, they wanted something more ‘tangible’. A combination of a discovery and alpha helped to meet that need. User research alongside prototype testing got stakeholders excited about the potential of their product.
- It can take a long time to recruit users. I would get started on this in week 1. I’ve used recruitment agencies to speed this process up. Yet using recruitment agencies can be expensive and you may miss hard to reach groups.
- Learn from other services. Sometimes they will have done research in an area in which you would like to learn more. If that research exists, is it better to focus elsewhere?
- A good outcome of a discovery can be to not proceed into an alpha.
- Be wary of continuously doing discoveries without making progress into later phases. This can frustrate stakeholders.
Other things to consider in discovery
- Try different forms of exploration e.g. surveys, user testing, card sorting, focus groups and workshops.
- Understand users with accessibility needs and assisted digital needs.
- Understand your offline journey.
- Understand your riskiest area.
- Understand the needs of your internal users.
At the end of a discovery, you should have…
- A prioritised list of user needs. This should include a recommendation on scope.
- High-level plan for alpha e.g. team profile, user research plan, recommended budget, and suggested scope. It’s helpful for the alpha team to know where the discovery team recommends to focus.
- Initial measures of success.
I hope this helps when you embark on a discovery.