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.
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.
If you’re going to run a workshop to map a system, you’ll need to build up a team in a few layers:
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:
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.
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.
“What factors account for the current rates of CO2 emissions in the United States?”
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:
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:
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:
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.
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:
Each loop you’ve created can now be labeled. There are a few common classifications of loops:
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.
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:
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:
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:
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.
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 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.