Before you start building a service, you need to find out whether users need it and whether other services exist. This is to save time building something that may not be required, or might just not be the right thing.
This part of your project is called the discovery phase. The time spent in discovery, saves time in later phases.
- You shouldn’t start building your service in discovery.
- You shouldn’t use discovery to design a service to work around existing processes in your organisation. Use it to find out whether you can build a service that meets user needs.
- If a business case has not been created, or it hasn’t included some of the metrics we would recommend capturing, this should be done in discovery.
What to find out in discovery
- who your users are
- your users’ needs and how you’re meeting them, or any needs you’re not meeting
- which services currently meet your users’ needs
- how you’d start developing a new service if your discovery finds there’s a user need for one
- the statutory requirements for the service (legislation)
- what the current process looks like and identify any parts of it that are ‘painful’ i.e. manual or difficult for customers or staff
- what the user journey for someone using your proposed service might look like
- how you might build a technical solution given the constraints of your organisation’s legacy systems
- the policy that relates to your service and how it might prevent you from delivering a good service to your users
What to do in discovery
To get the information you need in discovery, you can:
- carry out user research
- gather internal information and statistics in the what to measure section
- analyse policies, laws and business needs
- map the current as-is process
- create and maintain the user story backlog
- create and maintain a list of tasks that is open for all the team to access
- have regular catch ups and share learning with the entire team
The team you need
Competencies required at the discovery stage require the BA/User Researcher to:
- Collaborate, not interrogate
- Maintain a great relationship with the service you are working with
- Remain clear and open – no sweeping issues under the carpet!
- Share knowledge with the team to increase empathy and understanding
How long discovery takes
Every service is different, but depending on the size and complexity of your service, your discovery should usually take between 4 and 8 weeks.
During the final week you should:
- make a broad scope for your project
- write user stories
- decide the features your ‘minimum viable product’ must have
A minimum viable product is a version of your service that has just enough features for you to test it with users and check whether those features work.
How you know discovery is finished
Discovery is finished when you know and have agreed:
- the scope of the service you want to build
- the team of people you need if you do move on to alpha
- that senior stakeholders want to begin building the service and understand your plans
- how you’ll measure success and what a successful service would look like
- any related services that exist to meet the user need and whether they’re run by government or third parties – your service shouldn’t be duplicating another government service and it should only meet needs government is uniquely positioned to deliver
- how many of your users need assisted digital support and what their needs are
You should have:
- a prioritised list of user needs
- a prioritised list of user stories
- a list of stakeholders, and information you’ve got from them about existing services
Moving on to the alpha phase
You should move on to the alpha phase if your discovery findings show:
- you can build a service that better meets user needs compared to what’s currently available
- the service you’re building will be better value for money
Stopping after discovery
Your findings may show it’s best to stop developing your service, for example if you discover:
- there’s no user need for the service you planned to build or for an online service
- user needs are already being met by another service
- technology or policy constraints mean you won’t be able to build a service that meets the user needs you’ve found
- it’s not cost-effective to develop the service
It’s not a failure to stop developing a service after the discovery phase if your findings show that’s the best thing to do.