After prioritizing services we now have a clear picture of the service(s) that need to be implemented first. In the following chapter you'll find a guidance on how to design one specific chosen service. After or while implementing one you can already start with the design of the next in the priority list
Reduce the risk of building the wrong thing by understanding the service domain and user needs early, testing ideas quickly, and by iterating and improving.
 (2).png)
Each phase answers specific questions and produces artefacts that inform the next.
The phases:
- Understanding the Current Service (As-Is) before proposing solutions
- Designing the Future Service (To-Be) before investing in detailed design or build
- Testing and Validating the Service before committing to full-scale delivery
Movement between phases is guided by confidence and evidence, not by completing every activity. Teams may:
- Loop back to previous activities when new insights emerge
- Run phases in parallel for different parts of a service
- Revisit earlier artefacts as assumptions change
Each phase ends with a set of deliverables that help teams decide whether they are ready to move forward, pause, or revisit earlier work.
Understanding the Current Service (As-Is)
Build a shared understanding of the problem space before committing to solutions.
In this phase, teams explore:
- user needs and service context
- existing systems, actors, and dependencies
- constraints, risks, and assumptions
The aim is to agree what problems are worth solving, for whom, and why.
Deliverables:
- Clear problem statement(s)
- Initial user needs and priority groups
- As-is user journey(s)
- Stakeholder and ecosystem map
- Known constraints, risks, and assumptions
Designing the Future Service (To-Be)
Agree what the future service should achieve and how it should work at a high level.
In this phase, teams:
- describe the intended future experience
- generate and explore service concepts
- establish shared foundations such as domain language, data concepts, and boundaries
The aim is to create enough clarity and alignment to guide delivery decisions.
Deliverables:
- To-be service vision or narrative
- High-level to-be user journey(s)
- Service principles or success measures
- Domain glossary and shared language
- Initial data concepts and boundaries
Testing and Validating the Service
Reduce uncertainty before full-scale development.
In this phase, teams:
- prototype and test ideas with users and stakeholders
- validate assumptions and hypotheses
- learn what works (and what does not)
The aim is to use evidence to refine direction and avoid costly mistakes later.
Deliverables:
- Prototypes (low- or high-fidelity)
- Documented assumptions and hypotheses
- Evidence from user testing or pilots
- Refined service concepts and journeys
- Clear decisions on what to proceed with (or stop)