51茶馆

Before you commit to building a service, you need to understand the problem that needs to be solved.

That means learning about:

• your users and what they鈥檙e trying to achieve
• any constraints you鈥檇 face making changes to how the service is run - for example because of technology or legislation
• the underlying policy intent you鈥檝e been set up to address - this is the thing that government wants to change or make happen
• opportunities to improve things - by sharing data with other teams, for example

This part of your project is called the discovery phase.

What you learn during discovery should help you work out whether you want to move forward to the alpha phase. Running an alpha means you鈥檝e decided that the benefits of looking further into the problem outweigh the cost.

You should not start building your service in discovery.

You can .

How long a discovery should take

There鈥檚 no set time period for a discovery, but around 4 to 8 weeks is typical. Let the purpose of your discovery dictate how long you spend on it.

If you鈥檙e working on a problem that no one鈥檚 researched before, you might need a bit longer. If it鈥檚 a problem you know a fair bit about already, you might be able to have a slightly shorter discovery.

Set a goal for your discovery

It鈥檚 useful to start by setting a clear goal for your discovery. This will help you scope your discovery appropriately and work out when it鈥檚 finished.

Define the problem

At the start of your discovery, you might be presented with a pre-defined solution or told you鈥檙e building a specific thing.

Before you start your research, you鈥檒l need to interrogate that solution and reframe it as a problem to be solved. This will help you better understand what your team has been set up to achieve.

Break down assumptions and ask lots of questions. Reframing the problem also includes agreeing what is not part of the problem.

For example, a problem is not: 鈥淲e need to build an interactive map to show people where our contact centres are鈥�. It鈥檚 probably something like: 鈥淗ow can we make it easier for people to find their nearest contact centre if they need to book a face-to-face appointment?鈥�

So start by . The better you define it, the better the potential solutions you鈥檒l end up with if you move on to the alpha phase.

You should also consider quantifying the value of solving the problem you鈥檝e been set up to address. During discovery, that means understanding how much the problem is currently costing.

What to find out in discovery

Once you鈥檝e set a goal for your discovery and understand the problem you鈥檙e looking into, you鈥檙e ready to start research.

Focus on learning about your users and their context, the constraints that affect your problem or the wider context you鈥檙e working in - and any opportunities to improve things.

Understanding users and their context

Start by learning about your users and their context. This means understanding what the user鈥檚 trying to achieve and how they go about doing it.

When you dig into this, you鈥檒l often find the thing you鈥檙e working on is part of a bigger process or user journey. For example, .

Understanding context includes developing a picture of what that wider journey looks like - for example, by creating a low fidelity map of the services that exist in the wider problem space.

As you flesh out your map, you鈥檒l probably notice that the problem spans across multiple departments and sometimes includes non-government organisations too.

Spend some time during discovery learning from those other teams and organisations. You should also talk to your operations colleagues, given that the user鈥檚 journey is very likely to include interactions via offline channels.

You鈥檒l also need to learn enough about your users鈥� accessibility requirements to let you work out whether the problem space you鈥檙e looking at presents any particular challenges from an inclusion point of view.

Bear in mind that, in the UK, 1 in 5 people report a permanent disability. And that accessibility covers a range of other needs for people who do not have a disability.

You鈥檒l also need to think about things like your users鈥� digital skills and internet access.

Understanding constraints

You鈥檒l need to understand any constraints you鈥檙e likely to come up against if you were to move on to the alpha phase. This includes constraints due to things like:

• legislation
• contracts
• legacy technology
• existing processes and systems

You鈥檒l need to work out which of these constraints are hard constraints that you will not be able to do much about. For example, primary legislation is not something that can easily be changed. But if you were to move on to alpha, you鈥檇 need to find a way of delivering a service that still works for your users.

Some constraints are soft constraints, though. For instance, if existing processes (whether in digital, call centre or paper-based teams) are preventing you from delivering the best version of your service, you鈥檒l need to work to change those processes - do not just work around them.

Understanding constraints is helpful for two main reasons. Firstly, it helps you work out whether it鈥檚 worth continuing to alpha. If there鈥檚 a hard constraint which means you are not able to improve on the solution that鈥檚 currently available, it might be worth stopping at the end of discovery.

The second reason is that it can help you prioritise your risky assumptions if you do continue to alpha. For example, if a service will only be viable if you can change an existing process or structure, you鈥檇 want to focus on ways of doing that during your alpha.

You could also look at related or similar services, to understand the constraints they face and how they dealt with them.

Identify improvements you might be able to make

One of the benefits of understanding the user鈥檚 wider journey and who鈥檚 involved in delivering it is that you can spot things that could be improved. You could take these improvements on to later development phases.

For example, your discovery research might reveal that another part of government is already collecting the personal information you need from your users. If you decide to go ahead and build a service, reusing that data would prevent users from having to provide the same information multiple times.

You could spend part of your alpha evaluating the technical and legal challenges of reusing that data in your service.

Your research might also lead you to consider alternatives to building a service. For example, you might be able to solve the problem more effectively (or less expensively) by publishing website content, running a campaign, partnering with a non-government organisation, giving improved information to face-to-face advisors or making data or an API available to third parties.

Your service should not duplicate another government service and it should only meet user needs that it makes sense for government to meet.

How you鈥檒l measure success

You need to consider how you鈥檒l measure if you鈥檝e been successful. That means you need to think about:

• what data you鈥檒l collect to measure service performance
• what performance metrics you鈥檒l use to understand if the service is working for users

Sharing what you learn

Unless confidentiality issues mean you cannot, you should talk publicly about what you鈥檙e learning. You could do this by publishing blog posts or running open show and tells.

This helps people across and outside your organisation know what you鈥檙e doing and makes it easier to collaborate with the other organisations working in your problem space.

The team you need

Aim to involve a variety of disciplines, although there are some people you need to have in your team at each phase.

How you know discovery is finished

Your discovery is finished when you鈥檝e decided whether or not you want to move on to alpha. There a couple of factors that play into this decision, including whether:

• there鈥檚 a viable service you could build that would make it easier for users to do the thing they need to do
• it鈥檚 cost effective to pursue the problem - this means weighing up how much it鈥檇 cost against how much of an improvement you think you could make

It鈥檚 not a failure to stop at the end of the discovery phase if your research shows that鈥檚 the best thing to do. In fact, you鈥檒l be saving time and money that could be better spent elsewhere.

If you do decide to move on to alpha, you鈥檒l need to make sure you:

• understand the wider context and the other services, teams and organisations working on similar problems to you
• are clear on how what you鈥檙e working on fits into that wider problem space
• have a list of ideas you鈥檇 like to test at alpha and an idea of which one you鈥檇 like to test first
• know roughly who you need in your team for alpha
• know how you鈥檒l measure whether you鈥檝e been successful

Related guides

You may find these guides useful:

• How the alpha phase works
• How the beta phase works
• How the live phase works
• Retiring your service