Let’s talk about two awesome techniques for scoping solutions — Impact Mapping and User Story Mapping. We’ll look at how they can be used together, though in practice, they’re often applied independently depending on the task at hand.
Both Impact Mapping and User Story Mapping are typically presented as agile techniques. Like most agile tools, they have a distinct trait: they help you achieve something in a fast and lean way — essentially following the Pareto principle (20/80). That means focusing on quickly delivering the core result, while ignoring bells and whistles. So keep in mind that these techniques are a) simple, b) relatively shallow, and c) fast to apply. In other words, I wouldn’t recommend using them to plan a nuclear reactor, but they’re perfect for designing an MVP for a startup.
Both Impact Mapping and User Story Mapping are typically presented as agile techniques. Like most agile tools, they have a distinct trait: they help you achieve something in a fast and lean way — essentially following the Pareto principle (20/80). That means focusing on quickly delivering the core result, while ignoring bells and whistles. So keep in mind that these techniques are a) simple, b) relatively shallow, and c) fast to apply. In other words, I wouldn’t recommend using them to plan a nuclear reactor, but they’re perfect for designing an MVP for a startup.
Let’s start with Impact Mapping — a technique for visually planning how to achieve a specific goal. In a business analysis context, it helps you work with stakeholders to explore how a solution can address defined business goals.
We’ll walk through the technique using a project example from Karl Wiegers’ book Software Requirements (3rd Edition), since many people are familiar with the scenario, along with its V&S and SRS content.
We’ll walk through the technique using a project example from Karl Wiegers’ book Software Requirements (3rd Edition), since many people are familiar with the scenario, along with its V&S and SRS content.
Project context (only the relevant part):
Most Process Impact employees currently spend around 65 minutes a day choosing, paying for, and eating lunch in the cafeteria. About 20 minutes of that is walking to and from the cafeteria, choosing food, and paying by cash or card. In total, employees are away from their desks for about 90 minutes. Some try calling ahead to place their orders, but often end up with the wrong meal because certain dishes run out.
The book doesn’t make it very clear who the actual beneficiary of the solution is — for some reason, we seem to be solving problems for both the cafeteria and the company whose employees use it. So let’s simplify the original three business goals from the book down to one that’s most relevant to Process Impact:
BO-3: Increase the average productive working time of each employee by 15 minutes per day, within 6 months of the system’s initial release.
Let’s not get into how this specific metric was decided — after all, Impact Mapping isn’t about defining business goals. You go into it already having your goals — whether they’re SMART or more abstract doesn’t matter, as long as they’ve been agreed with stakeholders. And just as importantly, this isn’t a method for selecting the final solution. Somehow (by magic, perhaps), we’ve arrived at the following idea:
Cafeteria Ordering System — a web application (originally also mentioned as a mobile app, but let’s stick with web for simplicity) that allows employees to place lunch orders, pay for them, and initiate delivery to a specified point within the Process Impact office.
That’s roughly the starting point for our Impact Map. An Impact Map is a type of mind map, built using a specific template. Like most agile techniques, it’s not something you sit down and create in isolation. It works best as a collaborative process with relevant stakeholders — the client, key business figures, user reps, you, your UXer, lead dev, and so on. We’ll briefly touch on what that process might look like later.
The map has four levels. Each should be worked through in sequence — don’t move on until the current level is solid.
Most Process Impact employees currently spend around 65 minutes a day choosing, paying for, and eating lunch in the cafeteria. About 20 minutes of that is walking to and from the cafeteria, choosing food, and paying by cash or card. In total, employees are away from their desks for about 90 minutes. Some try calling ahead to place their orders, but often end up with the wrong meal because certain dishes run out.
The book doesn’t make it very clear who the actual beneficiary of the solution is — for some reason, we seem to be solving problems for both the cafeteria and the company whose employees use it. So let’s simplify the original three business goals from the book down to one that’s most relevant to Process Impact:
BO-3: Increase the average productive working time of each employee by 15 minutes per day, within 6 months of the system’s initial release.
Let’s not get into how this specific metric was decided — after all, Impact Mapping isn’t about defining business goals. You go into it already having your goals — whether they’re SMART or more abstract doesn’t matter, as long as they’ve been agreed with stakeholders. And just as importantly, this isn’t a method for selecting the final solution. Somehow (by magic, perhaps), we’ve arrived at the following idea:
Cafeteria Ordering System — a web application (originally also mentioned as a mobile app, but let’s stick with web for simplicity) that allows employees to place lunch orders, pay for them, and initiate delivery to a specified point within the Process Impact office.
That’s roughly the starting point for our Impact Map. An Impact Map is a type of mind map, built using a specific template. Like most agile techniques, it’s not something you sit down and create in isolation. It works best as a collaborative process with relevant stakeholders — the client, key business figures, user reps, you, your UXer, lead dev, and so on. We’ll briefly touch on what that process might look like later.
The map has four levels. Each should be worked through in sequence — don’t move on until the current level is solid.
Level 1: Goals
These are the business goals you're trying to achieve.
These are the business goals you're trying to achieve.
Level 2: Actors
Actors are people or groups who can help or hinder the achievement of the goal.
Actors are people or groups who can help or hinder the achievement of the goal.
Some guiding questions:
- Who directly affects whether the goal is met?
- Who indirectly affects the goal and is involved in relevant processes?
- Who might, under some conditions, help or block achievement of the goal?
Given our context, here are the key actors:
- Employees (they’re the ones we’re trying to “upgrade”)
- Cafeteria management (they’ll be delivering food in the new setup)
- Process Impact leadership (optional — they're funding this, but we’re already focusing on their goal)
- Cafeteria delivery staff
- Cafeteria cooks
Actors we’re skipping for simplicity but could explore:
- Hosting
- Government regulators (if there are compliance requirements)
- Finance/accounting team (handling food expense records)
- Payment provider
At this point, you’ve probably noticed this is a light version of stakeholder identification. It’s not a complete overlap with stakeholder analysis, so there might be gaps — but remember, agile techniques prioritize speed and simplicity over completeness.
Level 3: Impacts
This is about how we want the actors to change their behavior in order to help meet the goal. Think:
Let’s sketch out some ideas, keeping in mind that our goal is to increase the effective working time of employees by automating food ordering and removing the need to walk to the cafeteria.
Employees:
Cafeteria management:
Process Impact leadership:
Delivery staff:
Cooks:
It’s worth noting: we might have a few gaps here, but that’s expected — this example was drafted solo. If we had the client, a cafeteria rep, a hungry employee, and our internal team (like a lead UX designer and a tech lead) all in the same room, the results would be a lot more complete and reliable.
This is about how we want the actors to change their behavior in order to help meet the goal. Think:
- What should the actor start doing?
- What should they stop doing?
- What should they do differently (more, less, faster, slower)?
Let’s sketch out some ideas, keeping in mind that our goal is to increase the effective working time of employees by automating food ordering and removing the need to walk to the cafeteria.
Employees:
- Stop physically walking to the cafeteria
- Start placing orders via the web app from the office
Cafeteria management:
- Set up new roles and responsibilities (e.g., delivery staff, support)
- Organize efficient order processing workflows
Process Impact leadership:
- Nothing specific — just fund the whole thing (already happening)
Delivery staff:
- Deliver food quickly to the office
Cooks:
- Prepare meals promptly based on orders
It’s worth noting: we might have a few gaps here, but that’s expected — this example was drafted solo. If we had the client, a cafeteria rep, a hungry employee, and our internal team (like a lead UX designer and a tech lead) all in the same room, the results would be a lot more complete and reliable.
Level 4: Deliverables
This final level of the Impact Map outlines solutions in response to each impact — in other words, what we can or must deliver to ensure the desired behavioral changes happen. These solutions will mostly fall within the scope of the target IT product (i.e. its functional capabilities), but not exclusively. We might also identify important non-functional requirements or supporting elements outside the product itself — things that need to happen around the product for change to truly occur. In terms of requirements, these would be classified as transitional requirements or external dependencies; in simpler terms: a product alone doesn’t drive change.
This final level of the Impact Map outlines solutions in response to each impact — in other words, what we can or must deliver to ensure the desired behavioral changes happen. These solutions will mostly fall within the scope of the target IT product (i.e. its functional capabilities), but not exclusively. We might also identify important non-functional requirements or supporting elements outside the product itself — things that need to happen around the product for change to truly occur. In terms of requirements, these would be classified as transitional requirements or external dependencies; in simpler terms: a product alone doesn’t drive change.
Employees
Stop physically walking to the cafeteria
We’ll cover this in the next point.
Start placing orders via the web app from the office
Cafeteria management
Set up new roles and responsibilities, if delivery services aren't already in place (e.g. new responsibilities for cooks, delivery staff, support team)
Organize efficient order processing workflows
Delivery Staff
Deliver food quickly to the office
Cooks
Prepare meals promptly based on orders
Additional deliverables for previously identified actors
These aren’t tied to a specific impact, we skipped this part.
Stop physically walking to the cafeteria
We’ll cover this in the next point.
Start placing orders via the web app from the office
- Login with a personal account (so orders are linked to individual users) + logout.
- We may also add password recovery, changing password, session timeout, etc.
- View menu.
- Someone from the cafeteria will need to upload the menu to the system — so we should also include menu management: add/edit/delete menu items.
- Place/edit/cancel orders.
- Pay for orders (e.g. by card).
Cafeteria management
Set up new roles and responsibilities, if delivery services aren't already in place (e.g. new responsibilities for cooks, delivery staff, support team)
- We don’t need to implement this ourselves — but we do need to ensure the cafeteria sets it up and that it works. Most likely, the client (the one requesting the solution) will be responsible for this, but it’s still worth covering this point during discussions with all key stakeholders.
Organize efficient order processing workflows
- Same as above. We might help by training cafeteria staff on how to use the system.
Delivery Staff
Deliver food quickly to the office
- If no delivery process exists yet at the cafeteria, one will need to be introduced. Again, probably outside our core responsibility — but worth flagging and discussing, since we’re all working toward the same goal.
Cooks
Prepare meals promptly based on orders
- Ability to view placed orders.
Additional deliverables for previously identified actors
These aren’t tied to a specific impact, we skipped this part.
- Hosting setup (External hosting).
- Analysis and compliance with national regulations regarding web apps and food delivery services; Data privacy policy; Registering the service for online commerce; Any other relevant regulations the cafeteria must follow to legally offer delivery (Government regulators):
- Export of individual order expenses (Finance/accounting team).
- Integration with a payment provider (Payment provider).
So, what have we done? We’ve essentially generated a solution scope — along with supporting context — by progressively working on how to achieve the business goal. Everything we’ve identified here are candidates for epics, user stories, features, non-functional requirements, external dependencies, project tasks, etc. Of course, from a requirements perspective, this all still needs refining:
- Some items will go into the scope of the IT solution (functional and non-functional bits).
- Others are complementary actions that will need to be taken outside the system (by the client, third parties, or other stakeholders).
How to facilitate an Impact Map workshop:
There are many ways to run this process — whatever facilitation tools and collaboration formats you like. But here’s a typical example:
There are many ways to run this process — whatever facilitation tools and collaboration formats you like. But here’s a typical example:
- Input: You already have the business goal defined and a general understanding of what the target solution should look like (e.g. from a prior session using Lean Canvas or something similar).
- Organize a workshop with relevant and available stakeholders — either in person or remote. For example: the client, a cafeteria representative, a hungry employee, you, and your internal team (UX specialist, tech lead, project manager, QA lead, etc.).
- Before and during the session, as with any workshop, make sure everyone understands the goal, expected outcomes, and is ready to contribute actively. Communicate this in the agenda and reiterate it at the beginning.
- Introduce key terms: explain what an Impact Map is, how you’ll move through the levels, and what’s expected from each participant:
- You’ll work through one level at a time.
- For each level, explain what it means and suggest prompts to help generate ideas.
- Participants add sticky notes (or mind map branches in Miro) during a 5-minute brainstorming round.
- Then, you review each one together: the author explains, others comment, you clean up duplicates and prioritize.
How does the User Story Map fit in? The User Story Map comes into play once the Impact Map is ready. It takes the part of the plan related to the IT solution and helps shape a well-structured, prioritized product backlog. In other words, it transforms the rough ideas into a clear breakdown of epics and user stories. But more on that in the next article.
Visual example of the map discussed in this article:
