(Paul is a Service Designer at E.ON. This is from his 1/25/17 post on practicalservicedesign.com, link here.)
Paul finds that cross-functional product teams can sometimes be slow to make progress, so he relies on service blueprinting to speed up the process
Service blueprints are a way of laying out the customer journey as folks explore, purchase and use a product or service
Paul uses this format for blueprinting:
- 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 format:
- Enables people to focus on their specific concerns within the context of the whole experience
- Makes it easy to demonstrate where and when other depts may need to provide support
- Demonstrates the overall customer experience to senior stakeholders while allowing them to explore any levels of detail they choose
Get started with a lo-fi version
- Begin with a post-it exercise to map touchpoint. Shouldn’t take more than 90 minutes. Transfer journey into an Excel doc
- Next discuss details with SMEs in workshops. Give yourself 1-2 weeks to complete the discussions and populate the Excel blueprint with the details you documented
- I like Excel since most stakeholders have and use it—design tools shouldn’t be accessible only by designers, we want everyone to be able to access and update the information. Share a link to the doc and encourage participation (within guidelines of course)!
- If necessary, create a high-fi version in a graphics program. But why is this necessary? If you don’t know why you need it, you probably don’t. (Though I imagine a one group that might benefit is your UX team, since designers tend to be allergic to data tables)
- Eric Flowers created a great template: copy-of-service-blueprint-template
This framework forces the group to directly address issues, documents and processes involved, who’s going to manage what etc. It will also become obvious if there isn’t enough clarity in what you’re trying to do
Try adding the mapping exercise to the project kick-off meeting—create alignment from the start to avoid divergent views later in the process. You won’t have all the information you need yet—use this as a way to define what’s missing and how to get it
Here is Paul’s visual:
About Paul (from his post):
Paul Moran
Service Designer at E.ON, interested in service design, design sprints, customer experience, UX
