# 2 Designing the Future Service (To-Be)

## Before you start To-be

\
Before you start, check:

* [ ] **There is a clear problem or opportunity to explore**\
  The team agrees what they are designing towards, not just what exists today.
* [ ] **The as-is service is understood well enough to challenge it**\
  The team has a shared view of how the service works today, including pain points and constraints.
* [ ] **Concepts and language are aligned**\
  The team shares a common understanding of important terms, roles, and responsibilities.
* [ ] **User needs are grounded in evidence**\
  The team can point to real user needs and challenges, not just assumptions or preferences.
* [ ] **Known gaps and uncertainties are explicit**\
  The team knows where confidence is lower and is designing with those uncertainties in mind.

## Skills required for the ‘As-Is’ phase

<table><thead><tr><th width="374">Skill area</th><th>Details</th></tr></thead><tbody><tr><td>Product management</td><td>Identify assumptions related to the product’s success. Act as the decider within the team.</td></tr><tr><td>Delivery management</td><td>Manage delivery risks related to timelines or dependencies.</td></tr><tr><td>User research</td><td>Support the team to validate assumptions through testing and research.</td></tr><tr><td>Interaction and content design</td><td>Build prototypes and test hypotheses.</td></tr><tr><td>Service design or business analysis</td><td>Research internal processes and prototype the to-be high level user journey.</td></tr><tr><td>Technology</td><td>Identify technical risks and constraints, and guide technical choices.</td></tr></tbody></table>

***

## Criteria for success for to-be

| Criteria                                                                                                                 | Evidence                                                                                                                                                                                                                                                                                                                                                                                        |
| ------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <p>Create a shared target vision</p><p>Domain concepts, system boundaries, and interoperability needs are understood</p> | <ul><li>Data boundaries diagram – Domain concepts, system boundaries, and interoperability needs are understood</li><li>Proposed system architecture</li></ul>                                                                                                                                                                                                                                  |
| Generate and prioritise ideas                                                                                            | Ideas and key features prioritised                                                                                                                                                                                                                                                                                                                                                              |
| Draft the to-be service journey                                                                                          | <p>. To-Be Journeys filled out</p><ul><li>User journeys, workflows, and interactions are mapped</li><li>The future stage aligns with established design principles, patterns, and UX maturity expectations</li><li>Future workflows clarify omnichannel interactions and system orchestration</li><li>Stakeholders agree on to-be direction and what will be tested in the next phase</li></ul> |

### Moving to the test and learn stage <a href="#moving-to-the-next-phase" id="moving-to-the-next-phase"></a>

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 <a href="#heading-title-text" id="heading-title-text"></a>

### Day 1

| Session                                                                            | Activities                                                                                                                                                                                                                 | Who to involve                                                            |
| ---------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| <p><strong>Introduction & framing</strong></p><p><em>60 minutes</em></p>           | 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. |                                                                           |
| <p><strong>Future vision definition</strong></p><p><em>15 minutes</em></p>         | A warm up activity to quickly create a shared future vision for the service.                                                                                                                                               | Service owner, delivery team, policy representatives, user advocates      |
| <p><strong>Build Domain Foundations (to-be)</strong></p><p><em>60 minutes</em></p> | 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 |
| <p><strong>Event storming (future state)</strong></p><p><em>2-3 hours</em></p>     | Explore how the future service should behave over time. Identify events, decisions, and outcomes.                                                                                                                          | Delivery team, technical leads, policy representatives, facilitators      |
| <p><strong>Wrap up</strong><br><br><em>15 minutes</em></p>                         |                                                                                                                                                                                                                            |                                                                           |