Speed up your team with a service blueprint
I’ve been working with a number of cross-functional product teams over the last year, and I’ve found there are a number of challenges which make progress slower than it could be.
In my recent experience, the service blueprint can help speed teams up.
I want to talk detail vs. I want to talk strategy
One of the main issues has been how to manage discussions which involve the whole team. Having a cross-functional team is great for making faster progress in general because team members get exposed to different perspectives and can discuss them in the moment. But a team with many different perspectives on an issue can also get bogged down in lengthy discussions without a framework to effectively navigate them.
I’ve observed teams trying to work through particular challenges but find it difficult to make progress because someone wants to talk about issues that are right in the details, while others want to establish high-level frameworks. Subject experts have different focuses, and this can lead to plenty of frustration despite everyone’s best intentions.
Service blueprint = end to end customer journey + detail
As a service designer my role as part of these teams has been to help them develop a consideration for customer experiences with their products. One of the tools which I’ve found most useful to facilitate this has been the service blueprint.
The service blueprint is a simple way of laying out the journey a customer takes as they become aware of, explore, purchase and use your product or service. The format I’ve been using is an easy to lay out framework which includes the following:
- High level section of the customer journey – awareness, exploration, purchase, usage, problems etc
- Touchpoints – a description of what’s happening written from the customer’s perspective
- Performers – who is involved in this touchpoint (who is involved from the customer’s business, from our business, from 3rd parties)?
- Front stage – what happens in this touchpoint that is visible to the customer?
- Back stage – what happens in this touchpoint that the customer doesn’t see?
- Enablers – what are the systems, documents and processes which make this touchpoint work?
- Measures – what do we want to learn at this touchpoint and what’s a suitable measure?
- Questions – what outstanding questions do we have about this touchpoint that need to be resolved?
This framework enables the team to discuss most of the things they eventually need to discuss, and its simple structure provides a way to manage the discussion effectively.
It’s also a great tool for stakeholder engagement because it enables people to focus their specific questions in the context of the whole experience. It makes it easy to demonstrate to other departments who may need to provide support to your project exactly where and how they have an impact on the customer experience. It’s also useful for demonstrating the overall experience to senior stakeholders and helping them understand both the big picture (the end to end experience) and any level of detail they want to explore (the touchpoints and the detail supporting each one).
Get moving with a lo-fi version
It’s easy to get started with a post-it exercise to map the touchpoints. From here it becomes a process of discussing detail with the subject matter experts across a number of workshops. It can be done at a really quick pace — a current project mapped the initial journey in about 90 minutes and in less than 2 weeks we’ve populated much of the rest of the content. I’ve now got an excel version which is easy to update and share, and is good enough to keep the team moving. At some point I’ll be producing something more hi-fidelity in InDesign to support wider communication. I’m still learning the appropriate point to move to a higher fidelity output, and am currently experimenting with staying lo-fi longer as long as it keeps us moving.
As we’ve been populating the blueprint it’s become obvious that this tool is helping the team move faster. Having a framework like this forces you to address issues directly — e.g. exactly how will the customer pay for this? What documents will be involved, what payment process needs to be in place and who will manage it? It becomes obvious very early if you don’t have clarity, which means you can take steps to get answers earlier than you might otherwise have done.
Do it early
In this current project we did the initial mapping exercise in our first full team meeting, which is the earliest I’ve done it with a team. The result has been brilliant — it’s got us all aligned and focused on the same version of the customer journey we want to build rather than finding out later–and closer to the launch deadline–that people have got divergent views. It means that the delivery team is aligned with the proposition team, and that the finance team have got a head start on building the business case.
Connect it with other tools
We’ve also been using tools like the value proposition and business model canvases which both help to describe how the proposition itself works for both the customer and the organisation. The service blueprint helps describe exactly how the customer will experience the proposition.
Joining these tools together allows you to tell a coherent story of your product or service.
The level of detail contained in the service blueprint also allows you to connect with other parts of your product development process such as business readiness planning. A complete service blueprint will show you exactly when and where resources need to be deployed to deliver the customer experience you’ve designed. I’m looking forward to rapidly moving into this phase with my current project.
I hope you’ve enjoyed reading my experience of using this tool. I’m interested to hear other people’s experiences of using this framework (or variations of it). How have you seen it add value? How could it be amended to be even more useful? Please let me know in the comments 🙂
Mid 2018 update: More about service blueprints in my new post:
