Meeting the Service Standard
There are a couple of points in the standard you'll want to pay particularly close attention to 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.
At alpha, this could mean showing:
- how you know that you've got the scope of your part of the journey right.
- you've looked at the wider user journey your service is part of.
- you have a sense of what would need to happen to make the journey as a whole work as well as possible (in particular, you're able to talk about other services that are part of the same journey, and the opportunities and challenges involved in making changes to those services).
- you're working in the open, and have started building relationships with teams responsible for other parts of the journey where it makes sense to do so.
- you understand any constraints with legislation, contracts or technology that impact on your service.
- you're planning to minimise the number of times a user has to submit the same information to government.
Getting the scope of your part of the journey right
Getting the scope of a transaction right is probably the most important part of making it simple to use. Use alpha to explore what scope makes sense from the user's point of view.
Joining up with the user's wider journey
Not all transactions are part of a wider journey for the user. But if yours is, you should have explored that wider journey as part of discovery.
You could bring a rough journey map (or similar artefact) to your alpha assessment, showing where your service sits in the user's journey, the different organisations involved and the different channels people use to access them.
If one of your riskiest assumptions is that it's possible to make changes to other services in order to provide the user with a simple, intuitive journey, use the alpha phase to test that assumption by talking to the people responsible for those other services. By the end of alpha, make sure you're clear what can be changed and how difficult or costly it would be to make those changes.
If you face any blockers collaborating across government or more widely, you need to show how you're addressing them, for example by building relationships with potential collaborators.
Either way, you should be talking and building relationships with the other people working in the same area as you. A good place to start is to check whether there's a service community for the area you're working in.
You should also get in touch with the GOV.UK content team midway through your alpha. They'll help you work out how your transaction should join up with GOV.UK.
Dealing with constraints
Use the alpha phase to explore any immovable constraints in legislation, contracts or legacy technology that affect the service you're planning to build. By the end of alpha, you should be able to explain:
- how you'll create a service that meets user needs while working within these constraints.
- where they're the type of constraints that can be removed over the long term (for example, by changing a technology platform or contracting with suppliers in a different way), the organisation's plan for doing this.
Working in the open
During alpha, you should continue to talk publicly about the prototypes you're building and what you're learning from them. For example, through blog posts and open show and tells. As part of this, think about ways to share what you're learning with operational delivery colleagues.
Reusing users' information where possible
It's often the case that, when interacting with related services, users have already given government the same information you need from them.
Use the alpha phase to investigate whether you can reuse that data, so that users do not have to provide the same information multiple times as they move from task to task. Unless there are public policy, trust or legal reasons not to share data, you'll be expected to show how you're working towards sharing it.
Providing a joined up experience across different channels
Point 3 of the standard says your service needs to work well across all the channels a user might use to access it.
This involves understanding how the online and offline parts of your service link together and any pain points users experience as a result of this.
You could work towards this at alpha by:
- including offline elements like letters in your alpha experiments and user research, especially where this relates to a risky assumption (for example, that you'll be able to change the content of letters).
- considering user journeys that start within a third party or non-government organisation, like referrals.
- inviting operational delivery colleagues to get involved in the alpha - they'll have a really useful perspective on what the riskiest assumptions are.
Making sure everyone can use your service
Info: Accessibility
Take a look at the Accessibility Guidance page for more information.
With an online prototype, you cannot apply the full range of technical accessibility tests you'd use for production code. But at alpha, you should be able to show that you:
- understand the WCAG accessibility principles - this will help you identify and test any specific accessibility challenges you're likely to face with your service
- are including disabled people in your user research
You do not have to get an accessibility audit at alpha, but it's worth starting to think about it because they can take time to arrange. And if you appoint your auditor during alpha, they can review your alpha designs or prototypes for potential accessibility problems giving you plenty of time to fix things.
Either way, by the end of alpha you should have a plan for how you're going to tackle accessibility at beta.
You should also be able to show that you've considered inclusion in the wider sense. This means:
- you've thought about whether there are likely to be pain points for particular groups of people when accessing the service (for example, if you're asking for someone's permanent address and your users include homeless people, you'll need to show that you've got a plan to stop them being excluded)
- including people with low levels of digital confidence in your user research
- you've started thinking about how you'll design the assisted digital support model for people who need help doing things online
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