Last week I put out a tweet after a restless nights sleep with my 18-month-old son. Do you know that feeling of being half awake and thinking about thinking? I felt like I had to put something out there. Twitter didn't disappoint and quickly told me I was wrong.
I enjoy thinking about thinking, so I indulged in some more thinking about maps.
My understanding of a map is that they are a moment frozen in time; a snapshot of networks and tributaries; a top-down view at a specific resolution of a system, but ultimately, a tool for understanding.
Social understanding, specifically.
Because whilst one might fixate on the artefact, the real power lies in building it with other people. Why?
It reveals the whole system to the team. Everyone approaches the system from a different perspective. A map helps everyone see the entire system and how people contribute to it (see, the oft-quoted parable of the blind men and the elephant).
A map demonstrates to stakeholders that you have acquired the right amount of domain knowledge and know what you're talking about.
In my experience with service design, I am often an external contributor who knows little about the system. Often stakeholders and subject matter experts are wary of people like me coming in and suggesting a change (after all, who likes change? And who is this dick head with a man bun telling me my process is inefficient?!).
So a map gets you in detail: understanding the system, it's quirks, the language people use—a real anthropological investigation—and, ultimately, it is a tool for building trust. (For me, This is the fun part of discovery: immersing yourself in the system).
As soon as you commit to creating a map, it is out of date. There are planned releases on the backlog, strategies to be delivered, workarounds evolving (because, humans). So it's almost impossible to remove time from the process.
Then a person's experience of a service is sequential. It's effectively a story of that person living with, accessing, and struggling with your service.
In a previous life and career, I worked with storyboards in the film industry, and one can draw an immediate parallel between the two templates. (Storyboards aren't new in service maps, but are more prevalent in their cousins, service blueprints--the future state map). Yet, it's not as simple as 'user, Karen, starts at step 1 and moves to step 2'. We do our best, but visualising people entering and reentering the service at different points is hard and doesn't do the messiness of the process any good.
('But, Nate, that's the point! We're trying to make it less messy for users!' Yeah, good luck with that, spend more time with people. Our job is to make the complex simple, but we can't smooth it out completely. It's just against nature, and that's a hill I will die on).
The closest analogy that feels right to me is like a 'choose your adventure' that Dominic Campbell pointed out in reply to my tweet. (For what it’s worth I agree Dominics views on maps).
I want to attempt a 'choose your own adventure' mapping session of a service. I imagine it would have to be a relatively high-level map as there would be many paths to choose from and adding the intricacies of systems, actors, any data and insight you might have might make it pretty big.
I know of a few designers experimenting with various mapping methods (if you are, get in touch, I like to try anything once!). But one that caught my eye from last weeks twitter chat was Zenko mapping. Zenko leaves out time, suggesting that things don't need to be done in a specific order (h/t @jonathanDholden).
Sidebar: In the video describing Zenko, I particularly enjoyed John's quote 'Don't work in models that pretend it is easy; work in models that allow you to do next right thing.'
'Thanks, Nate, great read' </sarcasm>
Yes, you've probably got this far and thought that. I have been going over it in my head all week, tying myself in knots thinking about time and maps. But it doesn't matter. What matters as a service designer—the anthropological investigator—is that you adapt to your surroundings and use the tools you have at your disposal to get the right outcomes. That's why we should always hunt for new tools and ways to express the system. Of course, this comes with a warning: obsessing over tools is a fool's errand; they should never come before the team or the user or any other person in the process of understanding.
There we are. An indulgent ramble this week. I have a lot to say on maps, most likely wrong, but I enjoy looking at ways to frame thinking and understand the whole. What are your favourite mapping thoughts?