Complete firstClear scope
Agree the subject, boundary and decision before filling the model.
A broad or mixed scope produces a misleading model.
Method guideKnowledge Modeling
Domain Storytelling
A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.
ComplexityLow
Time1-2 h
Participants2-8
FormatWorkshop
MaturityEstablished
01
Prerequisite
What needs to be finished first
Complete firstAccess to relevant evidence
Bring source material and people who know the work; distinguish facts from assumptions.
Unverified interpretations become false certainty.
02
Preparation
What needs to be ready before start
Materials
Shared visual workspace, source evidence, and an agreed decision question.
People / roles
Domain expert as narrator, facilitator, modeler, developers or analysts.
Pre-read
Collect existing data, examples, constraints and relevant stakeholder perspectives.
Time needed
60–120 min for one scenario; schedule separate sessions for other flows.
Setup
Choose one familiar, bounded business situation with domain experts. Let the expert tell what happens; number each concrete activity in order. Draw actors and work objects; connect each object to the activity that changes/uses it. Ask for concrete terms, decisions, exceptions and rules when abstractions appear. Replay the story with experts; capture language, open questions and model implications.
03
Core question
The one question this method answers
How do actors work toward a business outcome, including exceptions?
04
Flow
Phases with goal, actions, output and pitfall
Makes domain knowledge discussable through a concrete story of actors, work objects and activities.
Domain story record
Fictional worked example
Fictional, numbered story: (1) Patient asks for a follow-up. (2) Reception checks calendar. (3) Reception offers two slots. (4) Patient chooses one. (5) Reception confirms appointment. Work objects: calendar, slot, appointment. Domain question: when is the slot reserved as binding?
Situation and scope
Describe a concrete domain case with start and outcome.
Fictional: patient books a follow-up.
Actors
Name participating people or systems.
Patient, reception.
Activities
Number activities and connect work objects.
Check calendar; offer two slots.
Work objects
Record work objects with concrete domain meaning.
Calendar, slot, appointment.
Rules and questions
Separate conditions, exceptions and unknown rules.
When is a slot reserved as binding?
The example text is fictional; replace it with sourced project information.
- 1
Situation
Choose a concrete situation
Goal
Story scope
Inputs for this step
- Domain expert, shared context and real case
Actions
- Choose a bounded real business case with a beginning and outcome, not the entire process or target future.
Output
Story scope
Story scope
Quality check
Can participants retell the case concretely?
Pitfall
The group starts with abstract system requirements. Ask for a recent example and focus on that case.
Timing: Allow time according to scope and evidence; no universal duration.
- 2
Story
Tell and number the story
Goal
Numbered domain story
Inputs for this step
- Storyteller, facilitator and cards
Actions
- Let the domain expert narrate activities and number them in order without correcting the model prematurely.
Output
Numbered domain story
Numbered domain story
Quality check
Does the sequence reflect the narrated situation?
Pitfall
Analysts take over and smooth away exceptions. Let the domain expert use their own words.
Timing: Allow time according to scope and evidence; no universal duration.
- 3
Objects
Connect actors and work objects
Goal
Pictographic model with legend
Inputs for this step
- Story, roles and named work objects
Actions
- Draw actors as doers and work objects as things worked on; connect each to the activity that uses or changes it.
Output
Pictographic model with legend
Pictographic model with legend
Quality check
Can readers distinguish actor, action and object?
Pitfall
Abstract process boxes hide domain objects. Ask directly who does what with which object.
Timing: Allow time according to scope and evidence; no universal duration.
- 4
Review
Validate terms, rules and gaps
Goal
Validated story and question list
Inputs for this step
- Model, glossary and domain expert questions
Actions
- Replay the story, confirm meanings and label rules, variants and unresolved questions.
Output
Validated story and question list
Validated story and question list
Quality check
Do experts confirm terminology and exceptions?
Pitfall
One story is generalized into a universal process. Mark variants and inspect more cases before generalizing.
Timing: Allow time according to scope and evidence; no universal duration.
05
Artifact
What comes out at the end
Sketch: what the artifact looks like
Form
Makes domain knowledge discussable through a concrete story of actors, work objects and activities. Record scope, evidence, assumptions, owner and next review in the versioned artifact.
Versioning / ownership
Record scope, date, participants, source version and owner. Note changed assumptions and the reason for each revision.
Tool alternatives
- Shared whiteboard or paper template
- Source links, records or measurement data
domain-storytelling-working-template.md
Prepare the decision, source evidence and next review.
Domain Storytelling: Worksheet
Question
To be confirmed
Desired outcome
To be confirmed
Scope
Run the method Time: See catalog planning range; no universal duration.
Complete this worksheet on paper or in your own document during the work.
Preparation for this scope
Method setup
- Materials: Shared visual workspace, source evidence, and an agreed decision question.
- Roles: Domain expert as narrator, facilitator, modeler, developers or analysts.
- Advance information: Collect existing data, examples, constraints and relevant stakeholder perspectives.
- Overall time needed: 60–120 min for one scenario; schedule separate sessions for other flows.
- Setup: Choose one familiar, bounded business situation with domain experts. Let the expert tell what happens; number each concrete activity in order. Draw actors and work objects; connect each object to the activity that changes/uses it. Ask for concrete terms, decisions, exceptions and rules when abstractions appear. Replay the story with experts; capture language, open questions and model implications.
Prepare for the work steps
Situation: Choose a concrete situation
- Domain expert, shared context and real case
Story: Tell and number the story
- Storyteller, facilitator and cards
Objects: Connect actors and work objects
- Story, roles and named work objects
Review: Validate terms, rules and gaps
- Model, glossary and domain expert questions
Domain story record
Situation and scope
Describe a concrete domain case with start and outcome.
...
Actors
Name participating people or systems.
...
Activities
Number activities and connect work objects.
...
Work objects
Record work objects with concrete domain meaning.
...
Rules and questions
Separate conditions, exceptions and unknown rules.
...
This blank document contains only section prompts.
Quick-Start Guide · Domain Storytelling
Situation: Choose a concrete situation
Expected artifact: Story scope
Story scope
Entry:
...
- Can participants retell the case concretely?
Story: Tell and number the story
Expected artifact: Numbered domain story
Numbered domain story
Entry:
...
- Does the sequence reflect the narrated situation?
Objects: Connect actors and work objects
Expected artifact: Pictographic model with legend
Pictographic model with legend
Entry:
...
- Can readers distinguish actor, action and object?
Review: Validate terms, rules and gaps
Expected artifact: Validated story and question list
Validated story and question list
Entry:
...
- Do experts confirm terminology and exceptions?
Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/domain-storytelling/run-sheet
06
Example output
Concrete filled scenario, fictional example
Fictional example for orientation. Counts and timings describe this case and are not universal requirements.
domain-storytelling-beispiel.md
Concrete filled scenario, fictional example
Fictional, numbered story: (1) Patient asks for a follow-up. (2) Reception checks calendar. (3) Reception offers two slots. (4) Patient chooses one. (5) Reception confirms appointment. Work objects: calendar, slot, appointment. Domain question: when is the slot reserved as binding?
07
Pitfalls
Recognize symptoms and steer against them
Quick overview, the full text is in the matching phase in the flow
- Choose a concrete situationThe group starts with abstract system requirements.View in phase
- Tell and number the storyAnalysts take over and smooth away exceptions.View in phase
- Connect actors and work objectsAbstract process boxes hide domain objects.View in phase
- Validate terms, rules and gapsOne story is generalized into a universal process.View in phase
Trap
Choose a concrete situation
Symptom
The group starts with abstract system requirements.
What to do
Ask for a recent example and focus on that case.
Trap
Tell and number the story
Symptom
Analysts take over and smooth away exceptions.
What to do
Let the domain expert use their own words.
Trap
Connect actors and work objects
Symptom
Abstract process boxes hide domain objects.
What to do
Ask directly who does what with which object.
Trap
Validate terms, rules and gaps
Symptom
One story is generalized into a universal process.
What to do
Mark variants and inspect more cases before generalizing.
08
Stop criteria
When to pause, resolve prerequisites, or choose another approach
Stop if the decision question or scope is disputed; align it first.
Stop if key inputs are unavailable; list what evidence is needed.
Stop if the group treats assumptions as observed facts.
Finished the method guide?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.