Skip to main content

Discovery

What is a discovery?#

Discovery is an initial phase of work carried out in the UX design process in order to understand the problems that need to be solved and inform our design decisions down the line. It involves researching the problem space, what our users are trying to achieve, learning about constraints and gathering evidence to help define the direction we need to take or validate a proposed direction and what to do next.

Discoveries do not involve testing hypotheses or ideas.

Discoveries are important because they allow us to identify and focus on the right problems. It ensures we’re building the right thing for our users or indeed whether we want to move forward with the project at all. Discoveries mitigate the risk of building something that does not solve our problems, meet our users needs, avoids wasting time, money and effort.

A discovery phase is generally technology or solution agnostic. The focus is to explore and define problems rather solving them within the short time frame. If building a given service or product has been decided the discovery phase becomes more of a requirements-gathering and validation exercise where teams seek to confirm that the proposed solution solves the users and business’ problems.

The double-diamond shown in the framework for innovation approach developed by the UK Design Council helps communicate the discovery process at a high level. We must first understand the problem space through research and use the knowledge gained to agree and define the problems we need to solve. Only then do we move on to ideate, test, iterate and develop our product or service.

How long is a discovery?#

There’s no rule on how long should be spent on a discovery but they generally take between 4 and 8 weeks. The project itself should dictate the length of time needed.

If you are working on a project that has not had any research or there is a lack of understanding about the problems users are experiencing, then a longer discovery will be necessary. If the problem is well known then you could shorten your discovery.

When do you need a discovery?#

In most cases, a discovery is needed when there are lots of unknowns. If you do not know what you’re looking to achieve and/or how you’re going to achieve it.

You will need a discovery phase if:

  • there is not a complete idea of what the product or service should be
  • there are unknowns that prevent the team progressing
  • the project has a lot of complexity
  • the team is not aligned on what it is looking to achieve
  • an organisation is looking to expand it’s product or service offerings or where to take an existing product next
  • there are changes in product or service policy, legislation or technology
  • there’s a change in strategy for a business or organisation, for example, a move to make services digital or digital transformations

What does a discovery consist of?#

There are lots of different types of activities that can be carried out during a discovery, some activities are included every time and others may be optional depending on the circumstances.

Common activities include:

Setting a goal#

It’s important to set a clear, achievable goal for your discovery. This will help you define what is and is not in scope for this phase of work and keep team members aligned. It will also help you identify when the discovery phase is finished.

Stakeholder and subject matter expert (SME) interviews#

Stakeholders and SMEs have valuable insight into a product or service’s internal workings, processes and the users who interact with them.

It’s important to speak with stakeholders and SMEs early on in the process to gain that foundational layer of knowledge and insight which helps the team understand the project, problems and scope along with helping them focus their efforts.

Interviewing stakeholders and SMEs can give you an understanding of:

  • what motivated the stakeholder to approach AND to help solve their problems
  • key objectives and how these objectives fit into the broader context of the business or organisation
  • most importantly, what problems are we trying to solve and how they are impacting the users
  • any solutions they have tried before, what has and has not worked
  • what factors will dictate how users interact with the solution such as device or interface type
  • opportunities for improvement

In addition to interviewing stakeholders, including key stakeholders in the discovery process and workshops helps with buy-in and also provides further insight when it’s most valuable to the team.

Problem definition#

If you have a predefined solution at the start of discovery, it is important to reframe it as a problem to be solved so that we may better understand what the team has been brought together to achieve. Start by converting any assumptions into "how might we’s" or "problem statements".

We need to get to the route of what issues the business or organisation and/or users are facing in order to be able to better solve them or validate the initial assumptions in regards to a solution.

If a solution has not been predefined, your problem should be derived from stakeholder interviews, user research and market research and again converted into "how might we’s" or "problem statements".

You may decide to prioritise these problems as a team in the discovery phase.

You should also consider quantifying the value of solving the problems you discovery. What are the cost implications of the problem existing. Is it worth the time, money and effort to resolve?

Understanding users#

Carry out research to understand the user’s behaviours, needs, motivations, pain points, what they’re trying to achieve and how they go about achieving it. There are lots of methods for research both qualitative and quantitive such as contextual inquiry, user interviews, reviewing analytics and unmoderated UX studies such as feedback forms.

Through research the team will gain an understanding of:

  • how, when and where a problem occurs
  • how the problem affects the users and in turn, the business or organisation
  • users’ needs and expectations
  • what the wider journey or service looks like and who else it impacts such as operations and support teams
  • users’ accessibility requirements keeping in mind 1 in 5 people in the UK report having a permanent disability
  • users’ digital skills, internet access and technology they use
  • opportunities for improvement

Research will help the team empathise with and understand the user on a deeper level and ensure what we build is truly user centred.

Project constraints#

The team needs to realise and understand the constraints of the project. Common constraints include:

  • policy
  • legislation
  • contractual agreements
  • technology
  • existing processes and legacy systems
  • time and resource

It’s important to discover what constraints can and can not be changed. Some things may be impossible to change, legislation for example. Other constraints can be easier to change, existing processes in support centres or paper-based teams for example. It’s always worth trying to push to remove constraints where possible rather than just work around them to ensure a good end to end experience.

Understanding the constraints can also help the team decide wether to proceed with the project if this constraints are going to prevent you from improving the product or service. It can also help the team prioritise tasks. For example, if the project requires changes in existing processes, then you would prioritise this in the next phase of work.

Workshops#

Workshops are a useful tool for gathering existing knowledge, understanding requirements and aligning the team and stakeholders during the discovery phase.

Examples of workshops carried out during discovery:

  • Kick off workshops - to ensure the team and stakeholders are aligned on the discovery objectives and responsibilities of each team member
  • Research workshops - to question existing assumptions, highlighting those that need to be validated or explored further, also known as assumption-mapping along with discussing the unknowns and drafting research questions
  • Affinity-diagramming workshops - using your research findings, uncover trends around problems identified, causes, symptoms and needs
  • Storyboarding and user journey mapping workshops - to put context around the users and their journey when using a product or service based on real data, helping the team gain a shared understanding of needs and pain points and build empathy
  • Service-blueprinting workshops - to plot information gathered in research and business analysis on a map to identify gaps in the context of a wider service
  • Problem statement workshops - to create problem statements or "how might we’s" which help the team focus going forward
  • Post up workshops - in which participants generate a diverse range of ideas and post them up on a wall to discuss as a team

Discovery outputs#

Once your discovery is complete the team should have a deep understanding of the problem space, the wider service, user needs, business requirements and and idea on the direction you need to take the project.

In some cases a decision might be made not to move forward with the project. For example, if the team has discovered there is not a user need or the project is not cost-effective. It does not mean a project has been unsuccessful, it means we’ll have helped our clients avoid wasting time and money.

Examples of outputs from discovery to communicate what you have learnt include:

  • finalised problem statements based on research
  • service blueprints
  • storyboards
  • user journey maps
  • user-needs statements
  • personas
  • high-level list or map of ideas you want to explore in the next phase of work (it’s important that any ideation does not take time away from completing key discovery activities)