# Design Service

Design and deliver government services that work, using GovStack tools and patterns.

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

<figure><img src="/files/JyWEpbTVf4JP5UFEQRHp" alt=""><figcaption></figcaption></figure>

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.

<details>

<summary><strong>Understanding the Current Service (As-Is)</strong></summary>

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

</details>

<details>

<summary><strong>Designing the Future Service (To-Be)</strong></summary>

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

</details>

<details>

<summary><strong>Testing and Validating the Service</strong></summary>

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)

</details>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://specs.govstack.global/implementation-playbook/1.0.0-rc/implementation/design-service.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.