What to find out in Discovery
Once you've set a goal for your discovery and understand the problem you're looking into, you're ready to start research.
Focus on learning about your users and their context, the constraints that affect your problem or the wider context you're working in - and any opportunities to improve things.
Understanding users and their context
Info: User Personas
Take a look at the Persona Guidance page for more information.
Start by learning about your users and their context. This means understanding what the user's trying to achieve and how they go about doing it.
When you dig into this, you'll often find the thing you're working on is part of a bigger process or user journey. For example, getting sponsored by an employer is only one part of coming to work in the UK.
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'll 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's journey is very likely to include interactions via offline channels.
Info: Accessibility
Take a look at the Accessibility Guidance page for more information.
You'll also need to learn enough about your users' accessibility requirements to let you work out whether the problem space you're 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. It is vital to consider accessibility requirements from the outset.
You'll also need to think about things like your users' digital skills and internet access.
Understanding constraints
You'll need to understand any constraints you're 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'll 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'd 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'll 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's worth continuing to alpha. If there's a hard constraint which means you are not able to improve on the solution that's 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'd 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's wider journey and who's 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'll measure success
You need to consider how you'll measure if you've been successful. That means you need to think about:
- what data you'll collect to measure service performance
- what performance metrics you'll use to understand if the service is working for users
Work in Progress!
This site is a work in progress and any opinions contained here are intended to spark discussion within each discipline's community of practice.
Created: 2023-06-26