Service blueprinting

The What, When, Why & How.

Image for post
Image for post

Co-written by Bart Coppens

Nowadays service design is one of the most important things when it comes to creating the ultimate customer experience. As many have basically put it; “the customer experience is the sum of all experiences a (potential) customer has during his interactions with a brand, across all touch points, online and offline.” So it’s no longer just the product itself that matters.

We, as interaction designers at Mirabeau, are the ones that design these interactions and unpack it to expose how the organisation can support this experience, which we like to do with service blueprints.

What are service blueprints?

  1. The need from a user perspective: What does the user need? Basically the user story.
  2. Touch point with the user: A rough sketch of what the basic solution will be like and what channel is used for the touch point?
  3. Notes/concerns: Are there any notes/concerns for this step, e.g. unhappy flows?
  4. Input/output: Which user input is required and which system output?
  5. Backoffice processes: Which systems or services are needed? Both online and offline.
  6. Opportunities (optional): Which KPI’s does the user story support? And what opportunities are there?

When do we use service blueprints?

Designing a new service: To help understand what has to be designed.

Improving a service: To understand the original service and identify pain points and opportunities.

Image for post
Image for post
For APG we designed blueprints for 33 modules that together form their new customer portal. Read more here.

At Mirabeau we work in an agile way to have a more creative and flexible way of working. But we have used service blueprints too for more classic ‘waterfall’ projects. More recently, working in dual-track scrum-projects where there is a discovery track and separate development track for each sprint, service blueprints have proved their added value in various phases of a project:

In the get ready phase: Having a get ready phase is a must in every project in order to do research and arrange workshops with both the client and users to gain insights on their needs and requirements. These can be processed and clustered into epics which leads to a service map. This is basically an outline of the service blueprints and thus the scale of the project. And helps with prioritising on an epic level and a milestone planning.

During ‘sprint 0’: Here is where the first service blueprints really start taking shape. The user stories are finalised, their touch points sketched, notes & concerns collected, etc. All in collaboration with stakeholders and sanity checked with the development team (e.g. do we have the data or can we process this). It is most efficient when service blueprints are ready for the upcoming sprint. This means the interaction designer works ahead of the team. Finalised user stories are the input for the backlog to later be picked up in the discovery and development tracks.

When doing a sprint review: The blueprints here serve as an already refined user story. Preventing questions popping up that can’t be answered on the spot and thereby allowing for a very effective sprint review.

During planning sessions: The blueprints here help to make a better planning-estimation. Ruling out assumptions and unknowns, as little should be left to the imagination of the team.

During the discovery tracks: The user stories form the perfect method of communication between all team members in the discovery track (e.g. interaction designers, visual designers, front-end developers and software architects. Also, with no unknowns, the team can focus on designing the ultimate solution to the user needs instead of a stop and go process when unanswered questions cause for impediments.

During the development tracks: As with the discovery track, taking away unknowns helps the efficiency of the team. Basically the team doesn’t have to worry about what should be developed and how it should work, or even if it is feasible. Their main concern should only be; what’s the best and most effective way to develop this.

Other benefits of service blueprints

Prioritising: Within the blueprints, the user stories can be more easily prioritized by a product owner (e.g. using MOSCOW). This because the blueprints clearly show relationships or even dependencies between the stories.

Flexibility: The blueprints are updated throughout the whole scrumproject: stories can be added, removed, changed and there is room for feedback.

Image for post
Image for post
A snapshot of a service blueprint about the journey of a house hunter for Vestide. Read more here.

Service blueprints are not…

Yes, wireframes are out the window (insert loud cheer here!). But other deliverables can still have a lot of added value. During a Get Ready phase these can be an Experience Map, a Value Proposition Canvas or Affinity Diagram for example.

It all depends on the project, the client and/or the team. Like Priority Guides, which can be created during the discovery tracks. These can add value within a less experienced team or a more content focused website. But with a more experienced visual designer and front-end developer service blueprints often take away the need for even these.

Conclusion

If you’ve got any questions or want to see how service blueprints can help, get in touch at Mirabeau , and let’s see how we can help.

Please clap if you enjoyed reading this article. If you have any questions or suggestions please add a comment below.

Written by

Medior UX researcher @ Mirabeau with a true passion for creating user-centred solutions.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store