3. Provide a joined up experience across all channels
This guidance will help you apply standard point 3.
Everyone is responsible for meeting the Service Standard. This standard point is most relevant to:
Why it's important
If a service moves between channels, for example, email, contact centres, paper forms, or in person, and you bring those different channels together, you can design an experience that reduces friction for users.
Understanding where your user needs fit into wider journeys can help to solve a whole problem for users.
Discovery
Things to consider:
- review channels that might be impacted by the policy intent or user needs. Speak with teams that work in any offline parts of your service, such as a call centre, and consider how an online service will affect them
- explore what you might want to prototype and test at alpha
- use relevant existing research and performance data across DfE
- map your service and the user journeys
Things to avoid in discovery
-
focusing on only one aspect of the journey
-
not including other channels
Alpha
Things to consider:
- use data and research to improve offline and online channels
- explore where your service should start and stop
- review all possible entry points, for example, how users find or know about it
- use common components, such as DfE Sign-in, to provide a consistent experience with other DfE services
- research with internal DfE teams who form part of the design of your service
- how you might encourage users to use your service
- understand gaps, drop-off points, re-entry loops, transitions to other channels and returns to your service
- consider the full end-to-end service, including the non-digital parts, for example, branding of an email matches that of the service it is sent from
Things to avoid in alpha
-
a service being built which is a live service. In alpha, you wouldn't be building a live service; you would be testing prototypes
Beta and live
Things to consider:
- use the GOV.UK Design System and DfE design systems and patterns. Only test new patterns where there is a clear user need and no suitable existing option
- iterate and change relevant artefacts to describe your end-to-end service based on user research. For example, service flows, blueprints, service maps
- understand how users will find your service and entry points
- plan how to onboard users
- observe and get feedback on the end-to-end journey
- monitor performance data of dropout points
- design and test offline processes and user support, including assisted digital routes, especially during public beta
Things to avoid in beta and live
-
the scope for private beta being too large. If the scope is too large, the service can actually become a version of the live service