Understanding service boundaries

Cross-service journeys

Part of: Design collection Last reviewed: 4 June 2026

Users do not think in terms of services or products. They think in terms of goals.

For example:

“I want to become a teacher”

This is a goal that spans multiple DfE products, including:

Each product has its own team, technology and, where appropriate, its own design. But the user experiences them as one journey.

When defining your service boundaries, map the journeys that connect your service to adjacent services.

Where do users come from?

Ask:

  • what service or information source do users use immediately before yours?
  • is there a clear link into your service?
  • do users have to search again?
  • do users understand why they are moving from one service to another?

Useful links:

Where do users go next?

Ask:

  • after completing your service, what is the user’s next step?
  • do you tell them what happens next?
  • do they have to figure it out for themselves?
  • is the next step owned by your team or another team?
  • is the transition clear, expected and supported?

Useful links:

What data crosses the boundary?

Ask:

  • does the next service need information the user has already provided?
  • can that information be passed on safely and appropriately?
  • will the user have to enter the same information again?
  • what identifiers are needed to connect the services?
  • what happens if data is missing, incorrect or out of date?

Useful links:

Service Standard point 2

The Service Standard requires teams to:

“Solve a whole problem for users.”

This does not mean you have to build everything yourself.

It means you need to understand the whole problem and design for the connections between services, even when those services are run by other teams.

You should be able to show:

  • how your service fits into the user’s wider goal
  • what happens before and after your service
  • where users move between services, teams or channels
  • how handoffs are designed
  • how risks, gaps and unclear ownership are managed

Useful links:

Dependencies and integrations

Most DfE services depend on other services, data sources, systems or organisations.

Map these dependencies during discovery so you understand what is within your control, what you can influence, and what sits outside your control but still affects the user experience.

Dependency type Examples Implications for design Useful links
Data dependencies Get Information about Schools, View your education data, DfE Sign-in What happens if the data source is unavailable? How do you handle stale data? Can users correct data errors? Get Information about Schools, DfE Sign-in
Process dependencies Approvals, checks, reviews, casework, moderation, validation, funding decisions How long does each step take? How do you keep users informed while they wait? What happens if an approval is delayed? Service Standard point 4: make the service simple to use, Service Standard point 10: define what success looks like
Organisational dependencies Schools, training providers, local authorities, Ofsted, professional bodies These organisations have their own priorities, processes and timelines. Design for their constraints, not just your users’ preferences. Service Standard point 2: solve a whole problem for users, Service Standard point 3: provide a joined up experience across all channels
Technical dependencies GOV.UK Forms, GOV.UK Notify, DfE Sign-in, legacy databases, APIs, reporting systems Use platform services where possible. Design graceful fallbacks for when dependencies fail. GOV.UK Forms, GOV.UK Notify

Avoiding fragmentation and duplication

Fragmentation happens when service boundaries follow organisational structures instead of user journeys.

The result is multiple disconnected services that each do part of the job, but none of them solves the whole problem for the user.

Signs of fragmentation include:

  • users entering the same information in multiple services
  • users not knowing which service to use for their situation
  • users being passed between teams or products
  • support teams spending time redirecting users
  • services using different language for the same thing
  • teams measuring their own transaction but not the wider outcome
  • handoffs between services being unclear or unmanaged

Useful links:

How to prevent fragmentation

Map by user goal, not by team

If three teams serve different aspects of the same user goal, the service boundary should span all three, even if the implementation does not.

Do not limit your map to what your team owns.

Map the full user goal first, then decide:

  • what your team owns
  • what your team influences
  • what another team owns
  • where the handoffs and risks are

Useful links:

Talk to adjacent teams early

In discovery, identify the teams whose services connect to yours.

Invite them to share:

  • user research
  • analytics
  • support data
  • service maps
  • design work
  • operational constraints
  • known risks and pain points

This helps teams design the connections between services before users experience them as gaps.

Useful links:

Design the joins

Even if you cannot merge services, you can design clear, well-signposted transitions between them.

This includes:

  • clear onward links
  • consistent language
  • shared content
  • agreed handoff points
  • clear ownership
  • status updates
  • confirmation messages that explain what happens next
  • support routes if something goes wrong

Useful links:

Use common identifiers

If the same user, organisation or case appears in multiple services, use consistent identifiers so data can flow between them.

Examples include:

  • email address
  • teacher reference number
  • unique reference number
  • organisation identifier
  • application reference
  • case reference

Common identifiers can reduce duplication, improve reporting and help users avoid repeating information.

Useful links:

Consider the universal barriers

Complex services amplify every barrier.

For example:

  • comprehension gets harder as jargon increases
  • time burden grows as steps increase
  • self-confidence reduces when users are confused
  • trust reduces when services feel disconnected
  • support needs increase when users cannot predict what happens next

Absorb complexity so users do not have to.

See the Universal barriers to inclusion guidance for the full framework.

Useful links: