Standard point 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:

Designers User researchers

---

Summary

Consider where your service fits into a wider journey or alongside other DfE services, and how it will join up across channels.

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.

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.

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:

• any channels that might be impacted by the policy intent or user needs. Speak with teams that work in any offline parts of the service, such as a call centre, and consider how an online service will affect them

• what you might want to prototype and test at alpha

• use of existing research and performance data across DfE

• service and user journey mapping

Things to avoid in discovery

• focusing on one aspect of the journey only

• not including other channels

Alpha

Things to consider:

• data and research being used to improve offline and online channels

• how you've explored where the service should start and stop

• use of 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 the service

• entry points to the service. For example, how users find or know about it

• how you might encourage users to use your digital service

• gaps, drop-off points, re-entry loops, transitions to other channels and returns to the service

• how design, user research, and content design are considering 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 of GOV.UK Design System and patterns or testing new patterns where needed

• the right artefacts to describe the end-to-end service are being iterated and changed based on user research. For example, service flows, blueprints, service maps

• how users will find the service and entry points

• a plan for how to onboard users to the service

• the team observing and getting feedback on the end-to-end journey

• performance data monitoring of dropout points

• offline processes and user support, including assisted digital routes, have been designed and tested, 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

Profession specific guidance

Each DDaT profession in DfE has their own community and guidance.

• User Research Manual
• Design Manual
• Architecture
• Technical Guidance