Meeting the Service Standard
Meeting points 2 and 3 of the standard at beta involves slightly different things than it did at alpha.
Solving a whole problem for users
Point 2 of the standard says you need to work towards solving a whole problem for users.
Getting the scope of your part of the journey right
At alpha, you’ll have tried different approaches and developed an idea of how to scope your transaction, so it makes sense to users.
Use the beta phase to continue to test and refine that scope.
Joining up with the user’s wider journey
At alpha, you’ll have worked out whether your service is part of a wider journey. At your beta assessment, you’ll need to show how the service you’ve built operates within that wider journey, working across organisational boundaries where necessary.
For a GOV.UK transaction, you’ll need to agree the following things with the GOV.UK team at GDS before going into public beta:
- how the transaction will join up with GOV.UK guidance or any start page
- a subdomain name and any content changes needed
Working in the open
Continue to work in the open during beta - for example, by blogging and by inviting operational delivery colleagues to open show and tells, so they know what you’re doing.
If what you’re building at beta is going to be part of a wider journey involving other organisations or services, it’s especially important to talk publicly about your plans. It’s also worth looking into whether you could start or join a service community.
Dealing with constraints
You’ll have used the alpha phase to understand any constraints that are likely to affect your service.
For example, contracts or the organisation’s plans for a wider change programme might influence how fast you can move away from legacy technology.
At the beta assessment you should be able to explain how the organisation as a whole is making reasonable progress towards addressing these constraints.
Reusing users’ information where possible
If you’re building a service that reuses information users have already provided to another part of government, you’ll need to show that users’ information is being shared in a way that’s secure, stable and works at scale. This might be through an Application Programming Interface (API) that follows the government API standards.
You’ll also need to make sure any information sharing happens in a way that protects users’ privacy.
Providing a joined up experience across different channels
Point 3 of the standard says that you should work towards providing a service that works well across all the channels a user might use to access it.
You’ll need to show that you’re making reasonable progress in improving the user’s experience in different channels. For example, by testing and iterating letters users get from the service or improving the way a call centre refers people online.
You should be able to explain how you know your assisted digital support model meets the needs of users who need help doing things online. And how you’ve set up your user support model.
You should also be able to show that the organisation as a whole is tackling any long term constraints that make it difficult to improve offline channels. Like a process for creating automated letters that makes it expensive to change things.
You should be able to explain how you're involving colleagues from operational delivery in:
- prioritising what you work on
- designing how the service works - for example, by inviting them to attend and analyse user research
And you should be able to explain the organisation’s process for solving problems that show up in one channel, but need to be fixed by making changes in another.
Making sure everyone can use your service
Info: Accessibility
Take a look at the Accessibility Guidance page for more information.
As part of providing a service that everyone can use, at your beta assessment you’ll need to show how you’ve run regular accessibility testing on your service and run research sessions with disabled people.
You’ll also need to talk about the results of your accessibility audit and fix any issues before moving into public beta.
You’ll need to show that you’ve considered whether the service has any pain points that might lead to people being excluded, and what steps you are taking to address them.
When you move into public beta, you will need to publish an accessibility page for your service.
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-07-26