2.4 Define the To-Be Service and Blueprint the Experience
Draft the “to-be” service journey
Describe and explore a future end-to-end service journey, bringing together:
user needs and outcomes
future service behaviour
organisational roles and responsibilities
enabling systems and building blocks
The goal is to make assumptions visible and test whether proposed ideas can work as a service.
How to do it
Move through this activity in layers, starting simple and adding detail where it adds value.
1. Start with the user journey
Begin by drafting a high-level to-be user journey.
Use our Journey Mapping Template (opens in Figma, go to file > save local copy) to create a To-Be journey.
Focus on:
what the user is trying to achieve
the main steps or phases of the service
key moments that matter to the user
At this stage, avoid internal process detail. The aim is to describe the experience from the user’s point of view.
2. Use service patterns to shape the journey
Once the high-level journey is visible, use service patterns to help structure and challenge it.
Start by identifying relevant action patterns, like:
find a service
check eligibility
apply or request
receive updates
receive a decision
After this, identify relevant functional patterns for each action (for example identity, messaging, payments). Each functional pattern is made up of potential steps that make up the journey.
3. Expand into a service blueprint
Once the journey feels coherent, teams can add further layers to create a to-be service blueprint.
Use our Service Blueprinting Template (opens in Figma) to create a Service Blueprint.
Depending on context, this may include:
frontline or back-office roles
systems or building blocks involved
hand-offs between organisations
policies, rules, or data dependencies
Not every service needs a full blueprint. Add detail only where it helps uncover risk, complexity, or decision points.
Watch a video tutorial for using the Service Blueprinting Template (opens in YouTube)
4. Sense-check and refine
Use the journey or blueprint to test assumptions:
does this respond to known user needs?
where are we assuming things will “just work”?
which steps feel risky, unclear, or expensive?
what would need to be tested before delivery?
Capture open questions, risks, and dependencies directly on the journey or blueprint.
Was this helpful?