The Social System Mapping Origin Story

I (Christine Capra) fell in love with System Mapping in about 2005 and started making maps at every opportunity. Some time after that, I began to work with intentional change networks and had the opportunity to create some network maps. From this, I began to imagine combining the two map-types. Over time a vision took hold of me – for how mapping could be used as liberatory, paradigm-shifting & systemically regenerative. Maps that grew and adapted with an evolving network over time. Maps that didn’t just statically reflect a dimension or two at a given moment, but could inform and widen ongoing adaptive action, acting as an ongoing scaffold to help see, design and build the change-networks we needed. But the technical tools needed to visualize and data-source the kind of maps my imagination was craving didn’t exist. In 2013, as this vision was maturing, nothing even came close. was the first step towards that liberatory mapping vision that had grabbed hold of me. Kumu put graph data visualization online and in the hands of non-experts and non-coders. Kumu’s maps are available to anyone chosen, able to show an unlimited amount of information about each node as well as for each connection. It is deeply customizable and highly interactive so that each viewer can explore and interpret as they choose, independent of some top-down expert. Access to the creating, viewing, analyzing and interpreting graph visualizations was democratized – yayy!!!

But we still had a data-sourcing problem – there was no tool that made it easy to gather the kind of data our maps required from large groups of people. Even existing SNA tools were fussy, friction-full and nearly useless with large populations. And manually creating a map of any size was so time-consuming that my vision had no space in which to unfold.

To solve that data-gathering problem Tim and I (and a series of coders – most recently and importantly Alex Musat) developed sumApp as the second step to creating the kinds of maps I was yearning to create. sumApp is unlike any other data-gathering tool, designed explicitly with the intent of enabling the kind of networked paradigm-shifting and system-transformation mapping work we wanted to support – data that was:

  • Updatable
  • Iterate-able
  • Accessible
  • Crowd-sourced
  • Multi-dimensional
  • Cross-purposeful
  • User friendly, especially with very large groups

and over time, it became much more (read more about it here )

Once the technical log-jam was broken, the next challenge to my vision was that all the obvious mapping labels were already being used – differently. ‘Network map’ already meant several things – none of which came near what we were doing or intending. I tired of explaining why OUR ‘network map’ was NOT like the ‘network map’ people had in their minds. Explaining why the shortcomings of ‘network map’ that they were presenting to me were not shortcomings of OUR ‘network maps’. I saw that the existing model in people’s minds over-rode everything I said. I spent all my time trying to erase existing mental models and rarely got to paint the actual picture I wanted to present. Just helping people see what I was showing them (even when it was an actual map of ours in Kumu) was so exhausting, that by the time I succeeded in any given instance, I hardly cared anymore.

Kumu and sumApp together are unique. The kinds of maps we can create with them are unique and distinct from any other system maps or social network maps or asset maps or network maps or influence maps or any other kinds of maps people were used to seeing. At first glance they look very similar to other ‘network maps’, but they play by different rules, they are far more dimensional, and they are successful in different contexts. Most people couldn’t see the difference. And that mattered.

  • First – it mattered because our maps were often dismissed out of hand based on preconceived notions of what I was offering.
  • Second – it mattered because even when creating a map with sumApp and Kumu, people’s imaginations were trapped in one box or the other and they wouldn’t cross the boundaries in their minds that our kind of mapping was designed to help them cross. This meant that they weren’t actually doing what I was trying to enable them to do, and they got only a small portion of the value I wanted them to get from their maps.
  • Third – it mattered because, while adhering to those old conceptual boundaries, they also adhered to old process constraints which limited their ability to develop and move a map forward. They tried to comply with all kinds of rules that weren’t relevant and that hindered their own hopes and progress.
  • Fourth – and maybe most importantly – it mattered because all those other kinds of maps are products. You define a preconceived outcome, implement a 5-step plan, and end up with a product – a thing, a document, however interactive – some experts make it, some others have it presented to them and poke at it a little bit. It’s a short-lived object that spends a moment in a spotlight and then ends up in a drawer or at the end of a never-clicked link. Hardly worth the effort. Whereas what we were (and still are) trying to generate was/is a collaborative process, an ongoing network-wide conversation, a lens into the evolving life of a network, an emergent and adaptive tool for both reflection and action that increases the effectiveness of all the network actor’s efforts.

Anyway – after struggling with those challenges for the first few years after developing sumApp, I realized that our framing was a huge problem. Using language that had already been applied differently elsewhere was the entirely wrong starting point for a conversation or a process. Whereas, if I gave it it’s own name, we’d be starting with a fresh canvas. I could paint whatever picture I wanted and people could see each part of it by it’s own merits, liberated from the pre-existing model in their own minds. It became clear we needed a name-change.

So I did some brainstorming and came up with some options, and then did some googling to see which of my options was already being used elsewhere. Other labels I considered:

  • Eco-system maps (too broad, too many other applications of it already being used)
  • Social eco-system maps (again – used elsewhere and used very loosely)
  • Human System Maps (I liked that, but didn’t want to step on Human Systems Dynamics or imply an endorsement or an association that didn’t exist at the time – out of respect for Glenda’s Eoyang’s work)

I landed on ‘Social System Mapping’ which was regrettably long, a bit cumbersome to say, not punchy or cute or catchy, and unfortunately easy to mis-hear as ‘system mapping’ – which still happens too often. But more important to me than those drawbacks – there was no conflicting or confusing use of the term that I could find at that time. It wasn’t even a ‘term’. If you searched on Social System Map- or Mapping, nothing using that precise phrase came up. No-one was referring to anything as a social system map, so that clinched the deal – it was adequately descriptive and free for the taking – so I claimed it. We have henceforth always referred to what we do as ‘Social System Mapping.’

Re-naming our maps brought some unexpected (but welcome) consequences:

  • It allows us to define Social System mapping by not just the technology or by the content being visualized, but also a set of principles that are narrower and more clear about intentions than other kinds of mapping. We get to attach explicit ethical purpose to the label we use, regardless of how people choose to use the technology. In other words, with Social System Mapping the principles drive the process, the content and the technology, not the other way around.
  • It allows us to theorize, test and develop a methodology specific to our purpose and principles that resonates with the best parts of other mapping methods, but isn’t beholden to any of the irrelevant constraints of other methods. We’re developing a methodology along with a tool-set that is purely focused on using this type of mapping to serve the ultimate liberatory and regenerative paradigm-shifting purpose.
  • It created a new field of professional practice, shared learning and shared exploration. This definition enables us to say ‘this is what we do, this is why we do it, this how we do it’ and know that carries a consistent meaning.

There are multitudinous other mapping tools out there, other ways of using Kumu and sumApp separately and together, other types of maps, other methodologies, other process and design principles, other intentions – all of which are probably valid and potentially wonderful. This document is meant to fill in my definition for my freshly-coined neologism ‘Social System Mapping’, and meant to help reduce the confusion inherent in the term and distinguish it from all the other kinds of mapping that it can be conflated with. My hope is that most of the mappers who use sumApp affirm these principles and this definition of Social System Mapping. My belief is that they resonate for most.

This is the vision for this field that has driven me since we began. This is the journey I’m inviting people to take together in the context of Social System Mapping. This, as distinct from any of those other valid and wonderful activities that fall under the term ‘mapping’.

Much of what is articulated below is aspirational, but by clarifying the vision and the related principles and intentions, I invite everyone who learns to make maps with sumApp and who participates in those maps to move a little bit closer to making it a reality.


3 1 vote
Article Rating
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments