This is an issue I’ve often thought about. Whenever I present a system’s map I always preface it with “This map is wrong, it only exists to start a conversation.” I’ve found that I have to do that because either people get instantly involved in trying to correct small parts of the map (missing the broader point) or they disengage and assume I understand whatever’s going on better.
The solution, in my mind, has to come from separating two of the big uses of systems mapping and developing separate training around each.
- Analysis/exploration — this is the minutia and complexity and neutral description and research angle that wonks and detailed picture people love.
- Story telling/findings — this should be the outcome from 1. It should be simple and oversimplification doesn’t matter so long as we can “check the footnotes” so to speak if we so desire. It’s rare though to see a systems map get successfully converted into a solid three-part story that’s digestible. We want to show the detailed dynamics that make the story believable and rigorous and interesting and we also don’t want to “waste” the work that went into creating 1, but doing so muddies the story that you’re trying to tell and destroys conversation. I would also add that writing stories for systems is harder than writing a normal story. Where do you begin? Once you’ve begun, where do you go?
The broad issue at hand is that data doesn’t speak for itself, and systems maps are just another form of structured data. Many people have foolishly believed that a visualization component would relieve them of the responsibility of interpretation and storytelling, resulting in a wave of complex maps that tell no story. Good writers are what is needed and I’m skeptical that there’s a clean technical solution to this problem.