Design
Understanding service boundaries
Understand how to define service boundaries based on user journeys, so you design end-to-end services, avoid fragmentation, and deliver consistent user experiences.
Define where your service starts and ends, identify dependencies and integrations, and avoid the fragmentation that happens when boundaries are drawn around organisational structures rather than user journeys.
Why boundaries matter
The boundaries of your service determine what you design, what you build, and what you measure.
If you make them too narrow, you will build a transaction that works in isolation but fails users in context.
For example:
- a form that submits correctly but does not tell the user what happens next
- a form that does not explain how long the user will wait
- a service that does not tell the user who to contact if they need help
Define them too broadly and you will try to solve problems that belong to other teams. This can stretch your resources, slow delivery, and result in a sub-standard service.
Getting boundaries right is fundamentally a discovery activity. It requires understanding the user's complete journey. This includes:
- the parts that happen before they reach your digital service
- the parts that happen while they are waiting for an outcome
- the parts that happen after they get their answer or outcome
Service boundaries also determine how you relate to other teams. When two services share a boundary, someone has to design the handoff between them. If neither team owns the handoff, users fall through the gap.
Design Principle 8: build digital services, not websites
“The digital world has to connect to the real world, so we have to think about all aspects of a service and make sure they add up to something that meets user needs.”
This means your service boundary must include real-world interactions such as:
- phone calls
- emails
- letters
- waiting periods
It must not just include the digital transaction.
Defining the start and end points
A service starts when the user first becomes aware they need to do something.
It ends when they have achieved their outcome or been definitively told they cannot.
Everything between those points is the service, whether it is:
- digital
- phone-based
- postal
- face-to-face
The user’s start point is rarely your start page
Most users arrive at a government service from:
- a search engine
- a GOV.UK guidance page
- a link from another organisation
Their journey starts before your service's start page.
You need to understand what happens before they reach you:
- how does the user first learn this service exists?
- how do they decide it is the right service for their situation?
- what information do they need to gather before they can begin?
- have they already tried and failed with a different approach?
The user’s end point is rarely your confirmation page
For many DfE services, submission is the midpoint, not the end.
The user submits an application, then waits days or weeks for a decision. During that time, they may:
- check their status
- receive emails
- phone for updates
The waiting period is part of the service and needs designing.
How to map your service boundary
Mapping your service boundary is a collaborative exercise that should happen early in discovery.
It should involve the whole team, be led by service designers, user researchers and product managers, and draw on research with real users, not assumptions.
Start with the user’s goal
What is the user ultimately trying to achieve?
For example:
- “become a qualified teacher” is a goal
- “submit an application form” is a task within a service, not a goal
Map everything before the digital service
Understand what happens before the user reaches your digital service.
Ask:
- how does the user learn about the service?
- what do they need to know before they can start?
- what do they need to have ready before they can start?
- what other services or information sources do they use first?
Map the digital journey
This is the part teams usually know best.
Map:
- screens
- questions
- logic
- forms
- validation
- confirmation pages
Map everything after the digital interaction
Understand what happens after the user submits or completes the digital interaction.
Ask:
- what happens when they submit?
- how long do they wait?
- how are they notified?
- what do they do if there is a problem?
- what happens when they get their outcome?
Mark the boundaries
Decide which parts are:
- within your team's direct control
- within your influence, where you can change them by working with other teams
- outside your control entirely
Design for all three, but prioritise them differently.
Identify the handoffs
Identify where the user moves from your service to another service, team, organisation or channel.
Ask:
- who owns the transition?
- what information moves with the user?
- what does the user need to understand?
- how does the user know what happens next?
- what happens if something goes wrong?
If nobody owns the handoff, that is one of your biggest service risks.