githubEdit

2 Designing the Future Service (To-Be)

Before you start to-be

Before you start, check:

Skills required for the ‘As-Is’ phase

Skill area
Details

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

Criteria
Evidence

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

Session
Activities
Who to involve

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

Last updated

Was this helpful?