# 1.1 Understand the Context and System

Map the as-is service
\\

A collaborative activity to describe how a service currently works from the user (front stage actions) and operational (Backstage actions like systems, operations and data decisions) perspective. It helps teams build a shared understanding of:

* the steps users go through today
* who is involved at each step
* where systems, data, and decisions sit
* pain points, gaps, and inefficiencies in the current service

<figure><img src="/files/M17LSd3IQeuEREnRlJ5a" alt=""><figcaption><p>As-is and to-be mapping</p></figcaption></figure>

<details>

<summary><strong>Who should be involved</strong></summary>

Where possible, involve:

* people who deliver or operate the service day to day
* subject matter experts who understand policy, rules, or constraints
* members of the delivery team (design, product, technology)
* a user, user advocate, or someone close to users

This helps ensure the map reflects reality rather than assumptions.

</details>

<details>

<summary><strong>How to do it</strong></summary>

1. **Define the scope**\
   Within the team, agree which service, user group, or scenario you are mapping.\
   Agree what the start/entry point is and when the journey is completed or the user’s problem is resolved.\
   &#x20;

   <figure><img src="/files/3fBPZDBYBCAbkPwZFZCA" alt=""><figcaption></figcaption></figure>
2. **Map the steps in the journey**\
   Capture the main steps the user goes through, in plain language. Start with your agreed first and last steps then fill in the gaps.\ <br>

   <figure><img src="/files/Lc1uGuvihIS7r2l11R0G" alt=""><figcaption></figcaption></figure>
3. **Add supporting activities for other rows**\
   Note what happens behind the scenes at each step (people, systems, data, decisions). Capture any known relevant legislation either as a row in the map or as another document.<br>

   <figure><img src="/files/LtYNOniancPX6sjuTYOW" alt=""><figcaption></figcaption></figure>
4. **Identify issues and risks**\
   Highlight pain points, delays, duplication, manual work, or failure points.\ <br>

   <figure><img src="/files/qXJl3uY9zf7J8slF6lts" alt=""><figcaption></figcaption></figure>
5. **Review and agree**\
   Sense-check the map with participants and confirm it reflects the current service. You may start to highlight priority areas to improve through this activity.\ <br>

   <figure><img src="/files/FghwLS2Ykyjt01AJB7pY" alt=""><figcaption></figcaption></figure>
6. **Document the journey map**\
   Make sure the map is documented in a way that can be easily shared and understood.&#x20;

{% hint style="info" %}
Use our [Journey Mapping Template](https://www.figma.com/file/w9oqWWuuxWtab5EPJIVhhA/Journey-Template?type=whiteboard\&node-id=502-3589\&t=2jbkrrXKAmGpPeg6-0) (opens in Figma, go to file > save local copy) to create As-Is and To-Be journey.
{% endhint %}

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

Watch a [video tutorial for using the Journey Mapping Template](https://www.youtube.com/watch?v=sKnTfcUm2z4) (opens in YouTube)

</details>

<details>

<summary><strong>Outputs</strong></summary>

* [ ] As-is user journey maps for each of your prioritised users or user journeys
* [ ] A list of pain points or opportunities

</details>

***

## Model the domain

Build a shared understanding of a service to support design and delivery by:

* identifying the important things the service deals with (such as information, records, or decisions)
* clarifying what those things mean and who uses or manages them
* creating a shared language for the service domain

The output will be a **glossary** that teams can refer back to throughout the project.

Domain modelling is about shared understanding, not precision.\
It is not technical architecture, data modelling, or detailed process mapping.

<details>

<summary><strong>How to do it</strong></summary>

This activity works best when run with a mix of service operators and people who are experts within the respective domains, e.g. in “civil registration domain” when designing the service to obtain a birth certificate online.

#### **1. Identify key terms**

Ask participants to list important things the service deals with, using short, plain-language nouns. These terms often become the foundation for data models, APIs, and specifications.<br>

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

#### **2. Agree meanings**

For each term, capture a short definition and clarify who creates, uses, or approves it.

#### **3. Explore relationships**

Arrange terms to show dependencies, reuse, or handoffs between teams or institutions.<br>

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

#### **4. Capture the glossary**

Consolidate agreed terms, definitions, and any differences in meaning into a simple, shared format.<br>

<figure><img src="/files/9k6jvEV7qvZXCPGv9BFa" alt=""><figcaption></figcaption></figure>

Keep the output lightweight and easy to update.

</details>

<details>

<summary><strong>Outputs</strong></summary>

* [ ] A domain diagram
* [ ] A service glossary

</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.1/implementation/design-service/1-understanding-the-current-service-as-is/1.1-understand-the-context-and-system.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.