In my experience, there are two things you need to consider when building a service map:
This week I will cover fidelity and, next week, resolution.
Fidelity depends on my audience, so I break fidelity down into two further pillars:
The first audience I need to consider is the team and me. After a series of interviews with people involved in the system, we usually build maps and collate any previous insight, data, and research.
During this process of service discovery, the map is scrappy. It's note form; it's on post-its (physical or virtual); it evolves over a discovery, and only the team understand what it says. We have created a shared language; we build a picture of the elephant that only we can see.
For anyone outside of the team, the map looks alienating and exclusive.
But that's ok, because right now, the team, the subject matter experts, and the users have created a shared language that allows us to move forward.
If the map is a tool for the team, it's ok to stay at this fidelity and stay a working map. Otherwise, there's going to have to be a point where we need to make it more accessible at some stage.
As far as I know, the term 'Show Pony' was first coined by Service Design Extraordinaire Rita Cervetto. It means to turn your shabby, post-it laden wall into something more comfortable to digest and, sometimes, easier on the eye.
By the time you are thinking about creating a Show Pony, you should have a clear idea of the opportunities and problem spaces. So the Pony will strip most of the other stuff out to focus on these areas.
The Show Pony sounds like extra work, and it is. But 'ponying' your map can have the following benefits:
Next week I will talk about resolution.
Of course, the above comes with the caveat that this is my personal opinion derived from my working experiences. I'm sure there are instances where some of this works for you, and other times it doesn't. Feel free to cherry-pick, adapt and change. Either way, let's carry on the conversation.