2 Designing the Future Service (To-Be)
Before you start to-be
Before you start, check:
Skills required for the ‘As-Is’ phase
Product management
Identify assumptions related to the product’s success. Act as the decider within the team.
Delivery management
Manage delivery risks related to timelines or dependencies.
User research
Support the team to validate assumptions through testing and research.
Interaction and content design
Build prototypes and test hypotheses.
Service design or business analysis
Research internal processes and prototype the to-be high level user journey.
Technology
Identify technical risks and constraints, and guide technical choices.
Criteria for success for to-be
Create a shared target vision
Domain concepts, system boundaries, and interoperability needs are understood
Data boundaries diagram – Domain concepts, system boundaries, and interoperability needs are understood
Proposed system architecture
Generate and prioritise ideas
Ideas and key features prioritised
Draft the to-be service journey
. To-Be Journeys filled out
User journeys, workflows, and interactions are mapped
The future stage aligns with established design principles, patterns, and UX maturity expectations
Future workflows clarify omnichannel interactions and system orchestration
Stakeholders agree on to-be direction and what will be tested in the next phase
Moving to the test and learn stage
The to-be stage is complete when the team has explored plausible future service options and built enough confidence to begin testing and learning.
Before moving into the test and learn stage, teams should take a moment to reflect on the to-be work and agree:
which future service options or journeys are ready to be tested
which assumptions or hypotheses are most important to validate next
which parts of the service are sufficiently defined to prototype or trial
where uncertainty remains and further exploration or design work is needed
If the criteria above have been met and supporting evidence is in place, teams can make an informed decision to:
proceed to the test and learn stage to prototype and validate assumptions
continue the to-be phase to refine options or reduce uncertainty
return briefly to Discovery if new gaps or questions have emerged
This decision should be based on confidence and learning, not on pressure to progress.
Run a To-Be workshop
Day 1
Introduction & framing
60 minutes
Revisit As-Is outcomes and agreed focus areas. Clarify what the To-be stage is for and what it is not. Reconfirm scope and constraints. Explain how outputs will be used and what “good enough” looks like for this phase.
Future vision definition
15 minutes
A warm up activity to quickly create a shared future vision for the service.
Service owner, delivery team, policy representatives, user advocates
Build Domain Foundations (to-be)
60 minutes
Revisit domains and roles in the future service. Clarify how responsibilities or routines might change. Refine shared language and assumptions that will underpin design work.
Delivery team, subject matter experts, cross-organisation representatives
Event storming (future state)
2-3 hours
Explore how the future service should behave over time. Identify events, decisions, and outcomes.
Delivery team, technical leads, policy representatives, facilitators
Wrap up 15 minutes
Was this helpful?