2.3 Establish the Domain Foundations
Build Domain Foundations
Content work in progress
Help teams build a shared understanding of the service domain before committing to detailed design or delivery.
The focus is on clarifying roles, responsibilities, concepts, and routines to create a stable foundation that user journeys, service blueprints, and technical decisions can build on.
Read more about domain foundations
How to do it
Teams work through four simple steps: Decompose, Strategise, Collect, and Organise. All steps can be done on paper or a whiteboard.
1. Decompose the service
Break the service down into distinct areas of responsibility or concern.
A domain is a bounded area where:
a specific role operates
a set of routines or decisions happen
particular rules or constraints apply
At a minimum, most services include:
a user or citizen domain
one or more government or processing domains
Facilitator prompts
Who is involved in delivering or using this service?
Where does responsibility clearly change hands?
Which parts of the service operate under different rules or constraints?
2. Strategise the domains
Discuss the importance and complexity of each domain.
Some domains:
are core to delivering value
carry higher risk or policy sensitivity
require more flexibility or future change
Others may be:
supporting or administrative
more stable over time
This helps teams decide where to focus attention and avoid treating all parts of the service as equally complex.
Facilitator prompts
Which domains are most critical to user outcomes?
Which domains are hardest to change?
Where do failures or delays usually occur?
3. Collect domain knowledge
For each domain, collect the key information needed to understand how it works.
This may include:
main roles and responsibilities
typical routines or tasks
decisions made and outcomes produced
rules, policies, or constraints that apply
Use simple language and examples. Avoid technical detail at this stage.
This step often surfaces:
different interpretations of the same terms
gaps in understanding
assumptions that need testing
4. Organise and align
Bring the information together into a shared view of the domain foundations.
This may result in:
a simple domain map
a shared glossary or service dictionary
notes on how responsibilities change in the future service
Focus on alignment rather than precision. The output should be good enough to support design, not a final model.
Facilitator prompts
Do we agree on what these terms mean?
Are responsibilities clear?
What feels uncertain or contested?
Was this helpful?