Hacking Service Blueprints
Ways of Seeing what Service Blueprints risk Concealing
To many — if I can be risk being rude, to many non-designers, people who have become ‘service designers’ after only a short course — Service Design means producing a Service Design Blueprint. Using a tool you do not understand the limits of, can be very limiting of your practice; and in Service Design, this means consequences for those people whose daily work will involve performing that Service Design.
So what follows is a quick summary of what Service Design Blueprints can cause you to miss when (co-)designing a service. The summary point is that Service Design Blueprints are useful only if you hack them and supplement them. Most Service Designers of any worth know all of this. And quality training in Service Design, even in some short courses, does cover most of these points. I intend this to be directed more at people new to Service Designing.
Apologies that this is a hasty, disconnected set of points.
Origin of Service Design Blueprints
Customer Journey + Value Stream Analysis
One of the first mentions of design in relation to services was by Lynn Shostack in the early 1980s. Shostack’s concern was how the marketing of services needed to be very different from the selling of products. A 1982 academic article, summarized into a more widely accessed 1984 Harvard Business Review piece, “Designing Services that Deliver,” begins with the complaint that services are often poor quality because they have not been well-designed, arising from piece-meal trial-and-error or process-flow diagrams that focus only on the business’ systems and not on the customer experience. Shostack proposed adding a customer journey side to those process-flow diagrams to create a visual tool for planning the whole of the service experience.
Service Blueprints were valuable, argued Shostack, in two ways. The first was that they enabled designers to anticipate service failures and so plan for service recovery. This is interesting because most subsequent Service Blueprints produced these days are entirely linear, representing the one idealised service, without any branching or doubling back. I will return to this below.
The second importance of Service Blueprints was that they allowed designers to make the services more ‘logical,’ by which Shostack meant, more efficient. This means that Service Blueprints were originally designed to function more like Value Stream Maps in the Lean Manufacturing context, where each moment included on the decided-upon process must not only be necessary — avoid waste — but must generate value. In the HBR article, Shostack demonstrates how iterations of a Service Blueprint allow you to decide whether, and if so how much, you could charge more by adding to the service of shoe shining a second coat of shoe shine.
Service Blueprints have been developed beyond Shostack’s initial examples, but it is always worth wondering how much the context behind the design of a tool remains in the tool, designing how designing with that tool happens. Designers of services often believe that the Customer Journey side means that Service Blueprints are good for humanizing a customer’s experience of a service, but Blueprinting (in the architectural detail specification sense) a service does not seem on reflection like a good way to humanize anything, especially the experience of the service provider.
Service Designers worthy of the name know that Service Blueprints are an early stage working tool and should never be the basis of a communication to clients about the Service Experience Concept. However, some less careful service designers are tempted to include Blueprints in project documentation handover. Knowing that they will look to a business manager like something that can be used to not only instruct service workers — do this, and only this, and then, and only then, do that — but also evaluate, and so discipline, workers — you did not do it right, you failed to generate value so are a source of waste — should mean being wary of such unqualified handovers.
A final point on this. Shostack, in the early 1980s in North America, introduces Service Blueprinting as the core of this new practice of Service Design, with the example of a shoe shine service. Yoko Akama drew my attention to the fact that this is not a neutral choice of example. Apart from the racial politics involved, the example works on the assumption that this must be a business that needs service design, that such a service worker is not a skilled craftsperson ensuring quality in all they do, and/or is not a scrupulous businessperson avoiding waste and maximizing value creation. Shostack’s articles did not just found a new practice, but also recast a wide range of practices as designable, as needing to be redesigned on a revenue-per-customer-interaction basis. What interactions between people cannot, or perhaps should not, be translated into a Service Blueprint?
Line of Visibility I
Hiding Labor
A defining element of the Service Blueprint, what differentiates it from a Customer Journey Map, is the ‘Line of Visibility.’ This straight line divides Blueprint canvases into a top part representing the ‘front-stage’ in which the service recipient interacts with the service system’s touchpoints, which includes the ‘front-line’ customer service worker, from the ‘back office’ operations.
The Line of Visibility seems natural, but designers should always question such assumptions. Why do aspects of the service need to be concealed beneath a Line of Visibility? An answer is sometimes, because the customer is focused on getting the service accomplished, so does not want to be distracted or confused by all the stuff that is the service deliverer’s business. Concealing as much as possible of the service from the customer is supposed to give them a ‘cleaner’ experience, one that can even delight by appearing magical because the service is delivered without any visible effort by the organisation involved.
Things below the line fall, at best if digitizable, under the purview of the blackboxes that dev-ops build and maintain. In practice, non-digitizable things, and people, below the Line tend to fall back into ‘business process management’ rather than being activities available for designers to help improve. The service work and workers behind the Line of Visibility, who are in fact essential to the creation of value, do not then get the same ‘humanizing’ attention paid to their experience. Things can be messy, effortful and even oppressive because customers are not seeing them.
Building trust in a service — which is essential given that a service is ‘the coordination of promises’ that requires service recipients to play their part helpfully in the co-creation of value — often requires customers having some ability to see into the back-office. Customers can be more willing participants in a service when they can see that things are proceeding despite there being, for example, some delay. For this reason, the Line of Visibility should not be a straight line; it should drop down at stages of the service experience to indicate when the customer can see what is happening. Or rather, the Line of Visibility could be perforated to suggest that the customer can see into processes that they nevertheless are not directly interacting with.
Line of Visibility II
What Service Workers can See
The Line of Visibility is a division between what customers see of the service and the rest of what is involved in the delivery of the service. As indicated, the origin of Service Blueprints claimed to foreground the customer’s experience, and so what the customer sees of the service. But the delivery of a quality service also depends on what the service workers can see.
On the one hand, this means that there are things that those contributing to the performance of the service but not necessarily interacting with customers need to be able to see concerning the customers. A Service Blueprint might indicate this as digital information captured about the customer’s requests that gets sent over the Line of Visibility. However, more real-time information, especially if there are qualitative particulars about the customer that require customisation of the service process, might best be handled by those below Line being able to have a view of the ‘front stage’ at different moments in the service process.
Similarly, though a frontline service worker is above the Line of Visibility with the customer, they obviously need to be able to see across the Line in order to apprise the customer of where things are at, should there be a complication or delay. Without such an ability to see through the Line of Visibility, the frontline service worker can only ever respond with, ‘The computer says no.’
On the other hand, a multi-stage process with many components requires that service workers be able to see each other, so that they can coordinate their part in the realisation of the service. There might therefore need to be internal Lines of Visibility below the Line of Visibility — or rather, since the idea of concealing aspects of the service process within the business does not make sense (except as a power play), service designers can specify Sightlines, ensuring that a service worker can and will see another aspect of the service process if and when it is important to what they are doing.
Line of Visibility III
Seeing Ahead not just Into
Just as there might be Sightlines for the service workers above and below the Line of Visibility, so there might be Sightlines for the customer. Having the Line of Visibility as a strictly horizontal division focuses attention on what can be seen at any particular moment of the service, obscuring what people involved in the service might need to see about what is coming up or what has happened.
For example, how much of the overall service journey should be communicated to a customer at the beginning of a service? It might be beneficial for them to have a good sense of its stages and flow before commencing; though that might also be overwhelming and unlikely to be remembered. The notion of a Customer Journey, and the theatrical metaphors that dominate service designing, suggest limiting foresight. The whole point of a story is that it unfolds over time, with things happening that you do not anticipate. Should services have this kind of drama? Should the pathway of the service experience disappear ahead of youa around a corner or over a hill?
It is also likely that service providers need to be able see the history of a service’s delivery to help forward the service in ways that best suit the customer’s experience to date. Being able to track back is of great importance in services when a customer is being cared for by multiple people over a period of time. Handover documentation of a patient’s history for example, can be a matter of life and death in the case of nursing.
In either case, whatever it might be best for a customer or service provider to foresee or look back over, a Service Blueprint, with its columnal structure and horizontal Line of Visibility, does not help a service designer make these decisions. Other ways of zooming into moments of a service, and then looking around at what is and should be visible, are needed.
Swimlanes
Handover between different Cultures
One of the first, comprehensive designerly Service Design guidebooks — by Polaine, Løvlie and Reason — made the important point that that a Service Blueprint is an Org Chart turned 90°. The horizontal rows of a Service Design blueprint beneath the Line of Visibility are often cast as different departments of a service-providing organisation. The point of a Service Blueprint is to prioritise the experience of the customer rather than the structure of the organisation, which is why departments are flipped on their side and shown to be cooperating at each stage to deliver the service.
However, as any experienced service designer knows, you do not make the silos go away by lying them down beneath the all-important customer. A Service Blueprint risks drawing lines between activities in different rows that would suggest it is a straightforward thing for one action in the service by one department to trigger a simultaneous or consequent action in another. In reality, these flows or hand-overs between rows are exactly what needs to be designed. Businesses organise themselves into departments because one part of the business thinks and works one way, while another part of the business thinks and works in another. There can be culture clashes between departments for purely functional reasons, let alone those then being exploited for reasons of power.
A Service Blueprint is then less a place for the designing of the service and more a tool for seeing all the interactions, between customer and frontline service worker, as well as between all the back office departments, that need to be designed. The lines between actions on Service Blueprint are ‘jobs to be done,’ converted into micro-projects, each of which needs careful attention to issues of translation and confirmation across units with different workflows and priorities.
Visual Planning I
Deregulate to capture Timespaces
One definition of service is a time-based set of interactions. The unfolding over time is a key aspect of what is being designed, precisely why the Blueprint borrows the metaphor of the journey.
However, there is a temptation for Service Blueprints, especially when based on canvases or done by arranging postit notes on a wall, to have all the columns be of a regular size. This might look neat, making the early card sort of activities involved in the service feel like an accomplishment, but the aesthetic is deceptive, suggesting the service’s component activities tick over regularly like clockwork.
This risk can be tempered by categorizing the Service into key phases of the service experience. This is one of the values of Service Blueprinting, allowing those involved in the design to make decisions about the overall arc of the experience, ordering the ‘chapters’ of the customer journey. Ideally, chapters would not be of equal size to capture their importance, or more prosaically, how long they should take. However, the size of each phase in a Service Blueprint is usually determined more by the number of same-sized columnal activities involved in each phase, rather than any attempt to depict how long that phase should actually take in practice. A single activity might require a considerable period of time, whereas many activities might be able to be moved through quickly — distinctions that are not visible if columns are all the same size.
Good interaction designers also know that humans tend to group similar kinds of activities not only in the same time-period, but also the same kind of equipment-space. Gathering what is needed together to do something allows that practice to cohere in ways that lowers the cognitive load involved — or rather, frees up cognitive load so that those involved can concentrate on doing the practice well rather than chasing after this or that needed tool that is not at hand. A Service Blueprint should therefore register not just time-based ‘chapters’ of the experience, but also the different ‘places’ that it would be best for each experience to take place in — and this can mean distinct zones of a digital environment (at its crudest, ‘screen/pages’ of an app) as well as actual rooms interior designed to orient customers and service recipients to this phase of the service (i.e., servicescapes). Some Service Blueprints might signal distinct ‘places’ through horizontal ‘swimlanes,’ but it would be more useful if the ‘timespaces’ of each ‘practice’ involved in a service were captured as blocks that incorporated different parts of the service coming together for a common period of time. Forseeing when a service demands a change a place, and how to help people through those transitions, is also central to careful service designing.
Visual Planning II
Branch and Loop for Failure Recovery
As mentioned at the outset, one of the principal purposes of Service Blueprinting according to the process’ originator, was to anticipate service breakdowns. Most Service Blueprints however pride themselves on presenting a single experience, what is supposedly the ‘ideal’ way in which the service happens. While this might have its place, more valuable, at least in terms of risk management and quality assurance, is using Service Blueprints to imagine a wide variety of things that could happen over the course of the service. The aim should be to provide a visual guide to ways in which the service can get back to its ‘ideal’ journey given as many contingencies as the imagination of the designers and the experience of the service providers can come up with (this is a less sexy version of what could be called Speculative Critical Service Designing) — though the aim should not only be planning for failures, whether by customers or service providers, but also planning for a diversity of customers and so customisations of the service.
On this, one of the most important things to plan for is the late arrival of customers into the journey or their early departure. The customer journey aspect of a Service Blueprints is credited for helping clients realise that the experience of the customer extends beyond their direct engagement with the organisation. Service Blueprints get everyone involved in the service to see the columns, or chapters of columns, that occur before and after the service ‘proper’ but which nevertheless can determine the perceived success of the service. However, an unanticipated consequence of this tends to be restricting the service proper to the expectations that all customers have been successfully directed to approach the service through those particular pre-service activities and leave through the designed post-service activities. In reality, these are by definition harder to direct because customers’ lives are less easily designed than those of service workers. So, services should anticipate people coming to, and leaving, the service at different times and in different ways. In some cases, it might just be realising that a customer needs to be guided back to an earlier stage to complete what needs to done for the service to happen well; but in other cases, it might be possible to use Service Blueprinting to accommodate such variances.
Trying to put ‘if… then….’ branches and loops into rectilinear Service Blueprints does however tend to break their visual grammar. We have had some success by putting alternative pathways into overlays, as a third dimension, rather than trying to put alternatives onto the one 2D Blueprint (which leads to an unreadable sprawling gigamap).
Visual Planning III
Widening for Service Worker Journey
If one of the values of a Service Blueprint is that it helps you widen your sense of the timeframe involved in the service experience, it is problematic if that widening is applied only to the Customer Journey in the top half, and not the employees involved in delivering the Service, whether frontline service workers or in the back office. If the quality of the service arises from how the customer anticipates the service experience, and then journeys to the service location, as well as the activities the customer undertakes afterwards, the same is true for the service worker; their training, their commute, their planning for the day’s customers, their debriefing. This might just mean instrumental things like getting uniforms and equipment and servicescapes prepared, and then cleaned and stored afterwards. But if there is emotional labour involved in the service, such as is essential in any care work, it is important that service designer attend with just as much care to what is involved in the pre- and post-service experience of the service deliverer.
This means that a Service Blueprint should visually indicate that a service is the coming together of people, and that those people in either case go through a stage of changing from people in the world with a variety of skills, knowledge and values, into people who are ready to co-create a service together, and then people who go back to their separate lifeworlds. Someone becomes a customer, just as someone becomes an employee, each time the service happens. The latter is done more regularly, with more dedicated resources, so that transition from person to delegate of the servicing organisation can be more comprehensive but also faster and more (but never entirely) controlled.
As I hope I made clear at the beginning, these points are directed at people who tend to reduce Service Designing to producing a Service Blueprint. Well trained and experienced Service Designers have many tools and techniques for doing the things I have talked about, so will think that it was perhaps unwise for me to try to talk about all these things in relation to Service Blueprints. Or to put it the other way around, if you tried to produce Service Blueprints that did everything I have mentioned, you would no longer have something that looked like a Service Blueprint, though you might have started to actually do Service Designing.
