I write this post with a conflicted heart. The post is ostensibly about language. And making sense – which simultaneously is precisely what this blog is for me; a record of my thinking, and thoughts in progress. But, I’ve just read Nick Marsh’s post on service design is dead, and while I don’t agree necessarily I do see his point. And do kinda sorta agree with the sentiment.
Sometimes I think being a designer is like being an artist in the early part of the 20th century when they became conscious of their isms – dada-, cub-, futur-, favue, orph- express-, et al. And I find myself *heavy sigh* a little bored of considering my point of view of “[insert term] design”. This may well be my last technique-based post for some time as I think I’d just like to do some doing and post about it, or post about some info-pretty.
But before then – this little bugbear has bugged me unbearably for sometime and started with the question “Is it a pathway or a journey map?” So in order to get some semblance of ‘just right’ in my mind I present the following musing to concluding.
Let the musing begin….
To wit: maps / pathways / user pathways / journeys / journey maps / experience map / service blueprints* / service models / service maps
So, all the pretty names, but what are these things essentially?
Tangible and visual means of showing:
1) How the service is experienced (outside-in)
2) How the service works (inside-out)
Why do you do these things as a designer?
To help business understand how the service – intangible in nature – works in a tangible way and how ultimately change can happen that supports customer/consumer/citizen experience and doesn’t make the customer/consumer/citizen hate the business for making their lives more difficult leading to distrust, ultimately making future change difficult. Simplistic but I refer you to para two and this post.
Service Design diagrams are the same as a LOVEM for an architect, and a BPMN for a business analyst. Relevant, useful and tools of our trade. Disclaimer: I know Architects and BAs do many more types of representational information.
Are Maps/Models/Pathways all different?
Except for the separation of outside-in to inside-out, I think no.
I was going to capture some definitions – but there are plenty out there and I do like Service Design Tools, or the definitions in this site (I did work pretty hard over four years to determine and ratify them).
To be literal, this is a map: This is a journey or pathway through:
The map has all the details of the experience – it’s signposted, it features the surrounds. The pathway or journey is the route through the map. The map shows the system in action in which all customers/users act, the pathway shows the customer with a particular goal’s route through the system.
I am therefore saying that a journey map shows the system in action for a particular experience of a customer/user. A map on its own shows only the system in action.
Furthermore, I think I’m saying this:
- Want to show the service system and how users interact with it? It’s a map (experience, journey, whatever) and a pathway is an inherent component (otherwise it’s just a system diagrammatic) – in fact, the journey/pathway gives context to the map
- Want to show how the service works from an inside-out perspective? Service blueprint, baby. And don’t mess it up with experiential information.
And now for some definitive-ish concluding:
- Maps are a suitably broad description for the visual means of illustrating a service system. As a map they should be appropriately signposted and show the relationships between time, space and objects. Ref: I Heart Frameworks for where maps come from.
- Pathways/Journeys are routes through the service system. As a navigational course intended by a human to achieve a goal the ‘journey’ needs to show the think | do | use elements of experience: motivators, expectations, perceptions, beliefs, and particular tools, interactions, etc of the particular journey-maker (i.e. different users have different journeys)
- Maps and pathways/journeys should always go together because they provide the ‘so what’ context to the ‘this is what actually happens’ revelation.
- A separate tool – a blueprint is my preference – needs to illustrate how the non-experiential elements of a service work from the business perspective.
So, “Is it a pathway or a journey map?” I’ll go with ‘Journey Map’, and I’m comfortable in saying it can look like this. Does that mean I’ll rename the example post ‘Customer Journey Maps’? No, but I’ll add a link to this post.
Thanks for reading. Comments welcome.
Related Posts:
*I have discovered in Australia (or maybe just Canberra (or maybe just the public sector in Canberra)) Service Blueprint means a full spec of user experience and user requirements. However, to me a service blueprint is the single schematic a la the Shostack originated version and this post.