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
Who should be involved
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.
How to do it
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.
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.
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.
Identify issues and risks Highlight pain points, delays, duplication, manual work, or failure points.
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.
Document the journey map Make sure the map is documented in a way that can be easily shared and understood.
Use our Journey Mapping Template (opens in Figma, go to file > save local copy) to create As-Is and To-Be journey.
Watch a video tutorial for using the Journey Mapping Template (opens in YouTube)
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.
How to do it
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.
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.
4. Capture the glossary
Consolidate agreed terms, definitions, and any differences in meaning into a simple, shared format.
Keep the output lightweight and easy to update.
Last updated
Was this helpful?