Design Service

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.

The service development phases

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)