March 25, 2020
March 25, 2020
March 25, 2020
There’s this famous story about the wolves of Yellowstone you might have heard. Throughout the early days of Yellowstone Park, wolves were considered a nuisance, as they were thought to be a threat to local livestock, and as a result, weren't legally protected from being hunted. In 1907 political pressure from local ranchers and agricultural interests led to the USFS working with the United States Department of Agriculture Division of Biological Survey to develop methods for controlling wolves and coyotes.
Between 1914 and 1926, at least 136 wolves were killed in the park. By 1926, grey wolves were considered to be locally extinct. And after the wolves were gone, the elk population began to rise and overgraze on aspen, cottonwood, and berry producing shrubs. The loss of these plants led to a decline in beaver populations, too, as they depend on these plants to survive in the wintertime. Scientists began to worry about the negative effect as early as the 1930s.
Throughout the 1960s and 1970s (but as far back as the 1940s) wildlife biologists began to call for reintroducing wolves to the park, and finally, in March of 1995, fourteen wolves were reintroduced into Yellowstone. The resulting change has been magnificent. In the years that followed, not only have the elk populations decreased, but the coyote population has too. Coyotes hunt foxes, so this decrease in the coyote population led to an increase in the fox population, which in turn increased the survival rate of other coyote prey, such as hares, rodents, and birds. The changes in these populations then altered the rate at which nuts, seeds, and insects were eaten. The changing grazing patterns of elks caused vegetation to recover. The number of beavers increased and created dams, which helped protect the streams and ponds against bank erosion and provided new habitats for moose and and fish. The songbirds came back.
Ecologists call this a “trophic cascade”. It’s a phenomenon where the act of adding or removing a top predator from the food chain causes a dramatic change in the food chain of the ecosystem as a whole. At Yellowstone, the reintroduction of a top predator caused the entire watershed to become not just more ecologically diverse, but more stable, too.
The ecosystem that drives Yellowstone is a complex set of cascading actions and their consequences. This cascading effect exists far outside of ecology though. A change in just one aspect of any complex system can have an outsized effect on the whole. And the more we understand this chain of cause and effect, the better equipped we are to make decisions about how to change it for the better.
About a year ago I wrote an overview of system dynamics and its application on design systems, largely based on the work of Donella Meadows. Today I’d like to build on that work by discussing how you can model systems to help you understand where you need to focus to have the most impact. Much of the concepts and ideas I’ll outline in this system + design workshop format are inspired by Rob Ricigliano.
There’s this famous story about the wolves of Yellowstone you might have heard. Throughout the early days of Yellowstone Park, wolves were considered a nuisance, as they were thought to be a threat to local livestock, and as a result, weren't legally protected from being hunted. In 1907 political pressure from local ranchers and agricultural interests led to the USFS working with the United States Department of Agriculture Division of Biological Survey to develop methods for controlling wolves and coyotes.
Between 1914 and 1926, at least 136 wolves were killed in the park. By 1926, grey wolves were considered to be locally extinct. And after the wolves were gone, the elk population began to rise and overgraze on aspen, cottonwood, and berry producing shrubs. The loss of these plants led to a decline in beaver populations, too, as they depend on these plants to survive in the wintertime. Scientists began to worry about the negative effect as early as the 1930s.
Throughout the 1960s and 1970s (but as far back as the 1940s) wildlife biologists began to call for reintroducing wolves to the park, and finally, in March of 1995, fourteen wolves were reintroduced into Yellowstone. The resulting change has been magnificent. In the years that followed, not only have the elk populations decreased, but the coyote population has too. Coyotes hunt foxes, so this decrease in the coyote population led to an increase in the fox population, which in turn increased the survival rate of other coyote prey, such as hares, rodents, and birds. The changes in these populations then altered the rate at which nuts, seeds, and insects were eaten. The changing grazing patterns of elks caused vegetation to recover. The number of beavers increased and created dams, which helped protect the streams and ponds against bank erosion and provided new habitats for moose and and fish. The songbirds came back.
Ecologists call this a “trophic cascade”. It’s a phenomenon where the act of adding or removing a top predator from the food chain causes a dramatic change in the food chain of the ecosystem as a whole. At Yellowstone, the reintroduction of a top predator caused the entire watershed to become not just more ecologically diverse, but more stable, too.
The ecosystem that drives Yellowstone is a complex set of cascading actions and their consequences. This cascading effect exists far outside of ecology though. A change in just one aspect of any complex system can have an outsized effect on the whole. And the more we understand this chain of cause and effect, the better equipped we are to make decisions about how to change it for the better.
About a year ago I wrote an overview of system dynamics and its application on design systems, largely based on the work of Donella Meadows. Today I’d like to build on that work by discussing how you can model systems to help you understand where you need to focus to have the most impact. Much of the concepts and ideas I’ll outline in this system + design workshop format are inspired by Rob Ricigliano.
There’s this famous story about the wolves of Yellowstone you might have heard. Throughout the early days of Yellowstone Park, wolves were considered a nuisance, as they were thought to be a threat to local livestock, and as a result, weren't legally protected from being hunted. In 1907 political pressure from local ranchers and agricultural interests led to the USFS working with the United States Department of Agriculture Division of Biological Survey to develop methods for controlling wolves and coyotes.
Between 1914 and 1926, at least 136 wolves were killed in the park. By 1926, grey wolves were considered to be locally extinct. And after the wolves were gone, the elk population began to rise and overgraze on aspen, cottonwood, and berry producing shrubs. The loss of these plants led to a decline in beaver populations, too, as they depend on these plants to survive in the wintertime. Scientists began to worry about the negative effect as early as the 1930s.
Throughout the 1960s and 1970s (but as far back as the 1940s) wildlife biologists began to call for reintroducing wolves to the park, and finally, in March of 1995, fourteen wolves were reintroduced into Yellowstone. The resulting change has been magnificent. In the years that followed, not only have the elk populations decreased, but the coyote population has too. Coyotes hunt foxes, so this decrease in the coyote population led to an increase in the fox population, which in turn increased the survival rate of other coyote prey, such as hares, rodents, and birds. The changes in these populations then altered the rate at which nuts, seeds, and insects were eaten. The changing grazing patterns of elks caused vegetation to recover. The number of beavers increased and created dams, which helped protect the streams and ponds against bank erosion and provided new habitats for moose and and fish. The songbirds came back.
Ecologists call this a “trophic cascade”. It’s a phenomenon where the act of adding or removing a top predator from the food chain causes a dramatic change in the food chain of the ecosystem as a whole. At Yellowstone, the reintroduction of a top predator caused the entire watershed to become not just more ecologically diverse, but more stable, too.
The ecosystem that drives Yellowstone is a complex set of cascading actions and their consequences. This cascading effect exists far outside of ecology though. A change in just one aspect of any complex system can have an outsized effect on the whole. And the more we understand this chain of cause and effect, the better equipped we are to make decisions about how to change it for the better.
About a year ago I wrote an overview of system dynamics and its application on design systems, largely based on the work of Donella Meadows. Today I’d like to build on that work by discussing how you can model systems to help you understand where you need to focus to have the most impact. Much of the concepts and ideas I’ll outline in this system + design workshop format are inspired by Rob Ricigliano.
Who is this for?
Who is this for?
Who is this for?
Systems thinking is a hot topic in product design right now, but let’s be very clear: not every problem can be solved with a system frame of mind. Problems that are well defined, well scoped, and focus on short-term progress probably won’t benefit from the kind of concentrated analysis that systems practices require to be executed successfully. Those types of problems are excellent for classic design sprints. I won’t go into detail about that here, but there’s a wealth of knowledge out there about design sprints. I recommend GV’s book Sprint.
Systems practice is better suited for folks looking to make significant change on a broad scale. This is because systems practice aims to make sustainable change through identifying the underlying social, behavioral, and environmental factors driving them.
By their very nature, systems are wildly complex things, and solving issues in systems means bringing experts under the same roof. Often these folks don’t get enough opportunities to solve problems collaboratively. Systems mapping will help bring these subject matter experts together so we can get a broad overview of the system and look for integrated ways to improve the health of the system and make more progress than we otherwise would have if we had acted in isolation.
Systems thinking is a hot topic in product design right now, but let’s be very clear: not every problem can be solved with a system frame of mind. Problems that are well defined, well scoped, and focus on short-term progress probably won’t benefit from the kind of concentrated analysis that systems practices require to be executed successfully. Those types of problems are excellent for classic design sprints. I won’t go into detail about that here, but there’s a wealth of knowledge out there about design sprints. I recommend GV’s book Sprint.
Systems practice is better suited for folks looking to make significant change on a broad scale. This is because systems practice aims to make sustainable change through identifying the underlying social, behavioral, and environmental factors driving them.
By their very nature, systems are wildly complex things, and solving issues in systems means bringing experts under the same roof. Often these folks don’t get enough opportunities to solve problems collaboratively. Systems mapping will help bring these subject matter experts together so we can get a broad overview of the system and look for integrated ways to improve the health of the system and make more progress than we otherwise would have if we had acted in isolation.
Systems thinking is a hot topic in product design right now, but let’s be very clear: not every problem can be solved with a system frame of mind. Problems that are well defined, well scoped, and focus on short-term progress probably won’t benefit from the kind of concentrated analysis that systems practices require to be executed successfully. Those types of problems are excellent for classic design sprints. I won’t go into detail about that here, but there’s a wealth of knowledge out there about design sprints. I recommend GV’s book Sprint.
Systems practice is better suited for folks looking to make significant change on a broad scale. This is because systems practice aims to make sustainable change through identifying the underlying social, behavioral, and environmental factors driving them.
By their very nature, systems are wildly complex things, and solving issues in systems means bringing experts under the same roof. Often these folks don’t get enough opportunities to solve problems collaboratively. Systems mapping will help bring these subject matter experts together so we can get a broad overview of the system and look for integrated ways to improve the health of the system and make more progress than we otherwise would have if we had acted in isolation.
Who to involve
Who to involve
Who to involve
If you’re going to run a workshop to map a system, you’ll need to build up a team in a few layers:
The Core Team — These folks are a small group of people to organize and drive the workshop itself. They need the most understanding of systems practice to help string together the group's thoughts into a coherent system. If you’re reading this, that’s probably you.
System Stakeholders — These are subject matter experts from the community that can help inform and educate the group on the inner workings of the system.
Participants — These are folks involved in key activities throughout the workshop, but aren’t responsible for any of the deliverables. They’re great to include when you need to get more detailed on a specific part of a system. Think of these folks as people who can help you collect the most robust data set possible to map your system.
If you’re going to run a workshop to map a system, you’ll need to build up a team in a few layers:
The Core Team — These folks are a small group of people to organize and drive the workshop itself. They need the most understanding of systems practice to help string together the group's thoughts into a coherent system. If you’re reading this, that’s probably you.
System Stakeholders — These are subject matter experts from the community that can help inform and educate the group on the inner workings of the system.
Participants — These are folks involved in key activities throughout the workshop, but aren’t responsible for any of the deliverables. They’re great to include when you need to get more detailed on a specific part of a system. Think of these folks as people who can help you collect the most robust data set possible to map your system.
If you’re going to run a workshop to map a system, you’ll need to build up a team in a few layers:
The Core Team — These folks are a small group of people to organize and drive the workshop itself. They need the most understanding of systems practice to help string together the group's thoughts into a coherent system. If you’re reading this, that’s probably you.
System Stakeholders — These are subject matter experts from the community that can help inform and educate the group on the inner workings of the system.
Participants — These are folks involved in key activities throughout the workshop, but aren’t responsible for any of the deliverables. They’re great to include when you need to get more detailed on a specific part of a system. Think of these folks as people who can help you collect the most robust data set possible to map your system.
Work Backwards from a North Star
Work Backwards from a North Star
Work Backwards from a North Star
Before you start diving into mapping your system and identifying areas of opportunity, it’s a good idea to think upfront about the outcomes you really care about. You likely won’t be able to solve all your problems at once, but knowing your ultimate goals can direct your short term focus to be in service of that larger term goal. Think about this with your Core Team and come up with a succinct statement to represent what you’re actually driving toward. This is often called a North Star vision.
Your North Star should have a few qualities:
It should be inspiring. Often, this north star is the root of your story. You’ll use it to tell others about the work you’re doing and why it’s important. It will seem far off, and others may think it’s unachievable, but it should also be a future everyone’s eager to get to. In my opinion, this is the most important part of any long term strategy.
It should be human-centered. Now is not the time to worry about metrics. These aspirational north stars are more about identifying what a healthy, sustainable system looks like. Metrics can come later as a way to measure your progress along the way.
It should be long term. These types of visions can take years, if not decades to achieve. This positions them as a guiding light, but also allows them to be malleable over time as conditions change.
It should be aware of its surroundings. When you’re developing this North Star statement with your team, think about the larger challenges you expect your organization to face over the coming years, as well as other goals you may be trying to achieve. Your industry may be evolving dramatically over the next few years, and there may already be signs of that change happening today that can inform this long term vision.
Along the way, you may develop other milestones that represent significant progress toward this ultimate outcome. Those milestones should still take years to get to - but should give you a better picture about how to reach that end state. Sometimes, these nearer term milestones can be more helpful to focus on for systems mapping workshops because they’re easier to attach the current reality of the system to. If you focus too much on a moonshot, people may not be able to connect it to the problems you’re already facing today.
Before you start diving into mapping your system and identifying areas of opportunity, it’s a good idea to think upfront about the outcomes you really care about. You likely won’t be able to solve all your problems at once, but knowing your ultimate goals can direct your short term focus to be in service of that larger term goal. Think about this with your Core Team and come up with a succinct statement to represent what you’re actually driving toward. This is often called a North Star vision.
Your North Star should have a few qualities:
It should be inspiring. Often, this north star is the root of your story. You’ll use it to tell others about the work you’re doing and why it’s important. It will seem far off, and others may think it’s unachievable, but it should also be a future everyone’s eager to get to. In my opinion, this is the most important part of any long term strategy.
It should be human-centered. Now is not the time to worry about metrics. These aspirational north stars are more about identifying what a healthy, sustainable system looks like. Metrics can come later as a way to measure your progress along the way.
It should be long term. These types of visions can take years, if not decades to achieve. This positions them as a guiding light, but also allows them to be malleable over time as conditions change.
It should be aware of its surroundings. When you’re developing this North Star statement with your team, think about the larger challenges you expect your organization to face over the coming years, as well as other goals you may be trying to achieve. Your industry may be evolving dramatically over the next few years, and there may already be signs of that change happening today that can inform this long term vision.
Along the way, you may develop other milestones that represent significant progress toward this ultimate outcome. Those milestones should still take years to get to - but should give you a better picture about how to reach that end state. Sometimes, these nearer term milestones can be more helpful to focus on for systems mapping workshops because they’re easier to attach the current reality of the system to. If you focus too much on a moonshot, people may not be able to connect it to the problems you’re already facing today.
Before you start diving into mapping your system and identifying areas of opportunity, it’s a good idea to think upfront about the outcomes you really care about. You likely won’t be able to solve all your problems at once, but knowing your ultimate goals can direct your short term focus to be in service of that larger term goal. Think about this with your Core Team and come up with a succinct statement to represent what you’re actually driving toward. This is often called a North Star vision.
Your North Star should have a few qualities:
It should be inspiring. Often, this north star is the root of your story. You’ll use it to tell others about the work you’re doing and why it’s important. It will seem far off, and others may think it’s unachievable, but it should also be a future everyone’s eager to get to. In my opinion, this is the most important part of any long term strategy.
It should be human-centered. Now is not the time to worry about metrics. These aspirational north stars are more about identifying what a healthy, sustainable system looks like. Metrics can come later as a way to measure your progress along the way.
It should be long term. These types of visions can take years, if not decades to achieve. This positions them as a guiding light, but also allows them to be malleable over time as conditions change.
It should be aware of its surroundings. When you’re developing this North Star statement with your team, think about the larger challenges you expect your organization to face over the coming years, as well as other goals you may be trying to achieve. Your industry may be evolving dramatically over the next few years, and there may already be signs of that change happening today that can inform this long term vision.
Along the way, you may develop other milestones that represent significant progress toward this ultimate outcome. Those milestones should still take years to get to - but should give you a better picture about how to reach that end state. Sometimes, these nearer term milestones can be more helpful to focus on for systems mapping workshops because they’re easier to attach the current reality of the system to. If you focus too much on a moonshot, people may not be able to connect it to the problems you’re already facing today.
Don’t Boil the Ocean
Don’t Boil the Ocean
Don’t Boil the Ocean
Often, when you start mapping a system, you’ll identify a lot of different areas you could potentially focus on improving. But it might not be immediately clear which one is most important to focus on first. It can feel overwhelming or discouraging, but it’s important to not boil the ocean. Without a focal point, workshops can go off the rails pretty quickly. It’s important to establish a single clear and specific question that can serve as the theme for the workshop before it starts.
In design sprints, it’s common to spend most of the time focusing on coming up with solutions to a problem. In a system mapping workshop, we want to avoid specific solutions and instead spend the majority of the time seeking to understand how the system works. Focusing too prematurely on solutions causes us to fall back on the knowledge that’s most readily available, rather than looking for the areas where we have the greatest leverage. How Might We and Jobs To Be Done exercises put your systems mapping workshop at risk of going off the rails.
As you’re developing the theme for your workshop, instead of asking “How?”, which is about developing solutions, shift the conversation toward asking “What?” — more specifically “What accounts for…?” which sets up the workshop to be centered around uncovering factors and relationships.
Example Theme
“What factors account for the current rates of CO2 emissions in the United States?”
Often, when you start mapping a system, you’ll identify a lot of different areas you could potentially focus on improving. But it might not be immediately clear which one is most important to focus on first. It can feel overwhelming or discouraging, but it’s important to not boil the ocean. Without a focal point, workshops can go off the rails pretty quickly. It’s important to establish a single clear and specific question that can serve as the theme for the workshop before it starts.
In design sprints, it’s common to spend most of the time focusing on coming up with solutions to a problem. In a system mapping workshop, we want to avoid specific solutions and instead spend the majority of the time seeking to understand how the system works. Focusing too prematurely on solutions causes us to fall back on the knowledge that’s most readily available, rather than looking for the areas where we have the greatest leverage. How Might We and Jobs To Be Done exercises put your systems mapping workshop at risk of going off the rails.
As you’re developing the theme for your workshop, instead of asking “How?”, which is about developing solutions, shift the conversation toward asking “What?” — more specifically “What accounts for…?” which sets up the workshop to be centered around uncovering factors and relationships.
Example Theme
“What factors account for the current rates of CO2 emissions in the United States?”
Often, when you start mapping a system, you’ll identify a lot of different areas you could potentially focus on improving. But it might not be immediately clear which one is most important to focus on first. It can feel overwhelming or discouraging, but it’s important to not boil the ocean. Without a focal point, workshops can go off the rails pretty quickly. It’s important to establish a single clear and specific question that can serve as the theme for the workshop before it starts.
In design sprints, it’s common to spend most of the time focusing on coming up with solutions to a problem. In a system mapping workshop, we want to avoid specific solutions and instead spend the majority of the time seeking to understand how the system works. Focusing too prematurely on solutions causes us to fall back on the knowledge that’s most readily available, rather than looking for the areas where we have the greatest leverage. How Might We and Jobs To Be Done exercises put your systems mapping workshop at risk of going off the rails.
As you’re developing the theme for your workshop, instead of asking “How?”, which is about developing solutions, shift the conversation toward asking “What?” — more specifically “What accounts for…?” which sets up the workshop to be centered around uncovering factors and relationships.
Example Theme
“What factors account for the current rates of CO2 emissions in the United States?”
Step 1 — Lightning Talks
Step 1 — Lightning Talks
Step 1 — Lightning Talks
Before you really dive into the workshop, you may start with a series of lightning talks from key stakeholders. This is where I’d recommend starting if you have a diverse pool of specialists who may be less familiar with the overall subject matter. These lightning talks are usually 10-20 minute talks that give a high level overview of a particular problem space. Remember:
These are purely informational and aren’t intended to present any solutions at all — they’re just there to get everyone in the room up to the same basic level of knowledge so conversations can happen more easily.
If you decide to do lightning talks, give presenters ample time to prepare (at least a week. Opt for more if you can).
Give folks coffee and bathroom breaks every ~45 minutes so everyone stays focused throughout all the talks.
Before you really dive into the workshop, you may start with a series of lightning talks from key stakeholders. This is where I’d recommend starting if you have a diverse pool of specialists who may be less familiar with the overall subject matter. These lightning talks are usually 10-20 minute talks that give a high level overview of a particular problem space. Remember:
These are purely informational and aren’t intended to present any solutions at all — they’re just there to get everyone in the room up to the same basic level of knowledge so conversations can happen more easily.
If you decide to do lightning talks, give presenters ample time to prepare (at least a week. Opt for more if you can).
Give folks coffee and bathroom breaks every ~45 minutes so everyone stays focused throughout all the talks.
Before you really dive into the workshop, you may start with a series of lightning talks from key stakeholders. This is where I’d recommend starting if you have a diverse pool of specialists who may be less familiar with the overall subject matter. These lightning talks are usually 10-20 minute talks that give a high level overview of a particular problem space. Remember:
These are purely informational and aren’t intended to present any solutions at all — they’re just there to get everyone in the room up to the same basic level of knowledge so conversations can happen more easily.
If you decide to do lightning talks, give presenters ample time to prepare (at least a week. Opt for more if you can).
Give folks coffee and bathroom breaks every ~45 minutes so everyone stays focused throughout all the talks.
Step 2: Define the Factors
Step 2: Define the Factors
Step 2: Define the Factors
The first step in mapping a system is to understand all the factors that impact the system as it stands today. You’ll want all the stakeholders and participants present for this exercise. This exercise helps everyone get their thoughts out to the rest of the group early on, and it lets people focus on the areas they already have knowledge of without asking anyone to come up with solutions yet. You’ll use affinity mapping to find commonality among these factors. This type of exercise should feel really familiar to anyone who is used to running post it exercises as a part of design sprints. To run this exercise:
The first step in mapping a system is to understand all the factors that impact the system as it stands today. You’ll want all the stakeholders and participants present for this exercise. This exercise helps everyone get their thoughts out to the rest of the group early on, and it lets people focus on the areas they already have knowledge of without asking anyone to come up with solutions yet. You’ll use affinity mapping to find commonality among these factors. This type of exercise should feel really familiar to anyone who is used to running post it exercises as a part of design sprints. To run this exercise:
The first step in mapping a system is to understand all the factors that impact the system as it stands today. You’ll want all the stakeholders and participants present for this exercise. This exercise helps everyone get their thoughts out to the rest of the group early on, and it lets people focus on the areas they already have knowledge of without asking anyone to come up with solutions yet. You’ll use affinity mapping to find commonality among these factors. This type of exercise should feel really familiar to anyone who is used to running post it exercises as a part of design sprints. To run this exercise:
Take 10 minutes and have everyone write down all the factors they can think of that impact the system on sticky notes.
Use two colors of sticky notes - one for factors that help the system and another color for factors that hurt the system.
These help/hurt factors should map back to your original defining statement and focus on factors that can push the system into a healthy state or an unhealthy one.
After the 10 minutes is up, go around the room and have everyone share their factors. Put each sticky up on the board in two groups.
The facilitators should help group similar ideas or duplicates together as folks are sharing.
Take 10 minutes and have everyone write down all the factors they can think of that impact the system on sticky notes.
Use two colors of sticky notes - one for factors that help the system and another color for factors that hurt the system.
These help/hurt factors should map back to your original defining statement and focus on factors that can push the system into a healthy state or an unhealthy one.
After the 10 minutes is up, go around the room and have everyone share their factors. Put each sticky up on the board in two groups.
The facilitators should help group similar ideas or duplicates together as folks are sharing.
Take 10 minutes and have everyone write down all the factors they can think of that impact the system on sticky notes.
Use two colors of sticky notes - one for factors that help the system and another color for factors that hurt the system.
These help/hurt factors should map back to your original defining statement and focus on factors that can push the system into a healthy state or an unhealthy one.
After the 10 minutes is up, go around the room and have everyone share their factors. Put each sticky up on the board in two groups.
The facilitators should help group similar ideas or duplicates together as folks are sharing.
Step 2: Define the Factors
Step 2: Define the Factors
Step 2: Define the Factors
The first step in mapping a system is to understand all the factors that impact the system as it stands today. You’ll want all the stakeholders and participants present for this exercise. This exercise helps everyone get their thoughts out to the rest of the group early on, and it lets people focus on the areas they already have knowledge of without asking anyone to come up with solutions yet. You’ll use affinity mapping to find commonality among these factors. This type of exercise should feel really familiar to anyone who is used to running post it exercises as a part of design sprints. To run this exercise:
The first step in mapping a system is to understand all the factors that impact the system as it stands today. You’ll want all the stakeholders and participants present for this exercise. This exercise helps everyone get their thoughts out to the rest of the group early on, and it lets people focus on the areas they already have knowledge of without asking anyone to come up with solutions yet. You’ll use affinity mapping to find commonality among these factors. This type of exercise should feel really familiar to anyone who is used to running post it exercises as a part of design sprints. To run this exercise:
The first step in mapping a system is to understand all the factors that impact the system as it stands today. You’ll want all the stakeholders and participants present for this exercise. This exercise helps everyone get their thoughts out to the rest of the group early on, and it lets people focus on the areas they already have knowledge of without asking anyone to come up with solutions yet. You’ll use affinity mapping to find commonality among these factors. This type of exercise should feel really familiar to anyone who is used to running post it exercises as a part of design sprints. To run this exercise:
Health habits
Unhealthy habits
Take 10 minutes and have everyone write down all the factors they can think of that impact the system on sticky notes.
Use two colors of sticky notes - one for factors that help the system and another color for factors that hurt the system.
These help/hurt factors should map back to your original defining statement and focus on factors that can push the system into a healthy state or an unhealthy one.
After the 10 minutes is up, go around the room and have everyone share their factors. Put each sticky up on the board in two groups.
The facilitators should help group similar ideas or duplicates together as folks are sharing.
Take 10 minutes and have everyone write down all the factors they can think of that impact the system on sticky notes.
Use two colors of sticky notes - one for factors that help the system and another color for factors that hurt the system.
These help/hurt factors should map back to your original defining statement and focus on factors that can push the system into a healthy state or an unhealthy one.
After the 10 minutes is up, go around the room and have everyone share their factors. Put each sticky up on the board in two groups.
The facilitators should help group similar ideas or duplicates together as folks are sharing.
Take 10 minutes and have everyone write down all the factors they can think of that impact the system on sticky notes.
Use two colors of sticky notes - one for factors that help the system and another color for factors that hurt the system.
These help/hurt factors should map back to your original defining statement and focus on factors that can push the system into a healthy state or an unhealthy one.
After the 10 minutes is up, go around the room and have everyone share their factors. Put each sticky up on the board in two groups.
The facilitators should help group similar ideas or duplicates together as folks are sharing.
Step 3: Look for Cause and Effect
Step 3: Look for Cause and Effect
Step 3: Look for Cause and Effect
After you have a wide array of factors listed out on the whiteboard and a rough idea of the themes that they fit into, it’s time to start digging deeper into each theme. We want to start to form a story about the relationships between these factors, and the best way to start that is by looking at their upstream and downstream effects.
This section of the workshop can take quite a while to do. To speed things up, break up the workshop into smaller groups. It’s good to have a mixture of subject matter experts in each group to keep the conversation going - but try to keep it to 3-5 people in each group. Assign each group a theme to work with. Once everyone is split up into groups and is assigned a theme, have each group spend a while (at least an hour, but it could go for several depending on the subject matter) discussing the causes and effects of their theme through the following lenses:
Environmental - Cultural, political, socio-economic, and infrastructural drivers
Attitudinal - Beliefs, morals, values, norms, fears, and expectations
Behavioral - Actions, policies, and processes
As much as possible, these causes and effects should be informed by research, rather than hunches. It’s okay to draw on the subject matter of the experts in the room, but the more validation you have about these relationships, the more sound and secure your system map will be when it’s done, and the easier it will be to measure changes over time.
Remember that the causes and effects for these factors can be both physical and nonphysical. Let’s look at our example framing sentence of CO2 emissions in the US. Factors making CO2 emissions worse may be cars, freight, air travel, etc.
If we think about causes and effects, we can think about the physical, environmental distance between where the average American works and lives, or we can think about the attitudinal value set around individualism or vehicle ownership as a status symbol. The more likely someone is to value their individualism and freedom, the more likely they may be to own their own car and drive it. The more they drive, the larger their carbon footprint is.
As everyone works to map causes and effects, remember to take breaks in between to keep everyone engaged. After the time is up, have each team go around the room and spend 10 minutes explaining the causes and effects they identified. Note any areas where there may be overlapping factors starting to emerge.
After you have a wide array of factors listed out on the whiteboard and a rough idea of the themes that they fit into, it’s time to start digging deeper into each theme. We want to start to form a story about the relationships between these factors, and the best way to start that is by looking at their upstream and downstream effects.
This section of the workshop can take quite a while to do. To speed things up, break up the workshop into smaller groups. It’s good to have a mixture of subject matter experts in each group to keep the conversation going - but try to keep it to 3-5 people in each group. Assign each group a theme to work with. Once everyone is split up into groups and is assigned a theme, have each group spend a while (at least an hour, but it could go for several depending on the subject matter) discussing the causes and effects of their theme through the following lenses:
Environmental - Cultural, political, socio-economic, and infrastructural drivers
Attitudinal - Beliefs, morals, values, norms, fears, and expectations
Behavioral - Actions, policies, and processes
As much as possible, these causes and effects should be informed by research, rather than hunches. It’s okay to draw on the subject matter of the experts in the room, but the more validation you have about these relationships, the more sound and secure your system map will be when it’s done, and the easier it will be to measure changes over time.
Remember that the causes and effects for these factors can be both physical and nonphysical. Let’s look at our example framing sentence of CO2 emissions in the US. Factors making CO2 emissions worse may be cars, freight, air travel, etc.
If we think about causes and effects, we can think about the physical, environmental distance between where the average American works and lives, or we can think about the attitudinal value set around individualism or vehicle ownership as a status symbol. The more likely someone is to value their individualism and freedom, the more likely they may be to own their own car and drive it. The more they drive, the larger their carbon footprint is.
As everyone works to map causes and effects, remember to take breaks in between to keep everyone engaged. After the time is up, have each team go around the room and spend 10 minutes explaining the causes and effects they identified. Note any areas where there may be overlapping factors starting to emerge.
After you have a wide array of factors listed out on the whiteboard and a rough idea of the themes that they fit into, it’s time to start digging deeper into each theme. We want to start to form a story about the relationships between these factors, and the best way to start that is by looking at their upstream and downstream effects.
This section of the workshop can take quite a while to do. To speed things up, break up the workshop into smaller groups. It’s good to have a mixture of subject matter experts in each group to keep the conversation going - but try to keep it to 3-5 people in each group. Assign each group a theme to work with. Once everyone is split up into groups and is assigned a theme, have each group spend a while (at least an hour, but it could go for several depending on the subject matter) discussing the causes and effects of their theme through the following lenses:
Environmental - Cultural, political, socio-economic, and infrastructural drivers
Attitudinal - Beliefs, morals, values, norms, fears, and expectations
Behavioral - Actions, policies, and processes
As much as possible, these causes and effects should be informed by research, rather than hunches. It’s okay to draw on the subject matter of the experts in the room, but the more validation you have about these relationships, the more sound and secure your system map will be when it’s done, and the easier it will be to measure changes over time.
Remember that the causes and effects for these factors can be both physical and nonphysical. Let’s look at our example framing sentence of CO2 emissions in the US. Factors making CO2 emissions worse may be cars, freight, air travel, etc.
If we think about causes and effects, we can think about the physical, environmental distance between where the average American works and lives, or we can think about the attitudinal value set around individualism or vehicle ownership as a status symbol. The more likely someone is to value their individualism and freedom, the more likely they may be to own their own car and drive it. The more they drive, the larger their carbon footprint is.
As everyone works to map causes and effects, remember to take breaks in between to keep everyone engaged. After the time is up, have each team go around the room and spend 10 minutes explaining the causes and effects they identified. Note any areas where there may be overlapping factors starting to emerge.
Step 4: Create Feedback Loops
Step 4: Create Feedback Loops
Step 4: Create Feedback Loops
With a strong understanding of the causes and effects for each of the themes, we can start identifying feedback loops. These feedback loops can help us start to understand why this system behaves the way that it does, and forms the skeleton of a system map. These loops are often called Causal Loop Diagrams in systems practice.
Start by picking a single factor from the most robust theme you have outlined and listing out what causes that factor. Write each of them on post it notes and stick them on the whiteboard. These causes should be informed by the previous exercise. Continue asking what causes that factor, and what causes that, and so on until you’ve looped back to the original factor. Draw arrows on a whiteboard between each factor and note how the upstream and downstream factors affect each other. Use + and - symbols to denote how these factors are changing. As you create your loops, consider:
With a strong understanding of the causes and effects for each of the themes, we can start identifying feedback loops. These feedback loops can help us start to understand why this system behaves the way that it does, and forms the skeleton of a system map. These loops are often called Causal Loop Diagrams in systems practice.
Start by picking a single factor from the most robust theme you have outlined and listing out what causes that factor. Write each of them on post it notes and stick them on the whiteboard. These causes should be informed by the previous exercise. Continue asking what causes that factor, and what causes that, and so on until you’ve looped back to the original factor. Draw arrows on a whiteboard between each factor and note how the upstream and downstream factors affect each other. Use + and - symbols to denote how these factors are changing. As you create your loops, consider:
With a strong understanding of the causes and effects for each of the themes, we can start identifying feedback loops. These feedback loops can help us start to understand why this system behaves the way that it does, and forms the skeleton of a system map. These loops are often called Causal Loop Diagrams in systems practice.
Start by picking a single factor from the most robust theme you have outlined and listing out what causes that factor. Write each of them on post it notes and stick them on the whiteboard. These causes should be informed by the previous exercise. Continue asking what causes that factor, and what causes that, and so on until you’ve looped back to the original factor. Draw arrows on a whiteboard between each factor and note how the upstream and downstream factors affect each other. Use + and - symbols to denote how these factors are changing. As you create your loops, consider:
For each step in the loop, name each factor with a simple phrase, but try to keep it a noun that doesn’t specify amounts. Going back to our example, if you identified the number of cars on the road and the length of time people were commuting to work, rather than writing “longer commute” just write “commute time” with “+” at both ends of the arrow to denote that as more cars are on the road, the average commute time goes up.
I’ve found that it’s more helpful to think about whether you’re trying to create loops to demonstrate healthy behaviors or unhealthy behaviors. It can be difficult for both loops to coexist in the same system diagram without confusing people. Decide as a group before you start creating your loops if you’d like to focus on what factors contribute to an increasingly healthier system or an increasingly unhealthier one.
That being said, focusing on only health or unhealthy loops can make it hard to discuss some issues naturally. Try to stick to one pattern, but don’t force it.
Note along the way if there are gaps in your knowledge that prevent you from completing a loop. This may be a good place to dig in with other participants later.
Every loop should tell an important story about how your system works. As you’re building your loops, consider building out more specific narratives that can ground these loops in realistic scenarios. These can become powerful ways to get others to connect with the system.
For each step in the loop, name each factor with a simple phrase, but try to keep it a noun that doesn’t specify amounts. Going back to our example, if you identified the number of cars on the road and the length of time people were commuting to work, rather than writing “longer commute” just write “commute time” with “+” at both ends of the arrow to denote that as more cars are on the road, the average commute time goes up.
I’ve found that it’s more helpful to think about whether you’re trying to create loops to demonstrate healthy behaviors or unhealthy behaviors. It can be difficult for both loops to coexist in the same system diagram without confusing people. Decide as a group before you start creating your loops if you’d like to focus on what factors contribute to an increasingly healthier system or an increasingly unhealthier one.
That being said, focusing on only health or unhealthy loops can make it hard to discuss some issues naturally. Try to stick to one pattern, but don’t force it.
Note along the way if there are gaps in your knowledge that prevent you from completing a loop. This may be a good place to dig in with other participants later.
Every loop should tell an important story about how your system works. As you’re building your loops, consider building out more specific narratives that can ground these loops in realistic scenarios. These can become powerful ways to get others to connect with the system.
For each step in the loop, name each factor with a simple phrase, but try to keep it a noun that doesn’t specify amounts. Going back to our example, if you identified the number of cars on the road and the length of time people were commuting to work, rather than writing “longer commute” just write “commute time” with “+” at both ends of the arrow to denote that as more cars are on the road, the average commute time goes up.
I’ve found that it’s more helpful to think about whether you’re trying to create loops to demonstrate healthy behaviors or unhealthy behaviors. It can be difficult for both loops to coexist in the same system diagram without confusing people. Decide as a group before you start creating your loops if you’d like to focus on what factors contribute to an increasingly healthier system or an increasingly unhealthier one.
That being said, focusing on only health or unhealthy loops can make it hard to discuss some issues naturally. Try to stick to one pattern, but don’t force it.
Note along the way if there are gaps in your knowledge that prevent you from completing a loop. This may be a good place to dig in with other participants later.
Every loop should tell an important story about how your system works. As you’re building your loops, consider building out more specific narratives that can ground these loops in realistic scenarios. These can become powerful ways to get others to connect with the system.
Step 5: Classify Your Loops
Step 5: Classify Your Loops
Step 5: Classify Your Loops
Each loop you’ve created can now be labeled. There are a few common classifications of loops:
Vicious - A reinforcing loop that make things get worse and worse over time
Virtuous - A reinforcing loop that gets better and better over time.
Stabilizing - A type of self-correcting (balancing) loop that keeps things from getting worse
Stagnating - A type of self-correcting (balancing) loop that keeps things from getting better
In general, reinforcing loops are associated with exponential change, while balancing loops are associated with plateaus. For a system to remain healthy we tend to need a mixture of both of them, but more often than not the loops we have in the current system exist in the wrong proportion, which leads to an unstable system.
After everyone has finished sharing their loops, the collaborative portion of the workshop is finished. It’s a good idea to inform others about what the next steps will be and when you’ll be following up with them, as they won’t be a part of the next stage.
Each loop you’ve created can now be labeled. There are a few common classifications of loops:
Vicious - A reinforcing loop that make things get worse and worse over time
Virtuous - A reinforcing loop that gets better and better over time.
Stabilizing - A type of self-correcting (balancing) loop that keeps things from getting worse
Stagnating - A type of self-correcting (balancing) loop that keeps things from getting better
In general, reinforcing loops are associated with exponential change, while balancing loops are associated with plateaus. For a system to remain healthy we tend to need a mixture of both of them, but more often than not the loops we have in the current system exist in the wrong proportion, which leads to an unstable system.
After everyone has finished sharing their loops, the collaborative portion of the workshop is finished. It’s a good idea to inform others about what the next steps will be and when you’ll be following up with them, as they won’t be a part of the next stage.
Each loop you’ve created can now be labeled. There are a few common classifications of loops:
Vicious - A reinforcing loop that make things get worse and worse over time
Virtuous - A reinforcing loop that gets better and better over time.
Stabilizing - A type of self-correcting (balancing) loop that keeps things from getting worse
Stagnating - A type of self-correcting (balancing) loop that keeps things from getting better
In general, reinforcing loops are associated with exponential change, while balancing loops are associated with plateaus. For a system to remain healthy we tend to need a mixture of both of them, but more often than not the loops we have in the current system exist in the wrong proportion, which leads to an unstable system.
After everyone has finished sharing their loops, the collaborative portion of the workshop is finished. It’s a good idea to inform others about what the next steps will be and when you’ll be following up with them, as they won’t be a part of the next stage.
Step 6: Build the Map
Step 6: Build the Map
Step 6: Build the Map
At this point, it should just be the core group of folks who organized the original work. Now that you have some well established loops, start grouping and looking for relationships that connect your loops together. These loops should represent the core narrative for how your system works, but they should also branch off into other, smaller causal loops. This is the starting point for your overall system map.
Depending on what the dominant story is you’d like to tell about this system, and your original anchoring statement, you may need to experiment with a few different arrangements for your map. You might need to add new loops to fill out a narrative about how two existing loops connect.
At this point, it should just be the core group of folks who organized the original work. Now that you have some well established loops, start grouping and looking for relationships that connect your loops together. These loops should represent the core narrative for how your system works, but they should also branch off into other, smaller causal loops. This is the starting point for your overall system map.
Depending on what the dominant story is you’d like to tell about this system, and your original anchoring statement, you may need to experiment with a few different arrangements for your map. You might need to add new loops to fill out a narrative about how two existing loops connect.
At this point, it should just be the core group of folks who organized the original work. Now that you have some well established loops, start grouping and looking for relationships that connect your loops together. These loops should represent the core narrative for how your system works, but they should also branch off into other, smaller causal loops. This is the starting point for your overall system map.
Depending on what the dominant story is you’d like to tell about this system, and your original anchoring statement, you may need to experiment with a few different arrangements for your map. You might need to add new loops to fill out a narrative about how two existing loops connect.
This is the point at which you’ll start to find a lot of new connection points that might not have been addressed earlier. Some things I’ve found helpful at this stage are:
Don’t feel the need to keep every part of the diagram. If there is a factor that isn’t part of a loop, it might not be an important part of the story. Focus on the areas that best address your original framing statement.
Write out conclusions as you discover them. As you start to draw new connections, write out a narrative for them so you can keep track of them. As the map gets more interconnected, some of those stories can easily get lost or forgotten. Having the stories helps you understand which parts of the map are most important and which are less important.
This is the point at which you’ll start to find a lot of new connection points that might not have been addressed earlier. Some things I’ve found helpful at this stage are:
Don’t feel the need to keep every part of the diagram. If there is a factor that isn’t part of a loop, it might not be an important part of the story. Focus on the areas that best address your original framing statement.
Write out conclusions as you discover them. As you start to draw new connections, write out a narrative for them so you can keep track of them. As the map gets more interconnected, some of those stories can easily get lost or forgotten. Having the stories helps you understand which parts of the map are most important and which are less important.
This is the point at which you’ll start to find a lot of new connection points that might not have been addressed earlier. Some things I’ve found helpful at this stage are:
Don’t feel the need to keep every part of the diagram. If there is a factor that isn’t part of a loop, it might not be an important part of the story. Focus on the areas that best address your original framing statement.
Write out conclusions as you discover them. As you start to draw new connections, write out a narrative for them so you can keep track of them. As the map gets more interconnected, some of those stories can easily get lost or forgotten. Having the stories helps you understand which parts of the map are most important and which are less important.
Socializing & Iterate on the Map
Socializing & Iterate on the Map
Socializing & Iterate on the Map
Once you have your initial map, it’s time to start socializing it with others who participated in the original workshop.. Now is the time to invite everyone back together and explain what you’ve been doing, how you’ve been doing it, and what your key findings are so far. The goal here is to act transparently and to seek feedback from others. At this stage:
Remember that this is just the initial map. People are going to have opinions and the map is going to need refining.
Remind everyone of the original anchoring question. Otherwise you may get feedback about issues in the system that may be valid, but are out of scope for what you’re trying to identify and affect.
Focus on the most important story. You’ve likely come up with several narratives throughout the process of building this map. Focus the initial feedback so you can walk away with clear action items to improve upon it.
Save your iterations. Once you’ve shared your map and gathered feedback, you’ll likely need to make some adjustments to your map. Make sure to save a copy of the original map. Being able to show the evolution of the map is an important part of your narrative that can help stakeholders understand your thinking over time!
Once you have your initial map, it’s time to start socializing it with others who participated in the original workshop.. Now is the time to invite everyone back together and explain what you’ve been doing, how you’ve been doing it, and what your key findings are so far. The goal here is to act transparently and to seek feedback from others. At this stage:
Remember that this is just the initial map. People are going to have opinions and the map is going to need refining.
Remind everyone of the original anchoring question. Otherwise you may get feedback about issues in the system that may be valid, but are out of scope for what you’re trying to identify and affect.
Focus on the most important story. You’ve likely come up with several narratives throughout the process of building this map. Focus the initial feedback so you can walk away with clear action items to improve upon it.
Save your iterations. Once you’ve shared your map and gathered feedback, you’ll likely need to make some adjustments to your map. Make sure to save a copy of the original map. Being able to show the evolution of the map is an important part of your narrative that can help stakeholders understand your thinking over time!
Once you have your initial map, it’s time to start socializing it with others who participated in the original workshop.. Now is the time to invite everyone back together and explain what you’ve been doing, how you’ve been doing it, and what your key findings are so far. The goal here is to act transparently and to seek feedback from others. At this stage:
Remember that this is just the initial map. People are going to have opinions and the map is going to need refining.
Remind everyone of the original anchoring question. Otherwise you may get feedback about issues in the system that may be valid, but are out of scope for what you’re trying to identify and affect.
Focus on the most important story. You’ve likely come up with several narratives throughout the process of building this map. Focus the initial feedback so you can walk away with clear action items to improve upon it.
Save your iterations. Once you’ve shared your map and gathered feedback, you’ll likely need to make some adjustments to your map. Make sure to save a copy of the original map. Being able to show the evolution of the map is an important part of your narrative that can help stakeholders understand your thinking over time!
Step 7: Look for Opportunity
Step 7: Look for Opportunity
Step 7: Look for Opportunity
Once you’ve run through a few rounds of feedback, you should have a map that solidly speaks to your anchoring question. It should thoroughly explain the underlying causes and effects that lead to a healthy or unhealthy system, and you should have a few narratives to ground your map in reality.
Now is the time to look at the current state of the system and ask yourself what aspects of the system are preventing it from reaching the north star you’d ultimately like to get to? With the system printed out (now is a great time to utilize a plotter, if you have one) have everyone spend some time examining it and writing down problem statements. Your problem statement should acknowledge the current situation and also the north star you’d like to get to.
From here you can focus on identifying where you have the most leverage: where can you exert a small amount of force and have an outsized impact on the system itself? Is there anywhere where a small action can cause an entire watershed in your system to reshape? Think about:
Where are loops working against each other?
Where are there long delays in feedback loops that make undesirable behaviors even worse?
Where are there loops that are dominating other aspects of the system, even if they’re undesirable?
Is there anywhere where stagnation is preventing the system from moving forward?
Where are you seeing strong downstream effects on the rest of the system? Are those areas positive and ripe for reinforcement, or negative, and ripe for disruption?
These statements can become the seeds for How Might We statements that can drive future design proposals for change. As you iterate through these HMW statements, use the strong narratives about the system that you’ve already created to tell a story about how things are today and how you expect them to change in the future.
By thinking about design solutions as not just features you could push, but in terms of people, products, and processes as all playing an equal role in the solution, you can start to affect the system through the same environmental, behavioral, and attitudinal lenses we examined earlier. And you can also use your map of the system to check your proposals for any potentially unforeseen downstream effects on other loops in the system.
Once you’ve run through a few rounds of feedback, you should have a map that solidly speaks to your anchoring question. It should thoroughly explain the underlying causes and effects that lead to a healthy or unhealthy system, and you should have a few narratives to ground your map in reality.
Now is the time to look at the current state of the system and ask yourself what aspects of the system are preventing it from reaching the north star you’d ultimately like to get to? With the system printed out (now is a great time to utilize a plotter, if you have one) have everyone spend some time examining it and writing down problem statements. Your problem statement should acknowledge the current situation and also the north star you’d like to get to.
From here you can focus on identifying where you have the most leverage: where can you exert a small amount of force and have an outsized impact on the system itself? Is there anywhere where a small action can cause an entire watershed in your system to reshape? Think about:
Where are loops working against each other?
Where are there long delays in feedback loops that make undesirable behaviors even worse?
Where are there loops that are dominating other aspects of the system, even if they’re undesirable?
Is there anywhere where stagnation is preventing the system from moving forward?
Where are you seeing strong downstream effects on the rest of the system? Are those areas positive and ripe for reinforcement, or negative, and ripe for disruption?
These statements can become the seeds for How Might We statements that can drive future design proposals for change. As you iterate through these HMW statements, use the strong narratives about the system that you’ve already created to tell a story about how things are today and how you expect them to change in the future.
By thinking about design solutions as not just features you could push, but in terms of people, products, and processes as all playing an equal role in the solution, you can start to affect the system through the same environmental, behavioral, and attitudinal lenses we examined earlier. And you can also use your map of the system to check your proposals for any potentially unforeseen downstream effects on other loops in the system.
Once you’ve run through a few rounds of feedback, you should have a map that solidly speaks to your anchoring question. It should thoroughly explain the underlying causes and effects that lead to a healthy or unhealthy system, and you should have a few narratives to ground your map in reality.
Now is the time to look at the current state of the system and ask yourself what aspects of the system are preventing it from reaching the north star you’d ultimately like to get to? With the system printed out (now is a great time to utilize a plotter, if you have one) have everyone spend some time examining it and writing down problem statements. Your problem statement should acknowledge the current situation and also the north star you’d like to get to.
From here you can focus on identifying where you have the most leverage: where can you exert a small amount of force and have an outsized impact on the system itself? Is there anywhere where a small action can cause an entire watershed in your system to reshape? Think about:
Where are loops working against each other?
Where are there long delays in feedback loops that make undesirable behaviors even worse?
Where are there loops that are dominating other aspects of the system, even if they’re undesirable?
Is there anywhere where stagnation is preventing the system from moving forward?
Where are you seeing strong downstream effects on the rest of the system? Are those areas positive and ripe for reinforcement, or negative, and ripe for disruption?
These statements can become the seeds for How Might We statements that can drive future design proposals for change. As you iterate through these HMW statements, use the strong narratives about the system that you’ve already created to tell a story about how things are today and how you expect them to change in the future.
By thinking about design solutions as not just features you could push, but in terms of people, products, and processes as all playing an equal role in the solution, you can start to affect the system through the same environmental, behavioral, and attitudinal lenses we examined earlier. And you can also use your map of the system to check your proposals for any potentially unforeseen downstream effects on other loops in the system.
Implementing Strategies
Implementing Strategies
Implementing Strategies
As you start to narrow your opportunities down to the ones that are the most viable, think about which options can have a multiplicative effect on the system. You may be able to combine two or three smaller ideas that can build on top of each other to be greater than the sum of their parts. Pay careful attention to what kind of data instrumentation you’ll need to put in place to determine early on if your assumptions are correct. By identifying these before you ever act, you can also understand what baselines you need to establish and if the correct instrumentation is in place for those.
Once you settle on a solution, draw the strategy out onto your system map so you can explain to others what effect you expect the changes to have. You can highlight specific strategies by graying back the rest of the visualization so it’s clear and easy to see exactly where the changes are being introduced.
As you start to narrow your opportunities down to the ones that are the most viable, think about which options can have a multiplicative effect on the system. You may be able to combine two or three smaller ideas that can build on top of each other to be greater than the sum of their parts. Pay careful attention to what kind of data instrumentation you’ll need to put in place to determine early on if your assumptions are correct. By identifying these before you ever act, you can also understand what baselines you need to establish and if the correct instrumentation is in place for those.
Once you settle on a solution, draw the strategy out onto your system map so you can explain to others what effect you expect the changes to have. You can highlight specific strategies by graying back the rest of the visualization so it’s clear and easy to see exactly where the changes are being introduced.
As you start to narrow your opportunities down to the ones that are the most viable, think about which options can have a multiplicative effect on the system. You may be able to combine two or three smaller ideas that can build on top of each other to be greater than the sum of their parts. Pay careful attention to what kind of data instrumentation you’ll need to put in place to determine early on if your assumptions are correct. By identifying these before you ever act, you can also understand what baselines you need to establish and if the correct instrumentation is in place for those.
Once you settle on a solution, draw the strategy out onto your system map so you can explain to others what effect you expect the changes to have. You can highlight specific strategies by graying back the rest of the visualization so it’s clear and easy to see exactly where the changes are being introduced.
Adapt and learn
Adapt and learn
Adapt and learn
As you implement your strategies and start to collect more data about how the system responds, you’ll start to understand more about how the system works. You’ll need to make continual adjustments along the way. It’s helpful to document the journey and assess every now and then whether the system is changing in ways you expect. Remember, systems are always changing, which means the work on them is never done. The goal should never be to “fix a problem” - but rather to establish a direction and continually work to improve the system’s overall health and sustainability over time.
As you implement your strategies and start to collect more data about how the system responds, you’ll start to understand more about how the system works. You’ll need to make continual adjustments along the way. It’s helpful to document the journey and assess every now and then whether the system is changing in ways you expect. Remember, systems are always changing, which means the work on them is never done. The goal should never be to “fix a problem” - but rather to establish a direction and continually work to improve the system’s overall health and sustainability over time.
As you implement your strategies and start to collect more data about how the system responds, you’ll start to understand more about how the system works. You’ll need to make continual adjustments along the way. It’s helpful to document the journey and assess every now and then whether the system is changing in ways you expect. Remember, systems are always changing, which means the work on them is never done. The goal should never be to “fix a problem” - but rather to establish a direction and continually work to improve the system’s overall health and sustainability over time.