The map is not the territory. You've heard this before and I've quoted it before. The longer quote (due to Alfred Korzybski) from which the snappy soundbite originated adds some valuable context:
A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.
I was thinking about that this week as I came to a product new to me but quite mature with a very rich set of configuration options. When I say rich, I mean — without casting any shade, because I have been there and understand — it is set in multiple locations, has extensive potential effects, and is often difficult to understand.
For my current project I consider it crucial to get a non-shallow view of how this works and so I began to explore. While there is some limited documentation it is, as so often, not up to date so mostly I worked in the codebases. Yes, plural, because this product spans multiple repositories.
As I went I made a map. As I went further I revised the map. As I showed the map to others who already know the territory I corrected the map based on their feedback and revisited locations to work out where I had gone wrong.
This is bread-and-butter for me. I'll always make a model, even if just an informal in-head one. Here I knew in advance that I'd need to externalise it and I had no instinct for its size and shape so I went straight to Miro. This is what it looks like (or looked like at one point, it's still evolving):
I apologise that I can't share the detail, but the image shows the general idea: it superimposes geography, topology, landmarks, observations, open questions and connections. It leaves instructions behind so I know how to get to places again. It is messy and incomplete and that's OK. It's for me.
Satisfied that I had sufficient knowledge from my first pass, I wondered how to share it with the rest of the team. Not everyone needs to be at the same depth of understanding but it'll help if we have a common perspective on the key concepts and relationships.
I started to abstract information from my map and arrange it in ways that didn't reflect the situation on the ground with precision but instead emphasised the key elements, where they could be found, and how they could be navigated. Here's what that looks like (again, at one point, again, with detail obscured):
It doesn't come from direct any local cartography and no-one is going straight to a specific line of code from here, but this representation is also a map.
--00--
The map is not the territory. You already knew that and I already knew that. So why are we here? I'm here because I think it's interesting to reflect on the usefulness part of the Korzybski quote.
Neither of my maps is the territory, but then neither of them pretends to be. The first helps me, an explorer exploring, to orient myself and provides a basis for comparing notes with others who already have some comprehension of the terrain. The second helps me, a messenger with a message, to transmit my information to an audience in such a way that they get a sense of the landscape and its key features.
In the same way, these two representations of a slice of London also serve very different needs by emphasising very different informational requirements in very different ways:
My first map is somewhat analogous to the upper Ordnance Survey map. There are rich layers of information crammed into it and low-level navigation is possible using it but getting a sense of the wider geography requires careful scrutiny and effort on the part of the observer.
My second map is somewhat analogous to the tube map. It permits valuable conversations at a useful level of abstraction for those wanting to move at speed from rough area to rough area. You wouldn't want to try to walk from A to B using it but you can get a good idea about what As and Bs there are and how they might be linked.
--00--
The map is not the territory. You know this, because you've been annoyed so many times by the documentation you're looking at being completely unsuited for your purpose at that time. But when you're sharing information, when you're making that map, do you think much about the difference between what the user will need and what your maps show, about how which aspects of the territory to focus on to make it useful, about how to minimise that utility gap?
Mind the gap.
Images: Pawprint Family, The Map Centre, Transport for London
Comments
Post a Comment