Service mapping in tech — a success story
I’m a Service Designer working in house at an amazing tech company. We are building a platform that will support more sustainable energy networks, globally. It’s a massive undertaking and following is the story of how service mapping became everyone’s best friend — instead of only mine, at Kaluza.
The beginning
It was September 2019. I must have been talking about service mapping, when this colleague tilted their head and asked after a long pause:
What did they ask you to do…when they hired you?
I wanted to get offended but it was such an insightful question. It left me thinking. I wrote this blog and set off to befriend other disciplines at Kaluza instead of trying to force Service Design onto them. I knew the organisation would benefit from service mapping in particular. All I needed to do was get others to know that too! Getting to know them first seemed like a good place to start.
The journey
In the 2 years after writing that blog, I’ve been:
- Working with as many people as possible to learn about what matters to them within Kaluza — so Service Maps can be relevant.
- Trying all types of service maps — so I know which maps are helpful.
- Documenting as I go — so I can show the journey and my learnings to others.
In this time, something awesome happened. Only the most valuable approach to service mapping remained relevant and re-used. Natural selection! The more I worked with leadership, product and engineering, the more we learned about each other and the more demand there suddenly was for mapping. It wouldn’t have happened this way though if I hadn’t had the support of a set of very experienced design, engineering and product leaders. Following are a couple of Slack screenshots I’ve saved:
Today
- We are a team of 5 Kaluza Service Designers working strategically, creating frameworks for others instead of service mapping backlogs for ourselves.
- Maps are in demand and being created by everyone in the organisation. Not only designers.
- I personally know why we map at Kaluza and how it will help us scale faster and be the best energy platform in the world. Sounds grandiose but the vision is clear to me now. As more people pick up mapping, the more time Service Designers can spend in speculative design and service design for our future clients and markets.
Let’s bring in some colleagues!
I thought it would be a good idea to intro people who have completely adopted and embedded service mapping in their workflow, so you can know learn about their point of view too. Meet Alex and Omar.
Alex Veale
Alex: Hey — I’m Alex, I’ve been a Product Manager at Kaluza for just over 2 years and was previously a Business Analyst — I love working with people to solve impactful problems to drive positive customer and business outcomes.
Omar Sheikh
Omar: Howdy! I’m Omar Sheikh. I joined Kaluza this summer as Product Manager. I’m new to the energy industry. In my previous life I was Product Manager at a US Legal Tech company for 3+ years. I’m a believer that we always need to think about the “user” and ensure we have a design mapped out for each EPIC we ship. More UX → a more lovable product that “users” (B2B / B2B2C) want to use. TLDR — I’m a PM. I love UX. I am trying to incorporate design in our product development process.
Question: Why did service maps catch your attention?
Alex: I’ve always had an interest in UX and the importance of understanding the user’s experience of interacting with a product but I also love getting into the weeds with the lower level technical details. When Rita introduced us at Kaluza to Service Mapping I found it to be the perfect tool to connect the dots and tell the whole story of the users and their interactions with the product down to the API and service level with the concepts of “front stage” and “backstage” and the related “actors” really resonating. When I started (pre-COVID) we had a huge physical map in the office that we would gather round weekly and build up, since then we’ve moved to Miro which also works great.
Omar: Whether you’re polishing off a widget which end-users enter meter readings into or building out a new micro service, there is always design involved. Service Maps serve as an awesome tool to visualise our product areas and discover new opportunities. They shed light on Ops / end-user touch points, the interaction between backend services as well as cross-team dependencies.
Some of the conversation’s I’ve had:
“Now that we’re fleshing out our Service Maps, it looks like we send out a lot of comms. I’ll map out a wireflow showing them as screengrabs”.
[a few days later the team reviews the wireflow together] “We need to adjust copy which mentions our internal processes so the customer is aware.”
“This part of the maps shows a single point of failure too. Could we implement micro services from these other 3 sources?[the team make a note of this on the Service Map and incorporate this as part of the future state planning ]
How have you incorporated service maps into your workflow?
Alex: I’ve used service maps both to understand the current state of the world and how things currently work as well as envisioning how we may be able to solve new problems by starting with a map and identifying the areas of contention/change. I find that service mapping helps visualise the end to end solution and all interaction points and help create shared understanding and identify any sticky points.
Omar: Every Tuesday at 4–5pm I meet with our on-call engineer on Service Maps. We challenge each other asking questions along lines of:
- Can we simplify how we’re showing the steps involved in this process?
- Is this the best way to describe the process?
- Is this standard terminology?
- Can we group items together?
- Does the “notes” section have enough info on industry processes?
Session by session we’ve managed to run through all of our existing maps and we’re now cracking “easter eggs” (actual icon on our maps) and fleshing out unhappy paths.
The beauty of these sessions is that engineers rotate weekly. Some are more or less interested in the end user, others are gurus on industry processes and terminology. This means we’ve been able to add multiple layers to our maps depending on their mindset.
We are planning to transition these product manager/ engineer sessions into drop in sessions next year. This will help encourage more conversations with a wider audience, helping us discover additional opportunities and ultimately build a (more) lovable product.
What are product leaders who don’t use service mapping missing out on?
Alex: I think service mapping is a crucial skill to have on your product management tool-belt. Visualising the end to end flow of a service — connecting the “front stage” and “back stage” activities in a single view. This can expedite your problem solving process and bring your team along on that journey plus creating a living artefact that you can refer back to or iterate on.
Omar: Kaluza is going international. It’s key we understand how our product areas work so we can understand the gaps we need to fill to meet the global demand for our platform, servicing existing and new deals. Service Maps are a key tool in showing “how it works”. Let’s keep pushing to incorporate maps as part of the product development process as we have so far.
I want to think that one of my fellow Service Designers at Kaluza will eventually write another follow up blog and link back to this one. Tracing back our exciting journey to day one. Looking at you Ann, Agathe and Flori! Big thanks to Omar and Alex for letting me interview them — and Mark for letting me post a picture of the back of his head. Ha.
As always, reach out and say hello on twitter, linkedin or direct with thoughts, questions or feedback.
Thanks!
