CHAPTER 5
Describing the Service Ecology
Boxes versus Arrows—Finding the Invisible Connections
From Ecology Map to Service Blueprint
Start with Broad Phases and Activities
Low Fidelity versus High Fidelity
As you start gathering insights and other background material for a project, you will need to structure this information in some way. In this chapter we discuss the role of the service blueprint, which helps you structure, design, and align touchpoint interactions as they unfold over time. First, though, it is sometimes necessary to gain a sense of the context in which the service is operating, which is usually complex. You can map this out in a service ecology—a diagram of all the actors affected by a service and the relationships between them, displayed in a systematic manner.
A service ecology can start off simple—for instance, as a map that shows how a customer might use a website in combination with a call center to solve a problem. At the other end of the scale, it is possible to map complex systems such as a public transportation system or a model for reducing unemployment.
The basic actors in a service ecology are the enterprises that make a promise to the customer (or service user), the agents who deliver that promise through different channels, and the customers who return value back to the enterprise (Figure 5.1).
From a branding point of view, the enterprise makes a promise to the service user and expects value in return, whether by payment, tax, or labor. For example, a mobile provider gives its customers airtime and data in return for payment. A city provides street lighting and clears away trash in return for taxes. An employee receives a salary in return for his or her labor. As a side note here, when we talk about “enterprise” and “branding,” this may be in either a commercial or a nonprofit/public service context.
FIGURE 5.1
A basic customer–enterprise service ecology. The enterprise makes a promise to its customers, which is delivered by its agents through different channels. The customers return value, usually in the form of money.
The enterprise itself does not deliver experiences and utility to people, however. These are provided by the agents who are in direct contact with users through channels and touchpoints. Channels are the overall medium, such as e-mail, telephone, and face-to-face, and a touchpoint is an individual moment of interaction within that channel, such as a single call or an e-mail exchange. So, a customer might interact with several touchpoints across a single channel or across many channels. The role of the enterprise is to deliver the tools and infrastructure that agents need to deliver a good service experience.
The point of using the metaphor of ecologies when describing services is not only that services often harbor a complexity that can be compared to systems in nature. Looking at services as ecologies also emphasizes the point that all of the actors in a service exchange some sort of value. When customers pay a bill online, they save the bank money and they enjoy the convenience of banking outside regular banking hours. When users navigate a simple Web page, they leave behind data that enable the provider to improve the site, and the users do not have to fill in a load of details again when they return. A healthy ecology is one in which everyone benefits, rather than having the value flow in one direction only.
The most common lost opportunity is when enterprises neglect the resource that customers can be in terms of providing value back to the service. Customers are usually motivated to provide labor, knowledge, and data if these will help them get a better result, and when customers invest in the outcome, they connect more strongly to the brand.
Enterprises can do far more to help customers return value to both themselves and other service users. In general, the relationship between service users and the enterprise is very one-sided. Taxpayers who submit their tax returns after the deadline can be fined, but the tax office may take months to complete their side of the deal with no penalty. If travelers turn up five minutes late to check in with a budget airline, they can expect to miss the flight or pay a hefty surcharge (and often receive less-than-charming responses from staff). Yet when a flight is late and travelers miss their connection, it is their own hard luck.
Failing to provide resources in the form of communication channels for this return of value from the service user to the enterprise is dangerous. The Internet has given people the ability to easily create their own forums to voice their views and experiences, completely outside of the enterprise and often negative in tone. During the period we have been writing this book, we have seen the rise of the Arab Spring and the Occupy Wall Street movements, for example, which are powerful examples of self-organized value communication channels. Organizations can panic and view these voices as a loss of command and control, or they can view them as valuable feedback and make use of it. After all, the main purpose of paying someone to do insights research is to find out about these views, beliefs, and motivations. It makes sense to build it into the service ecology from the start.
A more detailed model of the service relationship includes much more exchange (Figure 5.2). The promise to the customer is fulfilled when agents provide utility and experience to customers through activities across the various channels, known as “frontstage” in service design (see “The Service Blueprint” below). Customers return added value to the enterprise through cooperation, information, and feedback, along with payment for services.
FIGURE 5.2
A detailed model of the service relationship. Frontstage, the promise to the customer is fulfilled when agents provide utility and experience and customers return added value to the enterprise through cooperation, information, and feedback. Backstage, the agents need tools and infrastructure to deliver utility and a good experience to customers. These tools also provide feedback in the form of data, which can be used to monitor and improve the service.
On the enterprise side, agents need tools and infrastructure “backstage” to deliver the utility and experience to the customer. These tools also provide feedback in the form of data, which can be used to monitor and improve the service. All of these flows need to be designed to deliver a good service.
The final point about the service ecology metaphor is that just like in nature, the actors in a service constantly change and evolve. In fact, services like Amazon and eBay make frequent small changes to their interfaces based on customer data, and a service delivered by a human changes with every employee. This means services need to be designed with enough resilience to handle constant changes in the machinery. One of the reasons co-design and client involvement is so important throughout the process is because staff need to learn the tools so they can make minor adjustments without having to call in the service designers every time. Management need to give staff the responsibility and flexibility to make changes in response to their environment.
Why Map Service Ecologies?
The example in Figure 5.2 is very simple, but services can be very complex once you take in the context and all of the actors involved. Designing an entire ecosystem is impossible, so service ecology maps are particularly useful in the early phases of design projects. They give you a means to establish a shared overview of the space you wish to work within.
The service ecology map has three main purposes:
- To map service actors and stakeholders
- To investigate relationships that are part of or affect the service
- To generate new service concepts by reorganizing how actors work together
As an exercise, mapping a service ecology can be very effective in a client workshop as a means to broaden the project space. It helps people to think beyond their own business or organizational concerns and see how what they are doing fits into the wider context of people’s lives and society. At the same time, it is important not to fall in love with the mapping exercise itself. Service ecologies can grow infinitely large, and if you do not focus on the results you are looking for, you can end up having mapped the whole world and not know what to do with it. It is important to define the boundaries of the map so you do not continue on forever. Some of this scope is defined by the project’s strategic goals, budget, sphere of influence, and so on, but the boundaries will also become clearer as you do the mapping exercise.
Figure 5.3 maps the ecology of a potential car-sharing service for FIAT and deals with the scope of the project by visualizing a series of levels that enabled the design team to focus in and out on the essential relationships of the service. The center describes the relationship between the driver and the car, and then expands to passengers, other cars, other services, communities, and at the perimeter, the Earth. (See how easily you can end up there?) The map was designed using icons printed onto honeycomb-shaped cards that enabled the project participants to combine actors in different ways to produce service concepts. As an example, connecting a community to a car revealed the potential of a business model in which FIAT could get a town to pay for a shared car to provide more flexible transportation for its citizens. The hexagonal shape of the cards allowed more elements to connect with each other than is possible with standard rectangular cards, but a set of sticky notes on a whiteboard suffices most of the time.
FIGURE 5.3
A map of actors involved in or affected by a new car-sharing scheme. This map was created for FIAT’s Future Design Group as part of a project at Interaction Design Institute Ivrea in Italy.
Ultimately, the project led to design proposals ranging from a redesign of the car key to enable multiple users to share a car, to a concept for integrating the car’s computer with public transportation information so that car club members could hop in a passing car rather than wait for the bus (Figure 5.4).
FIGURE 5.4
A concept image for connecting shared cars with public transportation information.
The development of the service ecology map helped make connections between different services that would normally have been overlooked. And making some quick mock-ups of the concepts at this early stage helps people imagine what the service might look like in reality. It also helps people to start thinking about the details, such as the privacy issues raised by the system shown in Figure 5.4, or just what it might mean for many people to have keys to the same car. Making the experience and proposition tangible helps highlight these details. We discuss this in more detail in the experience prototyping section in Chapter 7.
The Network Society
Around 1970, when the authors of this book were born, the developed world was well on its way to shifting from industrial societies to networked societies. Since then, organizations have steadily broken down strict hierarchies and favored models in which units are smaller, more independent, and collaborative. At the same time, network technology has developed at accelerating speed. These two social and technological trends are not necessarily driven by the same causes, but they have powered each other to form radically new platforms of service delivery.1
The maturation of these platforms has served as the foundation for the emergence of service design as a coherent design discipline over the past 10 to 15 years. It is a discipline fundamentally driven by networks. It is why designers have come to work on complex transportation, banking, and healthcare systems, not simply customer services or individual products or touchpoints.
These systems present a different type of complexity than industrial products. Products require designers to deal with many moving parts, but services require us to design systems that adapt well to constantly changing parts. Networks, organizations, and technology evolve on a daily basis, but the service still needs to deliver a robust customer experience.
Whether you need a way to approach “multichannel experiences,” “Web 2.0,” or some other current trend, service design offers tools and models that enable you to design for complexity.
There is no shortage of disciplines engaged in the design of touchpoints. Graphic design, UX design, product design, interaction design, information architecture, and customer experience design are just a few in a long list. These fields are still essential and used in the process of delivering service touchpoints. But this fact begs the question, “Why are so many service experiences awful when parts of them are seemingly well designed?”
Boxes versus Arrows—Finding the Invisible Connections
The answer to why so many services are poorly designed lies in the lack of attention paid to the invisible elements of time and context, both of which are critical to the experience of a service.
Arrows and lines in organizational charts and process diagrams often represent time, context, and connections. The problem is that arrows and connecting lines are so ubiquitous in diagrams that they are ignored. It is much easier to focus design effort on the boxes because they represent tangible touchpoints—the website, the ticket machine, and so on—but most people forget to think about designing the experience of the arrows, which are the transitions from one touchpoint to the next. Yet these connections contain some of the most important elements of positive experiences because they signify movement in time and space. It is as if companies spend fortunes building gleaming towers and cities while the roads between them are muddy dirt tracks. But people spend a lot of time traveling those tracks.
Silos within organizations can prevent engaging and positive service experiences from happening, because the seemingly small cracks between the individual silo elements, such as the discrepancies between online and in-store offerings, can soon open up into experience crevasses.
This is especially true of services because they usually unfold over time. Unlike a product, which customers purchase once and may use over time, services are usually the process of a time-based experience. A hotel stay is made up of many different experiences across a number of channels, from a Web search to find a place to stay, to booking, to the chocolate on the pillow, to the checkout procedure. Air travel, or even just buying the ticket, is something that happens over time. Long-term services, such as healthcare, finance, and insurance, affect people throughout their lifetimes.
All experiences of a service are a result of interactions of some kind. Obvious interactions are various touchpoints such as objects, interfaces, and interpersonal interactions. Less obvious are interactions between previous experiences or beliefs. Think of people’s fear of the dentist due to childhood experiences, an entire country being written off as a tourist destination because of one bad meal in a dodgy hotel, or the complexity of human emotions displayed by patients, carers, and medical workers in a healthcare service.
Service experiences are also affected by the contexts of time and place, and the most amazing thing at the wrong time can be more of a service design failure than something average that is delivered at exactly the right moment. Think of a romantic dinner interrupted by the restaurant violinist blaring away while a couple is trying to have a quiet conversation, or a helpful nurse arriving with a delicious meal just after a loved one has died. Some of the best service experiences are like the ideal wine waiter—there when he is needed, but somehow invisible when he is not.
A critical aspect of designing services is understanding context, and this is where service design is different from what many designers understand as user-centered design approaches. Our experience of UX design and interaction design is that the processes tend to be focused on individual touchpoints, and those touchpoints are, more often than not, digital and on-screen. This is in no way a criticism of these disciplines—we all have experience in them and use their processes and methods as part of the service design palette. It is more an observation of the areas that UX design and interaction design commonly engage in.
As we mentioned in Chapter 2, services are often created in silos and experienced in bits. Getting some companies to move from management silos, in which the customer may not ever feature, to a customer-centered perspective is already a massive improvement. Such companies may even use a diagram that looks something like the one in Figure 2.3.
With this in mind, different disciplines and departments can feel comfortable that they understand and are taking care of the customer experience. The Web and mobile team can look at their touchpoints, design them well, take a strong UX approach, and argue their case, but are the silos really dissolved? Taking another look at Figure 2.3, we see that if the connections (the arrows connecting the channels) are ignored, the silos are still potentially there, but they are just arranged in a circle.
The key to a seamless service experience is taking care to understand the contexts in which users interact with touchpoints and services. A good—or, rather, bad—example are the train ticket machines in Germany. After a recent upgrade, the graphic design of the screens is much more pleasant, but the overall interaction flow is slower and therefore worse due to the extra animation and display overhead. In the context of a design studio, the flow makes some sense, but in the context of rushing for a train and needing to buy a ticket, it is a disaster. The other context is the business of the machines themselves, usually designed and maintained by third-party organizations. Even when it is clear to the designers and researchers that the ticket machines are a problem, the company supplying and maintaining those machines usually resists changes, citing IT support issues. The only thing the design team is allowed to change are the graphics; they are not even allowed to touch the layout.
Many companies have an online (essentially mail-order) offering as well as bricks-and-mortar stores. They may offer special online deals that are not available in their stores, and some stores are official stores whereas others are simply franchises or resellers, which is often the case in telecommunications and insurance. The customer, however, experiences these—or expects to experience them—as a coherent brand and does not understand or is frustrated by the discrepancies. Why can’t the store offer the online cell phone plan, for example? There are usually “good” business reasons why these differences exist—an online transaction is basically self-service and therefore cheaper for the company—but for the customer they are a series of small irritations that add up to a terrible overall experience of the service.
From Ecology Map to Service Blueprint
The service ecology map gives us the bird’s-eye view of the ecosystem a service exists within, and the insights research gives us the bottom-up view from the stakeholders. As Lavrans’s story illustrates (see sidebar on page 88), the real effort goes into aligning everything and mapping out the middle elements that will actually form the design work to create the seamless (we hope) service experience. If you turn the traditional management model of silos in Figure 2.1 by 90 degrees, you will see something interesting—the customer/user is at the top, the enterprise is at the bottom, and all of the channels of interaction are in between (Figure 5.5). This is the beginning of the service blueprint.
FIGURE 5.5
Turning the traditional silo model of an organization 90 degrees and looking at it from the point of view of the customer journey dramatically improves the opportunity to join up the bits and deliver a consistent customer experience.
The Service Blueprint
Connecting together all of the different touchpoints in a service experience, as well as aligning the needs and wishes of all of an organization’s stakeholders, can become very complex very quickly, which is where service blueprinting comes in.
G. Lynn Shostack pioneered the idea of a service blueprint and coined the term in the early 1980s while she was a vice president of Citibank in the United States.2 Shostack developed the service blueprint as a way to plan the cost and revenue associated with operating a service, and her early versions looked very much like flow diagrams (Figure 5.6).
The example in Figure 5.6 is a simple one of a shoeshine service, but it introduced two key elements: time in the form of the customer service experience, and the line of visibility, which is essentially everything that the customer sees. Actually, it is everything the customer experiences because bad smells or loud noises can just as easily sour a customer experience.
This line of visibility has since been augmented in other designers’ models by lines of “external interaction” (all the things the “customer” interacts with) and “internal interaction” (all the things that service providers interact with).
FIGURE 5.6
An early example of a service blueprint. From G. Lynn Shostack, “Designing Services That Deliver,” Harvard Business Review 62, no. 1 (1984): 133–39.
Shostack’s line of visibility has transmuted into the frontstage/backstage metaphor in which anything that the “customer” experiences is frontstage (on-stage would be more appropriate to the metaphor) and everything else that goes on behind the scenes to make that happen is backstage.
Orchestral or theatrical metaphors are now common in service design. Service designers may like the idea of comparing themselves to conductors or directors for obvious and egocentric reasons that are probably not very productive. However, the service as an orchestral or theatrical production is a valuable metaphor and an alternative to the traditional role of designers. Service is more performance than manufacture.
For example, the idea of a “set,” or the setting of a service, is important because it enables us to think about the context in which staff and users interact. It also reminds us that things must work well backstage for the performance to be successful.
In classic theater, the actors have clearly defined roles, and from the beginning their goals are clear. What adds drama is how the actors face obstacles and overcome hurdles. Both staff and customers have specific things they wish to achieve, as in the classic dramaturgy of roles, motivations, and goals. The experience is defined by how they help each other reach a happy ending.
Finally, theater has props, which in service design terms are the touchpoints. These are the physical elements people use during the narrative, and they are crucial to enabling the drama to take place.
A classic example is a hotel stay—guests do not often see the activities of the staff who clean and make up the rooms (backstage), just the results (frontstage). Often, this backstage activity is evidenced in some way by bringing it frontstage, such as the folded toilet paper tip in a hotel bathroom that indicates the room has been cleaned.
The theatrical metaphor does have its limitations. Real people cannot be scripted, and we all know that the unexpected is bound to happen when people deliver or use a service. Services do not have fixed times when they start and finish, users often fail to “read their lines,” and service providers are rarely in full control of their environments.
The most rewarding way to use the theatrical metaphor is to think about service as improvisational theater. If you provide users and staff with a good “stage” on which to interact, and give them well-defined roles, clear goals, and the necessary props, people are likely to make the most out of the situation and create great experiences together.
The stage metaphor can be a useful way of aligning organizational activities with the “customer” experience, but the reason why we have put customer in quotes is because services do not always follow a simple customer and serviceprovider construct. Another way to approach blueprints is to treat each person, or even each nonhuman actor (usually a computer), as a role and map out the interactions between them across the full range of touchpoints.
Over the years, service designers have developed the blueprint as a comprehensive tool for placing the customer and service stakeholders at the heart of service design and innovation projects. As service designers engage more deeply with their clients’ processes and help them sort out their delivery systems, service design becomes central to clients’ businesses and operations.
A service blueprint is a map of:
- The user journey—phase by phase, step by step
- The touchpoints—channel by channel, touchpoint by touchpoint
- The backstage processes—stakeholder by stakeholder, action by action
A typical service blueprint template might look like the one in Figure 5.7.
The good news is that a service blueprint is an extremely useful tool. Blueprints help to capture the big picture and interconnections, and are a way to plan out projects and relate service design decisions back to the original research insights. The blueprint is different from the service ecology in that it includes specific detail about the elements, experiences, and delivery within the service itself, whereas the service ecology diagrams the service at a much higher level and shows the entire service’s relationship to other services and the surrounding environment in which it operates.
FIGURE 5.7
A typical service blueprint template, with the phases of the customer journey along the top (here it’s Aware, Join, Use, Develop, Leave) and the various touchpoint channels in rows underneath, including the backstage activities at the bottom. A couple of touchpoints have been filled in as examples.
The bad news is that, unlike blueprints for engineering or architecture, there is no typical or “standard” service blueprint with commonly agreed terminology and visual language. Andy worked on a research project at the Hochschule Luzern that examined a range of blueprints, and the group found as many different flavors of the diagrams as there were organizations creating them.3 Even within a single company, blueprints change in terms of design and content, sometimes requiring additional channels or more or fewer phases depending on the project and its purpose (Figure 5.8).
FIGURE 5.8
An example of a service blueprint with many touchpoints filled in. The second phase has been extended to accommodate a number of more detailed steps.
The underlying principles, however, remain the same. Essentially, you are trying to map out the service ecology by tracking all the people involved in its usage and delivery across all the relevant channels of communication and interaction. And you are mapping out all of this as it unfolds over time and connecting it to the insights research.
Engaging with real people provides insight on all levels of a service proposition. Do people value the service and the brand? Are they irritated by details on the invoice? The challenge from a service perspective is to include insights across the system in one picture.
The project team must then align insights from backstage staff with customer needs and define where in the customer journey the experience breaks down or great opportunities exist. Where do channels and technologies play well together to produce value, and when do they run counter to each other? Finally, you will design or write the design specification for all of the touchpoints.
Different Uses of Blueprints
The service blueprint offers a framework to categorize and work systematically with insight in complex networks. This puts you in the position of making concrete arguments about the design of the service, ranging from how to restructure the proposition to fixing a single crucial detail in the system. It also lays the groundwork for generating ideas and designing solutions that work across the network of people, technologies, and processes. As such, blueprinting is both a process of analysis and a method for generating ideas. These two overlap, of course. You might analyze an existing service, find problems, and then generate new innovations, all of which requires multiple iterations of the blueprint.
Blueprints and storyboard sketches (more detailed explanations of touchpoints) are to service design what 3D sketches and wireframes are to product design and UX design. Just like an exploded view of an electric motor, a service blueprint provides an overview for everyone involved in the design and delivery to see how the bits of the service work as a whole. A blueprint helps to break down barriers between business units, and it reveals opportunities for joining up processes to create more seamless experiences.
Blueprints for Analysis of an Existing Service
In the past, when trying to test the quality of a service, we could not find one single method to measure quality in the way people experience it across touchpoints. The service blueprint maps how the service is constructed, connecting all the channels and touchpoints to the customer journey and the backstage processes that are required to deliver them. It gives service designers a platform to systematically test people’s different journeys through the system. You can track their path across time and touchpoints, and reveal where real value was created and where opportunities were wasted. This tells you not only what is wrong, but also how to fix it.
Sometimes a failure behind the scenes that happens early in a process may not come to the surface until much later in the customer experience. For example, a poorly designed piece of communication, especially from a backstage process such as billing, can lead to customer confusion and a high volume of calls to customer services.
This kind of blueprint-as-analysis is a useful tool to show clients the results of insights research and to highlight key areas where resources should be concentrated. In the Gjensidige project, for example, the design team discovered between 50 and 100 touchpoints that connected to the customer experience, depending on the customer’s situation. Feeding touchpoint insights into a blueprint gives us a basis from which to work so that we can improve a service. It also gives us an overview that helps us decide which touchpoints to focus on during prototyping. Ideally, we want to work on the touchpoints that have the greatest impact on the service experience, but we do not know how they will work or feel until we see people interacting with them (see Chapter 7 for more on prototyping).
Blueprints for Service Innovation
The other use of a blueprint is when innovating new services, either as a strategic shift in an existing organization or because a market opportunity for a completely new business has been spotted. It is easy to get excited about a new and innovative service idea when it seems simple and compelling in your head, but it is equally easy for your imagination to end up working in silos. You might envisage a wonderful retail experience, for example, but forget to think about all the backstage things that need to happen for that experience to be a success.
Mapping out all of the stages in a blueprint helps you develop a much more coherent proposition because you can see how all the elements interlink and work over time. The other advantage of this step, creatively, is that the act of sketching out the blueprint usually gives rise to other ideas and connections you would not have thought of otherwise, which can help you develop new business propositions.
Although we describe a fairly comprehensive blueprinting process below, a quick thumbnail sketch of a blueprint grid, or even a four- or five-panel storyboard of the service usage experience, can really help you think through a service concept in the early ideation stages. Because services are complex, you may miss a critical point of failure when thinking through a service concept. You may also have difficulty communicating your concept to others without showing how some key elements of the service unfold over time. Sometimes a quick storyboard sketch helps you realize that an idea is a nonstarter, and learning this after a couple of hours of work is better than after a few months of effort.
Most projects involve a combination of the two blueprinting approaches. Some improvement work may be the initial foot in the door that leads to new service innovation projects later. Sometimes a radical, blue-sky innovation session leads to smaller improvements in an existing service.
Start with Broad Phases and Activities
Whether you are working on improvement, new service innovation, or a mixture of both, the first step in creating a blueprint is to establish the stages of the service experience over time—the service life cycle—and then add the roles of the people involved in the service (usually starting with the customer or service user) and the touchpoint channels. These can be laid out in a grid consisting of the various roles and channels down the side and the time phases across the top (Figure 5.9).
FIGURE 5.9
The blueprint is a grid with the phases and steps of time running along the horizontal axis, and the customer, touchpoint channels, and other stakeholders along the vertical axis.
As we mentioned, there are no standard or typical blueprints and each project or element of a project may require different phases, but it usually makes sense to start with a default set of broader user journey phases across the top of the grid (Figure 5.10). The ones we typically use are listed below.
- Aware: The point when the user first learns about the service
- Join: The sign-up or registration phase
- Use: The usual usage period of the service
- Develop: The user’s expanding usage of the service
- Leave: The point when the user finishes using the service, either for a single session or forever
FIGURE 5.10
Start the blueprinting process by mapping out the main phases across the top of the grid. each phase should be fairly broad, such as “Aware” or “use.”
You will want to come up with phases specific to your project, such as “check in” or “close account,” and you may want to break down some phases into more detailed steps, especially for the “Use” and “Develop” phases (Figure 5.11). Add a brief description of the phase or step if it helps create clarity. This descriptive text is especially useful in blueprints that focus only on the substeps within a certain phase.
Use whatever level of granularity you need for your project, but be careful not to mix up the levels of detail too much. Detailed, step-by-step screens of a Web service sign-up process, for example, really belong in the set of wireframe documents that will specify this touchpoint later. Too much detail in a service blueprint can reduce its ability to provide a useful overview.
FIGURE 5.11
Break down the main phases—Aware, Join, Use, Develop, Leave—into smaller substeps if needed. For example, an airline arrivals hall use phase might include steps such as “Arrive,” “Find check-in counter,” “Check bags,” “Receive boarding pass,” and “Go through security.” Each of these is represented as a thinner column that spans all the touchpoints at that step.
Add the Touchpoint Channels
Notice that the broad phases listed above are described in terms of types of activity, such as “join” or “use.” These do not address the question of how these phases are carried out, such as “Sign up via the website form.” This step comes next when you add the various touchpoint channels to the lefthand side of the blueprint. Each row of the blueprint represents a channel of touchpoints (Figure 5.12).
FIGURE 5.12
Each row below the customer journey phases represents a channel of touchpoints, such as “Print,” “Face to face,” “Web,” and “Phone.”
These channels will almost certainly include media channels such as print, e-mail, and a website, but they may also include people in the form of staff or other stakeholders. The service may also include interaction with products, third-party services, and even other customers or users. The list of channels can extend down as far as you need. The number of rows is determined by the project context, but sometimes having a larger set of touchpoints than you initially imagine can help broaden the scope of your “What if?” thinking.4 If your project lends itself to division into frontstage and backstage activities, as most will, you can also do this here.
Even simple services have many touchpoints, and comprehensive services can become very complex to map out. If you add other people interacting in roles, such as patient, nurse, doctor, and administrative staff, you will find the blueprint becomes very complex very quickly. The idea is to capture the overall picture of the service concept as well as the specific details that make up the touchpoint experiences. Blueprints offer a way to manage the complexity. It is also important to be able to think through the journeys between the various touchpoints. For example, it is no good if the patient’s experience with the doctor and in the CT scanning room are wonderful if the patient has to wait for hours in a dimly lit hospital hallway while sitting on uncomfortable furniture.
Now that you have your grid, you can start filling in each cell representing the individual touchpoint experiences (Figure 5.13).
If you are analyzing an existing service, you can start by adding the results of your insights research. Write a statement in each cell to describe the experience of each moment of interaction—the customer trying to sign up online for a new mobile phone contract, for example, or interactions with staff in a store. At the “zoomed-out” blueprint level, these should be just a few words and some simple sketches. If you have space, you might want to add a photo or sketch that may describe things better than you can with words.
FIGURE 5.13
Each cell represents a single touchpoint experience in a single phase or step of the journey.
If you are developing a new service, think through how all the touchpoints connect together as a complete experience. This is also true if you are improving an existing service, but in this case you will have to decide whether this iteration of your blueprint is intended as an analytical tool to uncover problems or whether you want to include all the new ideas in it, too.
by Chris Risdon
Just a few years ago, I thought of myself as a designer of digital products—an interaction designer in the field of user experience focused on making digital products usable, engaging, and yes, profitable. But a funny thing has happened over the past few years: the projects I worked on started to look a lot less like products and more like services.
I went from designing something that was used in a single context (say, sitting at a computer looking at a browser) and roughly the same way with each use, to something that was used in different contexts and potentially used differently in each of those instances. Instead of designing a digital thing, I was designing to support a less tangible, ongoing sequence of interactions over time, between a customer and a company.
And it wasn’t just digital. Increasingly, the work I was doing for a product system was finding its way to other parts of an organization and its service offering. Their call center and their retail or environmental experience were all able to benefit from the insights we gained from research gathered for the digital product channel. It became hard to conduct research and gain insights for the digital channel without it having explicit influence on other channels or areas of a company’s offering. Customers don’t think in channels, and they don’t recognize that they are switching channels, so we couldn’t simply confine ourselves to designing for a single channel and think the customer would have a consistent, satisfying experience. We may have thought we were designing digital products, but customers were having interactions with the company that manifested in both tangible and intangible ways.
With this new focus on product systems, I needed new methods to capture this experience—methods that captured a system, not a single product, and that illustrated the way this system was used over time and in those changing contexts. I also needed something that would bring together the different parts of the organization. Clearly, user experience principles can be applied much more widely than to digital channels, but it is still primarily a practice for designing discreet digital products, its methods are not necessarily designed to go broad—cross-channel and cross-organization. Terms, methods, and processes may conflate in the future, but service design activities are more inherently suited, currently, to cross silos and incorporate other channels. It is explicitly less about the discrete in absence of the whole. Both disciplines seek to take a customer-centered approach to designing a product or service, so there’s no reason why they shouldn’t be complementary.
Customer journey maps (or experience maps, as I tend to refer to them—not entirely but mostly a semantic difference) are probably the most useful service design tool I’ve brought into my user-experience-centric process. I first started using them after initially integrating another service design tool: the service blueprint. When I was working in-house for a company, I found the service blueprint a great way to understand how to support the cross-channel experience, especially for an organization with many silos. So it was a great tool for a particular context, but something was missing up front. Service blueprints aren’t inherently designed to give insight as to how a journey is experienced. I was lacking something earlier in the process that could empathetically illustrate the whole customer experience, which was needed to bring together individual parts of the organization into a singular vision (Figure 5.14). I wasn’t deliberately diving into the service design toolkit; I just happened to be looking for a tool, a method, to illustrate the customer journey through a more experiential lens.
There are a few things that I like about customer journey maps. First, it wasn’t the map itself, but the mapping. When customer journey maps are done right, they involve all the different parts of an organization. The collaborative activity encourages people to get their heads out of the weeds and see the customer experience beyond their silo.
FIGURE 5.14
A customer journey map.
Second, mapping is one of the best ways to identify the changing contexts of a customer’s interactions with the company over time. Mapping the journey brings understanding of what customers are feeling, thinking, and doing at any given point in time when they are interacting with a service, and recognition of how that changes.
Third, when done right, maps tell a story with depth and richness around the human experience. I’m a big fan of visualizing stories because visuals are much quicker to comprehend than a few paragraphs. A good model of the journey tells a story through the layering of qualitative and quantitative information. With the element of time, this visual model is the quickest and most effective way to tell a story.
Other traditional user experience tools for connecting different parts of the experience, such as the concept model, lacked the elements of time and context. Scenarios were too focused on a singular part of the experience. User experience methods, at the time, were lacking systems thinking, and customer journey mapping allowed me to take the individual parts and understand how they could be orchestrated together, particularly in this new world that wasn’t limited to the digital portion of the experience.
Many instances of past customer journeys I had referenced were in the service of marketing or retail experience. There are examples of customer journey or experience maps out there that are over a decade old. But only in this new age of pervasive connectivity and the convergence of digital and physical experiences are we seeing processes and methods refined, pushed forward, or reinvented altogether.
I apply service design methods in almost every project I do, and I try to explore how to push these methods further—often writing, teaching workshops, and speaking about the practice. But I don’t know if I’ll ever think of myself as a service designer. Nonetheless, the cross-channel nature of design has meant that I continue to employ a number of service design methods and activities, such as customer journey mapping and service blueprinting, as well as new ways of prototyping, such as acting and business origami, and other tools for understanding the whole system.
I can’t say how the vocabulary or semantics will shake out in the end. I think that the best organizations will take user experience—an empathic, outside-in approach to making their customers happy—and not simply think of it as something to apply to their products, but as something that permeates their entire organization. And service design can be an approach, or a set of activities, that we within user experience design can use to bring together a more holistic strategy to defining a great customer experience across channels. What I may call myself in a couple years, or how we’ll label our design disciplines, well, we’ll leave that to another discussion.
Chris is an experience designer at Adaptive Path. Chris’s multidisciplinary approach to design has led to a career spanning information architecture, visual design, and interaction design.
Low Fidelity versus High Fidelity
You now have a completed blueprint that provides an overview of your service in a grid. Our examples above were put together on a computer, but it usually makes sense to create a quick, low-fidelity version first. Sketch out the grid on a big piece of paper or a whiteboard and fill in the touchpoints with sticky notes (Figure 5.15), or fill in a simple spreadsheet or table (Figure 5.16). These give you the freedom to move things around, discard things, and generally remain flexible. At some point, you will need a version of the blueprint with more visual polish so that you can incorporate images and sketches. This is likely to take some kind of digital form so that you can easily update and share it (see the sidebar on page 107).
FIGURE 5.15
Using sticky notes on a whiteboard or wall allows you to move things around easily. This method is especially helpful when brainstorming services because sticky notes are impermanent and have limited space to write or sketch the main concept of the touchpoint, which keeps you from getting bogged down with details too early.
FIGURE 5.16
A table or spreadsheet is a fast if visually uninspiring way to get your insights and touchpoint analysis into a digital form.
Zooming In and Out
The blueprint is useful for the overarching view, and you need this perspective to make sure you keep all the parts of the service ecology in mind and avoid the silos problem described earlier. During the blueprinting process, however, you will also need to go into more detail than the individual cells allow while still bearing in mind the overall service proposition. This requires mentally zooming in and out from detail to big-picture overview during discussions. For example, what does the print communication look like and how does it fit in with the whole service proposition? How does the desire for a seamless smartphone activity affect the backstage IT requirements? It is exactly these relationships that often get lost in traditional requirements-gathering processes. The blueprint allows you to keep everything connected with a simultaneously user-centered and enterprisecentered focus.
As with many design methods, blueprinting is not an exact art. Improvements and tweaks to the process are made from project to project; clients may want specific terminology that matches their internal processes; and agencies develop their own tools and techniques. As we will show in the following chapters, however, the blueprint becomes the backbone of the service design process. It is used for mapping and analyzing the insights research and service ecology as well as designing and developing the service proposition and measuring the results. This makes it an iterative process, of course. The blueprint helps generate ideas but also needs to be changed and updated as new ideas and elements are conceived. Before we go further with the blueprint, however, let us take a look at the service proposition and how to design and develop it.