Secret Sauce and Systems Change: Seeing your synthesis differently
By Gwen Gage
As our team worked through a global health design challenge last year, we found the breadth and scope of the research was both immense and involved multiple layers of complexity. To help make sense of this complex challenge, I created a visual method for synthesizing design research data that involves iteratively organizing and reorganizing data to surface insights. Read on to explore why working through this visual approach from left to right then top to bottom, can be particularly useful when looking to create systems-level change.
Developing this visual synthesis process
This process emerged in the course of our research into vaccine and other health campaign effectiveness in global health. The research and synthesis portion of the design process can be overwhelming, especially on large, ambiguous topics. Our task was to examine the entire system of vaccine delivery campaigns in sub-Saharan Africa and determine how it could be improved. We were to look at what levers exist to create change in the system.
Tactically, we needed to do two things. Firstly, we needed to map the basic structure of a campaign. As case studies, we focused on Polio and Schistosomiasis campaigns run in Liberia and Ghana. To clarify the structure of a campaign, we would create both a process map and a stakeholder landscape, focusing on the tangible pieces of campaign delivery. Secondly, we needed to understand how global-level organizations engage in campaigns. For this, we were focused on the meta, emotional or cultural aspects behind campaigns that ultimately shape outcomes.
I will walk you through the process I’ve laid out from left to right.
Iceberg model
You may recognize this triangle diagram as the Iceberg Model. Your purpose or the map you are seeking to create, determines which part of the iceberg you are investigating. This can help keep the parameters or boundaries of the map in check.
The model implies that just like an iceberg, the visible events seen at the surface are only the tip of a bigger system. When thinking about systemic infrastructure problems, an example of a visible event might be heavy traffic at 5pm. Under the theoretical “waterline”, there are patterns and structures that led to the visible event on the surface. For instance, the traffic may be a result of the pattern of daily commute times and the structure may be a suboptimal road layout that creates bottlenecks at the bridges. Finally, lying beneath all of the previous layers are the actors’ mental models, which may include their emotions, biases, cultural upbringing, etc. For our traffic example this might be something like drivers’ moods at 5pm, or drivers’ preference towards driving on certain routes over others. This model can be applied to every situation where there are human actors, though it is particularly useful when looking at creating systems-level change. We often focus on trying to solve the problems that we can see at the top, but to create real, lasting change we may need to focus our attention at the deeper levels.
Row #1: Structural Maps
The top, light blue row in the visual synthesis process deals with the production of structural maps — maps that primarily answer the “what” question and give some indication to the tangible “why”. This means that a structural map addresses the top three layers of the iceberg — events, patterns and structures. Examples of structural maps might be process maps or stakeholder landscapes. A structural map done well should show us how a visible event is the result of specific patterns and structures.
To create our structural maps we synthesized data from roughly 50 virtual interviews, in which we used semi-structured interview guides. We interviewed a cross-section of country health staff at the national, subnational and community levels in both Liberia and Ghana about the campaign delivery process. From these conversations we were able to detail the basic steps involved in the lifecycle of a campaign, from funding and planning to delivery and reporting. We wanted to use this information to establish a baseline chronology of events and handoffs to bring clarity to a complex system.
By combining secondary research with the content of the interviews, we built both a process map and stakeholder landscape for each subtopic. This would help us understand what dynamics or hierarchies may exist, who are the key players, and where exchanges occur.
Structural Maps Process:
Following the process from left to right on this light blue row, the first thing I did was go through the interviews and identify relevant quotes or data that highlighted something interesting about the system. Note, there’s no secret method here. To sort the data, I simply made sure I knew what question I was trying to answer, then methodically worked through the data, flagging anything relevant to that question.
It was important to indicate somehow, either through a tag, a line color, something, which interviews the information was sourced from. You may think you’re never going to need to find it again, but trust me you will, probably a hundred times. So the best thing you can do is keep that fidelity from the beginning. You can also just use the direct quote in place of a summary, or you can use the quote and add a summary next to it, for easier skimming. Either way, make sure the direct quote is somehow linked to it, because once again, you’ll think you won’t need it, and you will. Do yourself a favor and do it from the start. (The data below utilized Lucidchart’s Data Linking feature, which allowed me to tag each box with the corresponding metadata.)
Then I categorized the quotes/data by type — red for a problem area, green for the current solution or workaround, blue for relevant stories, and yellow for contextual information. This first pass starts to give you a sense for what information is even being presented.
Then I sought to organize the data. This involved physically moving the boxes around the board to reorganize them. Prior to this, I didn’t have much of a background in information design, but I came across a concept I found very useful, called L.A.T.C.H. theory. This theory describes the various ways data can be organized. It can be organized by location [L], alphabetically [A], by time [T], by category [C], or according to a hierarchy [H]. By organizing your data in several different ways, you give yourself more chances to surface patterns. So this step should be done multiple times using different elements of the L.A.T.C.H. theory.
I first organized the data by topic. This helped me get a sense of the kinds of things people were speaking to us about.
If I found that a quote could fall between two categories I would sometimes put the quote in both places or I would examine whether the two categories were actually more interrelated than I thought. I might find that they were too close and could either be combined or differentiated further to create more clarity and distinction. This was also a benefit of using a visual method rather than a linear tagging software, because I could easily move or re-sort data if I changed categories.
Next, I organized the data chronologically, according to where it fell in a campaign’s lifecycle. By categorizing the information this way you can place your data in context. Simply looking at the chronology, you can start to get a sense of the relative amount of each data type. Are there a lot more reds than greens, meaning there are problems without solutions? Are there a lot of red boxes clustered at a certain area or a certain step in the process?
This was an enlightening exercise because it highlighted that our country-level research mentioned relatively few problems/red boxes in the pre-campaign phase. And the pre-campaign phase is typically where global orgs are most involved. This would seem to imply that their involvement may alleviate issues at this level.
Most of the problems/red boxes were clustered in the delivery phase of the campaign — a point at which most global orgs are not directly involved and are reticent to provide direct support.
Finally, I organized the data by emerging theme, creating something like a theory of change where steps built towards other steps. This helped me start to understand how pieces of data built on other data towards a larger outcome.
The last step is to analyze these results. Ask yourself, what is this telling us? Is it telling us something real, or does it just look real because I don’t have enough data?
It was interesting for us to compare the categories of issues that emerged from the country-level interviews with those from the global-level interviews. The country-level data really highlighted the tactical issue of reaching remote areas to deliver services. These problems were often very tangible and straight-forward — the roads are impassable, there was no gasoline, etc. However, when we analyzed the global-level data, a different set of issue areas emerged. This incongruence doesn’t necessarily mean that we had a gap in our research, but rather that the sourcing of information itself created two different pictures. This means that perhaps an additional issue we could highlight is that the two parties have radically different lenses with which they view the same situation. This can be a problem when these two parties come together to build a plan. They are likely working towards slightly different goals and prioritizing different issues.
The arrow at the end of the process indicates the next steps, which are either to do more research to fill in gaps, or decide that you have sufficient results and move on to creating something that can be tested or piloted.
Meta Maps and Process
The meta maps focused on the last layer of the iceberg model and sought to uncover any problematic mental models at play in the global level and I used the same process. I pulled quotes from interviews, color-coded them and clustered them roughly into themes. Because these maps focused on less tangible things like emotions and beliefs, the data needed a certain amount of extrapolation. Interviewees weren’t likely to lay out the psychology behind why they think something, so a certain amount of pattern finding must be done. I organized the data by level of abstraction, starting with the visible event and going deeper to uncover the underlying forces that led to the event. Once I had the data organized in these levels, I began to link them together in causal chains, which semi-neatly laid out the underlying factors that lead to an outcome.
Let’s look at an example to understand this better. One issue we identified was that there is a lack of funding flexibility around certain elements of campaigns. We wanted to find out what is driving that dynamic? One thing that came from our interviews was the that each agency runs according to their “comparative advantage” and they can be resistant to funding things they perceive as outside of that scope. However, many important elements fall between the gaps spanning various organizations’ comparative advantage. This led us to try and understand why these organizations are so tied to this concept of comparative advantage? We discovered one reason is that it can be a good fundraising tool. It’s easier to raise money when you can tell people exactly what their money is going towards. We can postulate that organizations were also reticent to go outside their comfort zones, having never funded certain things before, they were less eager to get involved. Underlying these issues is a deeply engrained culture of risk aversion within health and global health. In a competitive space, like global health, no organization wanted to be the one to fund something outside their scope and have it go poorly. We looked at all of the issues we’d selected and tried to identify what factors were driving those issues from behind the scenes.
After this step we grouped the causal chains into insights to get a better sense of the major themes bubbling to the top. This is really a process of taking a large amount of disparate data and giving it some basic structure. As you work more with the data, things will begin to cluster naturally around a few concepts.
What the maps tell us
It might not be explicit, but you may start to notice that, sort of like planets, things seem to be orbiting around certain concepts or a lot of data is pointing in the same direction. This method of synthesis will only work if you are truly deep in the data, spending significant time reading and working with the content. For that reason, it is not a process that can be done quickly and is perhaps not the most efficient. It is simultaneously a production method and a research method, because you may produce visual artifacts but it’s also about engaging with the data and understanding it from different viewpoints. As you do that, your final ideas will naturally develop.
This method worked very well for me as a visual thinker. With this method I was able to produce layered insights that went beyond simple connections or relationships. Rather than simply grouping related data under themes, this process produced more of a hierarchical/causal understanding of the data — why things were happening and what was behind them.
Note about tech used
As far as digital tools go, I primarily used Lucidchart and Miro for this work. Miro is more oriented to be a whiteboarding tool, so it runs smoother but has simpler capabilities. Lucidchart has more options in terms of visual design, but is a heavier program that can slow down your computer if you’re attempting to use multiple applications.
Conclusion
Our project was daunting at times and it pushed our team to the limits on more than one occasion; it was a real journey. The scope was huge and so much was being asked of us, and if you paid attention to the problems they got even bigger. This visual synthesis method felt like a steadying force because all I had to do was trust the process — I knew if I work with the data long enough, something had to come out of it. It may not be the revolutionary thing the client believes they are looking for, but it will at least be true to the data.
There is a tendency in design and other industries to rely on simple tools to surface the solutions. Sometimes we think, if we just create a relationship map, we’ll understand everything about a system and know how to fix the problem. But then, if that map doesn’t tell us anything, we might panic because it feels like our tool didn’t work. In this work, we assumed that our stakeholder landscapes would tell us more about power dynamics, how to make change, etc. But they didn’t. The orgs that had the most connections to them weren’t necessarily the biggest players, they just happened to have the most.
This might sound ridiculous, but in hindsight I think I approached this process a little like meditation. Every day I would not spend time being worried about finding that magical insight I would just methodically work on the next step in the process, like categorizing the data in a new way and seeing if that showed me something. And it always did. In that way it became a sort of self-fulfilling practice.
The making aspect was also vital to its success. Sometimes traditional research methods can lead to stagnation because they rely so heavily on the analytical side rather than the making side. The process of having to take that data and turn it around in different ways prevented us from getting stuck and allowed us to move more quickly through synthesis. If you’re just listing your data and not actively working with it and rearranging it, you’re putting a lot of pressure on your brain to conjure a miraculous insight.
I was actually a little reluctant to share this process publicly because I don’t want to contribute to the notion that there is a “right” way to do design work. Sometimes, we can get wrapped up in trying to find the perfect or “right” framework to be. In reality, a variety of processes could do the job. For me I decided to zero in on the iceberg model as a base framework because it was simple, could be applied to a broad range of things and the iceberg analogy was easy to remember.
There is no magic here. It’s just a daily slog, working with your data to see what comes out. And I actually find that fact really comforting because it’s something everyone can do. There is no ‘designerly’ secret sauce that some people just have; there are simple steps you can apply to synthesize your data and generate outcomes, you’ve just got to be willing to put in the work.
