Choosing the Right Framework — Matching the Framework to the Question

What You'll Learn

• Match a business situation to the disambiguation framework best suited to resolve its specific ambiguity.
• Describe the typical sequence in which frameworks are combined and explain why that order makes sense.
• Identify at least two situations where the typical sequence should be broken or a single framework used on its own.
• Walk into a project kickoff and recommend which framework to start with, using the four diagnostic questions as your guide.
• Articulate the core contrast between event storming (bottom-up, from events) and impact mapping (top-down, from goals), and know when each starting point is the right one.

Why This Matters

This module resolves the ambiguity of which framework to reach for by making the decision criteria explicit and shared.

You have now seen six disambiguation frameworks across this plan. That is a lot of tools. The risk — and it is a real one — is that you leave with a sense of capability but no clear idea of what to do first when you walk into your next kickoff. Teams that learn these frameworks and then try to use all of them on every project waste time and erode trust in the techniques themselves. The skill that separates a practitioner from someone who read the book is knowing which question each framework answers, and stopping to ask what question is actually unanswered in your situation right now.

This is not about finding the "best" framework. It is about diagnosing the specific gap in your team's shared understanding and picking the tool that closes it.

Core Concept

Every disambiguation framework exists to answer a particular kind of question. When you get that match right, the framework feels obvious and productive. When you get it wrong, the workshop drags and the output sits unused. The selection principle is straightforward: start by identifying what you are trying to learn, then choose the framework that serves that learning need.

There are four diagnostic questions — one for each framework:

"Do we understand how our business process actually works?" If you cannot confidently describe the sequence of events from end to end, or if the room contains people who disagree about that sequence, you have a domain discovery problem. Event storming (the collaborative workshop in which teams map domain events — significant things that happened in the business, written in past tense — on a shared timeline) is the right tool here. It is bottom-up: you start from what actually happens and build understanding upward. Use event storming when the domain is unfamiliar, when multiple teams have different stories about the same process, or when no one has ever mapped the end-to-end flow.

"Do we know who owns what and where the handoffs are?" If you can describe what happens but not who is responsible for each piece, or if teams are arguing about ownership and integration points, you have a boundary problem. A context map (a visual sketch showing the relationships and handoffs between bounded contexts — clearly defined boundaries within which a specific team uses consistent terminology and owns a coherent set of capabilities) is the right tool. Use it after you have enough understanding of the domain to identify where the seams between teams and systems actually fall.

"Do we agree on why we are building this?" If there is disagreement about what success looks like, or if stakeholders have different definitions of the goal, you have an alignment problem. An impact map (a mind-map structured around four levels — Goal, Actor, Impact, Deliverable — that traces every feature back to a business goal) is the right tool. It is top-down: you start from the goal and work down to what must be built. Use impact mapping when a project has been framed in terms of features rather than outcomes, or when the "why" behind a proposal is murky.

"Do we know what the user experiences and in what order we build it?" If the goal is clear and the domain is understood, but the team cannot agree on what the first release should contain or cannot see the user journey end to end, you have a sequencing problem. A user story map (a visual, two-dimensional grid that organises user activities horizontally and details vertically to preserve the user journey while enabling release planning) is the right tool. Use it when you are ready to plan delivery and need to draw release lines — horizontal cuts across the map that group which stories go into a given release.

The typical sequence for a new domain

When a domain is genuinely new and poorly understood, these frameworks have a natural order:

1. Event storming — Discover what actually happens. Get all the domain experts in one room and map the events. This produces shared vocabulary and a timeline that everyone can argue about and eventually agree on.
2. Context mapping — Once you can see the full landscape, identify the boundaries. Which teams own which events? Where do the handoffs happen? Draw the context map to make those seams visible.
3. Impact mapping — Now that you understand the domain and its boundaries, ask: why are we building this, and what changes if we succeed? An impact map connects the process you just mapped to the business goal driving the investment.
4. User story mapping — With goal clarity and domain understanding in place, plan the delivery. A user story map turns the actor journey into a sequenced set of releases.

This order respects the prerequisite flow: you cannot draw sensible boundaries without first understanding the domain; you cannot prioritise features without knowing who they are for and why they matter; you cannot sequence delivery without understanding the user's end-to-end experience.

When to break the sequence

The sequence above is a default, not a rule. Here are three situations where a different starting point is better:

• Optimising a well-understood process: If the domain is already well-known — the team has run the process for years and can describe it from memory — skip Big Picture event storming. A focused Process Modeling session on the specific subprocess you are improving is faster and more productive.
• Making a business case for an architectural change: If the goal is to get stakeholder buy-in for a significant investment (a platform migration, a new team structure), start with impact mapping. The business case needs to be framed around outcomes first; the domain work can follow.
• Clear goal, unclear user journey: If a small product team already agrees on the goal and has a solid understanding of the domain, go straight to user story mapping. Impact mapping and event storming would add overhead without adding insight.

The DDD core vocabulary as the shared floor

Across all four frameworks, you always need the foundation: a ubiquitous language (the shared vocabulary agreed on by both business experts and engineers, used consistently in conversations, documents, and code). You do not always need a formal DDD workshop to establish it — sometimes the vocabulary emerges naturally from the event storming session itself — but without it, every other framework will use words that mean different things to different people, and the artifacts you produce will not survive contact with the engineering team.

Concrete Example

Meridian Insurance has a new initiative: the Claims team wants to redesign their settlement process. The team calls you in. Everyone is ready to run an event storming session — it is the framework they know, and it feels like the obvious start. But you stop and ask the four diagnostic questions first.

Do we understand how the settlement process actually works? The Claims team knows this process well. They have run it for five years. They can walk you through it from memory: Claim Filed → Documents Requested → Documents Received → Assessment Scheduled → Assessment Completed → Settlement Calculated → Settlement Approved → Payment Issued. There is no mystery about the sequence. Running a Big Picture event storming session would take a day and tell them things they already know.

Do we know who owns what? Largely, yes. The Claims context is well-bounded. A quick conversation confirms that the relevant boundaries are already understood: Claims owns everything from Claim Filed to Settlement Approved; Finance owns payment disbursement.

Do we agree on why we are building this? No. And here is the genuine ambiguity. The claims director wants to reduce settlement cycle time. The CFO wants to reduce settlement cost. The customer experience lead wants to improve claimant satisfaction scores. These are three different goals, and each one would lead to a different redesign. This is the unanswered question.

Conclusion: start with impact mapping. The team runs an impact map with the three senior stakeholders. The goal is agreed: "Reduce average settlement time from 14 days to 7 days within 12 months, without increasing settlement cost." Actors: claims analysts, claimants, external assessors. The key impact for claims analysts: submit assessment reports without manual re-entry. The key impact for claimants: receive status updates without calling in. The deliverables follow naturally from there.

After impact mapping, the team has a clear goal. Now they run a focused Process Modeling event storming session — not a Big Picture one — on the specific settlement subprocess to find where the bottlenecks actually live. The hotspots cluster around document collection and assessor scheduling. Those two subprocesses get attention; everything else stays as-is.

Finally, with the bottlenecks known and the goal agreed, the product team runs a user story map for the claimant journey: File Claim → Track Status → Receive Decision → Receive Payment. The release line for the first iteration covers status tracking and automated notifications, because those address the claimant experience impact directly.

Compare this to the Meridian product launch described in the first module of this plan. That situation was the opposite: a new product, a domain that Engineering had never worked in, four teams with entirely different vocabularies for the same customer. There, Big Picture event storming was the right start precisely because the domain was unknown. Same company, different question, different framework.

Analogy

Think of these frameworks as diagnostic tools in a medical practice. When a patient walks in, a good clinician does not order every available test — a blood panel, an X-ray, an ultrasound, an MRI — before deciding what is wrong. That approach is expensive, slow, and produces more noise than signal. Instead, the clinician starts by asking what is symptomatic, listens to the patient's description, and then chooses the diagnostic that best matches what they suspect is the underlying problem. The X-ray answers questions about structure; the blood panel answers questions about chemistry; the ultrasound answers questions about soft tissue. Each is excellent at what it is designed to reveal and useless for questions it was not designed to answer.

Disambiguation frameworks work the same way. Event storming is your X-ray: it shows you structure you cannot see otherwise — the skeleton of a business process, the gaps and breaks in the flow. Impact mapping is your patient history: it tells you why the patient came in at all, what they are trying to achieve, and whether the presenting symptom is actually the real problem. User story mapping is your treatment plan: once you know what is wrong and why it matters, it tells you what to do first and in what order. A context map is the specialist's referral: it tells you who is responsible for what part of the system and where to route the handoff.

You choose the diagnostic that matches the question you are asking. You do not use all of them every time.

Going Deeper

Stakeholder count as a selection signal

The number and type of people you need in the room is itself a useful pointer toward the right framework. Big Picture event storming requires many diverse voices — 15 to 30 people from across the business, all of whom have different pieces of the process story. That scale is a feature, not a bug: the diversity of perspectives is what makes hidden assumptions visible. Impact mapping works best with a small strategic group — typically the goal-setter, a representative from the key actor group, and someone who understands delivery constraints. User story mapping works with a focused product team. If you are about to run an event storming session and realise you can only get four people in the room, that is a signal to ask whether you actually have a domain discovery problem or whether a different framework would serve you better with the stakeholders you have.

Customisation over dogma

Every framework has an orthodox version — the "correct" sticky note colours, the "official" four-level hierarchy, the "right" facilitation sequence. These conventions exist for good reasons, and learning them first is worth the investment. But experienced practitioners adapt. They combine steps, shorten sessions for teams with partial prior knowledge, or use a user story map's horizontal axis without the full vertical hierarchy when the team is time-constrained. The sign that someone has missed the point is rigid adherence to notation when the notation stops serving the learning goal. The frameworks are instruments for making assumptions visible and shared — not rituals to be performed.

The bottom-up and top-down contrast as a navigation principle

The most useful single distinction for framework selection is directional. Event storming is bottom-up: it starts from concrete things that happened (domain events) and builds toward understanding. Impact mapping is top-down: it starts from an abstract goal and works down toward concrete deliverables. User story mapping is user-out: it starts from the actor's experience and works outward to delivery sequence. Context mapping is boundary-in: it starts from the full landscape and draws lines around ownership.

When you are disoriented about which framework to use, ask yourself: does my team need to go from the concrete to the abstract (bottom-up) or from the abstract to the concrete (top-down)? If you do not yet understand what actually happens in the business, you need bottom-up — reach for event storming. If you understand the process but cannot agree on what success looks like, you need top-down — reach for impact mapping.

Common Misconceptions

"We should always start with event storming." Event storming has a reputation as the entry point for DDD-adjacent work, and for a genuinely new domain that reputation is deserved. But many real projects are not starting from zero. The Claims team redesigning a five-year-old process does not need to discover the domain — they live it. Starting with event storming in that situation produces a timeline the room already knows and burns the team's energy on mapping rather than on the actual problem, which is goal alignment. The framework you start with should match the specific question that is currently unanswered, not the framework that worked last time.

"More workshops mean better outcomes." It is tempting, once you have learned these frameworks, to run them all. But each workshop has a cost: participant time, facilitation effort, and the credibility you spend when people sit in sessions that do not produce anything they did not already know. Use the diagnostic questions ruthlessly. If a question has already been answered — the domain is understood, the boundaries are clear, the goal is agreed — skip the corresponding framework. Add only what is missing.

"The frameworks replace each other — if we do event storming well, we do not need user story mapping." These frameworks do not compete; they answer different questions. Event storming answers "what are all the domain events and where do they flow?" User story mapping answers "in what order should we build features to deliver value to this user?" You need both in sequence for new product work, but they are not interchangeable. Knowing the full timeline of events does not tell you which slice of that timeline to build first, for which actor, in which release. That is what the user story map is for.

Check Your Understanding

1. The Meridian Claims team comes to you with a request: "We want to run an event storming session on our settlement process." Before agreeing, what is the one question you would ask them, and why?

Reveal answer

You would ask: "What question are you trying to answer that you cannot answer now?" Event storming is designed for domain discovery — for situations where the business process is poorly understood or where multiple teams have conflicting accounts of what happens. If the Claims team already understands their settlement process, event storming is the wrong tool. The right question is: "What is currently unanswered?" That question points to the right framework. In Meridian's case, the unanswered question turns out to be goal alignment — which points to impact mapping, not event storming.

2. A product director at Meridian says: "We are building a new mobile app for claimants. I know exactly what we want to build — a portal where they can track their claim status. Let's start with a user story map." Is this the right starting framework? What might be missing?

Reveal answer

User story mapping is the right tool for sequencing a well-understood user journey toward delivery — but it requires that the goal and the user's actual needs are already clear. The phrase "I know exactly what we want to build" is a warning sign. Impact mapping should come first to ask: what behavior change in the claimant will move the needle on the business goal? If the goal is reducing inbound calls to the claims centre, a status-tracking portal might be the right deliverable — but impact mapping would confirm that before the team maps twelve weeks of user stories around it. Jumping straight to a user story map risks building a polished journey for a deliverable that does not address the real impact.

3. Explain in your own words why event storming is described as "bottom-up" and impact mapping as "top-down." In which situation is each starting point more appropriate?

Reveal answer

Event storming is bottom-up because it begins with the most concrete, observable things — domain events, the specific things that happened in the business — and uses them to build upward toward shared understanding of the domain, its boundaries, and its problem areas. Impact mapping is top-down because it begins with the most abstract thing — a business goal — and works downward through actors and their behavior changes to arrive at the concrete deliverables that enable those changes. Event storming is appropriate when the domain is unfamiliar or when multiple teams have different stories about the same process. Impact mapping is appropriate when the domain is understood but the "why" behind the work is contested or unclear.

4. A colleague argues: "Context mapping should always come before impact mapping, because you need to know who owns what before you can decide what to build." Do you agree? When would you make an exception?

Reveal answer

This is not a reliable rule. Context mapping clarifies boundaries and ownership — it answers "who owns what and where the handoffs are." Impact mapping clarifies goal alignment — it answers "why are we building this and what behavior must change?" These two questions are independent. If the goal is contested, impact mapping should come first, even before the context map is drawn, because without an agreed goal you do not yet know which bounded contexts are relevant to the work. You would draw the context map after impact mapping has confirmed which actors and domains are in scope for the goal. The exception runs the other way: if the team is arguing about ownership and integration points rather than about the goal, context mapping should come first.

5. Think of one project or initiative you are currently involved in. Which of the four diagnostic questions is currently unanswered for that project? What does that tell you about where to start?

Reveal answer

This is a personal reflection question — there is no single correct answer. The exercise is to apply the diagnostic honestly: (1) Is the business process understood? (2) Are the boundaries and ownership clear? (3) Is the goal agreed? (4) Is the user journey and delivery sequence clear? Whichever question you cannot answer confidently is the gap your team currently has, and the framework that closes that gap is the one to reach for first.

Key Takeaways

• The selection principle for disambiguation frameworks is: identify the question that is currently unanswered, then choose the framework designed to answer that question.
• The four diagnostic questions are: "Do we understand the process?" (event storming), "Do we know who owns what?" (context mapping), "Do we agree on why?" (impact mapping), "Do we know the sequence?" (user story mapping).
• The typical sequence for a new domain is event storming → context mapping → impact mapping → user story mapping — but this sequence should be broken whenever the domain is already understood, the goal is already contested, or the team lacks the stakeholders required for a given format.
• Event storming is bottom-up (from domain events to understanding); impact mapping is top-down (from goal to deliverable). Knowing which direction you need to travel is the fastest route to the right starting framework.
• The ubiquitous language — the shared vocabulary agreed on by business experts and engineers — is the foundation that all four frameworks depend on, even when no formal DDD workshop has been run to establish it.

References

• How to max out DDD Big Picture Event Storming with other Workshops — Philippe Bourgau's practical guide on how and when to combine event storming with user story mapping, impact mapping, and example mapping, with concrete sequencing advice.
• From Event Storming to User Stories — A step-by-step walkthrough of the transition from an event storming output to a prioritised user story map, with clear explanations of why the two frameworks complement rather than replace each other.
• Event Storming — The Complete Guide — Comprehensive reference on the different flavors of event storming (Big Picture, Process Modeling, Design Level) and the decision criteria for choosing among them based on what you are trying to learn.
• Impact Mapping Official Site — Gojko Adzic's definitive resource on impact mapping, including worked examples and guidance on when impact mapping is the right starting point for a project.