Summary
Consider where your service fits in your users' journey and whether you can solve a whole problem or influence a wider solution.
Collaborate across teams, programmes and other services to create a service that meets users' needs across all channels in the end-to-end journey. For example, if users have to come in and then out of the service again to reach their end goal, what would that look like.
Why it's important
People often don't know how education services fit together. It helps if you can bring things together into a journey which makes sense to users, irrespective of which organisation they belong to or channel they use.
You may not be able to fix a whole problem, but you may be able to improve it and support or influence a wider solution.
How to meet this standard in every phase
You'll be assessed on what you've done to meet this standard at service assessments. However, even if the service you're working on is not being assessed, it's good practice to consider how you'll meet this standard point.
Discovery
Things to consider:
- an understanding of the problem space and whether the proposed alpha addresses the full problem or leaves gaps
- whether there are services that exist that solve some - or the same - problem and how this service would fit in with existing services to solve a whole problem
- design and research to collaborate with policy and other teams who are delivering services for similar users
- an understanding of policy constraints and crossover with other services or DfE content
Things to avoid in discovery
- designing solutions or building a service. Discovery is about understanding the problem that needs to be solved before committing to building a service
- not exploring if the benefits of looking further into the problem outweigh the cost of moving into alpha
- ending the service at the end of an application, for example, not when the user has achieved their goal
Alpha
Things to consider:
- evidence of where the service touches other services and whether you've spoken to those teams
- speaking to teams working on similar services to share knowledge of the types of users, user research carried out, or design work done to meet user needs
- how the team will talk through an end-to-end journey at a service assessment
- an understanding of non-digital or offline processes and their impact or relationship to the service
- how the service fits in with other channels or services relevant to your user group
- if you are providing a service to schools which will be used by people who use other DfE services, consider how to make the service consistent in the look and feel, the language used, and the tone of voice
- how the service will look and feel like other DfE services that are part of the same user journey
- creating a map of the current user journey, pain points, and what the user journey will look like
- how to make it easy for users to focus on the next step in a journey. For example, how to navigate their way through the service to help them achieve their goal
- how the concepts being tested avoid duplication of what already exists,
- join together other relevant services or DfE content to solve a whole problem
Things to avoid in alpha
- just designing a digital version of a paper process
- ending the service at a point that doesn't make sense for a user
- the scope for private beta being too large. The team won't be able to iterate the service if it's for too many users
Beta and live
Things to consider:
- using research and private beta analytics to show the service works. Demonstrate, with evidence, how users can get through the end-to-end journey unaided, especially during public beta
- collaborating with teams that make part of the end-to-end service
- an understanding of - and research for - the full end-to-end journey, including online and offline journeys and GOV.UK content
- how support, including assisted digital channels, are working
- how users will know about the service, does it have a starting point on GOV.UK?
- offline processes and user support, including assisted digital routes, have been designed and tested, particularly at public beta
- an understanding of non-digital or offline processes and their impact or relationship to the service
- user support process is in place
Things to avoid in beta and live
- not testing all service touch points
- not doing usability testing with users with access needs, separate from an audit
Profession specific guidance
Each DDaT profession in DfE has their own community and guidance.