Note: I jump straight into the mid-point of our design process in this article. If you didn’t read the first part, don’t worry; you can find it here!
In this article — the second in a series where I share the design processes my team and I followed to design and develop a product concept — I want to take a look at a relatively new discovery tool; Service Blueprinting. My aim in using this process was to help the team explore a product we had previously designed, familiarise ourselves with the existing customer experience, and give some grounding to drive the experience, design, and development forward.
Service Blueprinting provides a deep dive into specific customer journeys. You can use it to uncover, at a granular level, details that might affect the flow of the user’s experience, the impact of your technology, and critical moments that could break the journey entirely.
“A service blueprint gets you an end-to-end, holistic view of your service and how it’s delivered. It is a tool for gaining team alignment and getting stakeholders on the same page in their understanding of the service…”
I wanted to use the Service Blueprinting process to help us identify where we could really optimise our product journey. We had originally designed something that was both comprehensive and very complex from a UX and technical perspective; there was a need to iterate on the design to create something more user focussed, more usable, and more in line with new areas of product real estate we had grown into.
Preparing to ‘print…
Preparing for the blueprint session was reasonably swift; it took a couple of hours to complete the pre-work that needed to happen to make the session a success. I already knew the ‘opportunity space’ (Blueprint syntax for the area of the product or service you are exploring) and, since mapping the core user journey on the whiteboard was already complete, subsequence scenarios (Blueprint syntax for the user journey you’re looking at) came together quickly.
The nature of service blueprinting means that you approach each scenario with relative granularity; this makes mapping the entire product journey in one blueprint unfeasible. The scenarios you map would generally be your end to end process broken apart; this is, at least, how it worked for us. We had some additional ‘unhappy paths’ which complemented the primary scenarios we knew we needed to look at; these additional paths were not cornerstones for the user completing their journey but were definitely more than outliers or edge cases.
After summarising the opportunity space and scenarios, I create digital canvases in Excel on which we could create our blueprints. The canvas is a simple layout with areas for each layer of the blueprint plus space to mark individual phases in the scenarios. I had considered running the activity as an offline, tactile process but given our core scenario was 17 steps (that we knew of) and we only had a 2 hour window when everyone was available, it felt more conducive to work digitally and complete the spreadsheet on the fly.
The last piece of preparation was to book a venue with enough space to accommodate the participants. As Jim Morrison said “If you book them, they will come.”
For a blueprinting session you need participants. These can be anyone who has a vested interest in the thing you are designing, key stakeholders, people from any area of your business.
For our session, I had invited:
- Our Product Owner/BA who acted as our primary SME. He knew the requirements and fundamental goals for this product.
- Our front-end developer and designer since they were both well versed in this product and had worked on it the first time around.
- Our back-end developers some of whom had worked on the product or had awareness of it and one of whom was entirely new to the product but now had to work on the new new iteration.
I acted as facilitator and scribe for the session although I had designed the first iteration of the product and knew it well. I aimed to input where necessary but not guide the team too much; I wanted them to be able to add to the blueprint to help boost their own investment and the shared understanding of the product.
To start the session, I introduced the blueprinting process and explained the outcomes that I wanted to achieve. A couple of the participants had previously walked through the core journey with me but for clarity we took a sweeping overview of all of the scenarios we would need to cover to really dig into this product.
Note: Megan and Erik have produced some fantastic documentation on how to facilitate a blueprint session which I followed closely since this was the first session I had done with this many people and working on live product.
We stepped into our core journey and began the blueprinting. We took the time over each step to identify details for each layer — or as many as were included — and to carefully document any questions, critical moments, and opportunities that might have come to light.
The blueprint allows you to capture the following detail for each step of your scenario:
- Phase Summary: This details the ‘phases’ into which your scenario has been split. It is helpful to detail individual micro-journeys within your longer single scenario.
- Scenario Step: A step in the scenario which the user sees / interacts with.
- Hidden Scenario Step: A step in the scenario which progresses the journey but is invisible to the user (Eg. A back-end service).
- Touchpoint: The thing with which the user interacts (Eg. An email).
- Actor: The user(s) involved in the current step.
- System: Technologies and services that run the current step.
- Policy Information: Any rules or regulations which might impact the current step.
- Metrics: Any KPIs or measures which affect the current step or could be generated by the user at this point.
- Questions: Questions about the current step.
- Critical Moment: A moment in the scenario that could cause the journey to break down entirely for the user; these are the dealbreakers. It is really important to capture your ‘Critical Moments’, even as ‘What if…’ notes.
- Opportunity: Chances to remedy the ‘Critical Moments’ and improve the user’s experience as it currently stands.
During the session there were questions about step variations and alternative routes through our scenario. For the purpose of this blueprint, we kept our focus on the core scenario and made sure to document the questions for each step and make note of any additional scenarios that we might want to explore in the future. Even if there is deviation in a small number of steps, it is worth taking the time to document an entirely new scenario.
Blueprinting our 17-step core scenario, surface to core, took little over 1h 15m which was quicker than I had anticipated. We didn’t look to add any more scenarios since time was scarce and the cognitive impact of working through more detailed scenarios was a little too much for the all of us at that point!
After the session, we knew we had to have at least one more gathering to work through some more fundamental scenarios which would help us complete our product journey. The second time the team gathered the process was quicker — we mapped two shorter scenarios in little over an hour. We found that there were a number of shared steps between each which took away the need to redo a lot of our work from the previous session.
Once the additional scenarios had been blueprinted, we had a firm ‘happy path’ through the majority of our product which gave the team plenty of scope to approach the impending redesign. Using the details — the questions, the critical moments, the opportunities — we were able to identify areas of the product we knew were a risk the first time around and pull out key areas where we knew improvement was possible. In Service Blueprinting parlance, this is the ‘synthesis’ step of the process.
Considering the benefits of Service Blueprinting, the team now had a strong shared understanding of the critical points that needed to be hit when we eventually worked on the redesign; everyone knew the journey and had a view of the same story. They were happy with the process and the outcome, and found the time spent collaborating on the product outside of pixels and code valuable.
I complete this course on Service Blueprinting which proved to be really valuable; it goes into much more detail that the free resources and is well worth the money!
The Practical Service Design site is also loaded with great information, plus has links to access the popular, highly active Slack community.
In the final article in this series, I am going to look at how we used the findings from our Service Blueprinting session to inform our approach to redesigning our product and how we approach ideation and fast prototyping to get us ready for development.