Notes on Paul Moran’s Speed up Your Team with a Service Blueprint

(Paul is a Service Designer at E.ON. This is from his 1/25/17 post on, 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)

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




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s