Service Design: Chapter 6: Developing the Service Proposition
Published: March 18, 2013
This is a sample chapter from the new Rosenfeld Media book Service Design: From Insights to Implementation. ©2013 Rosenfeld Media.
If we are looking to improve an existing service, our blueprint has given us a pretty good overview of the component parts of the service and how these are experienced over time. If we are developing something entirely new, we may have less detail but some idea of people’s needs and what some of the key touchpoints might be. Before going further into the details and committing significant resources to the project, we need to develop the service proposition.
Basing the Service Proposition on Insights
The service proposition is essentially the business proposition, but seen from both the business and the customer/user perspective. It is important that some kind of business model lies behind the service—even if it is a free or public service—otherwise it will not be sustainable or resilient to change. The usual approaches and questions apply: Who is going to fund it? What is the price point and market segment? What do we need to deliver the service, and what will it cost?
The service proposition needs to be based on real insights garnered from the research. For example, is there an unmet need, a gap in the market, an underdeveloped market, a new technology that disrupts existing models, an overly complicated service infrastructure that can be radically simplified, or a changing environment? Any one of these might lead to a business idea and, in turn, a service proposition.
The Zopa Service Proposition
Peer-to-peer lending service Zopa.com (Figure 1) is an excellent example of a service proposition based on the insight that companies have a very different relationship to financial services than individual consumers do. One reason for this difference has to do with the way companies are rated by third-party agencies (or the market), which enables companies to present themselves as a viable lending proposition to the financial industry. This system led to the development of the bond market, which allows financial institutions to invest in companies while spreading their risk. This, in turn, allows companies to borrow money in ways not available to consumers, and usually to get a better deal. The Zopa co-founders saw the opportunity to create a similar “bond market” for individuals. A person who may not want to lend £1,000 to one person might be willing to lend £1,000 to be divided among 100 people because the chances of default on the entire amount are very low.
Figure 1—Peer-to-peer lending service Zopa.com’s clear service proposition on their website
Zopa is also a good example of insight into the power of networks and data as the fuel for disruptive innovation. Behind the scenes, Zopa’s proposition is the insight that the data needed to create such a rating system on individuals are out there, but as Zopa co-founder Giles Andrews explained, “Banks have done a fantastic job of telling everyone that they own all this data, which they don’t, of course. It’s yours, it’s mine, it’s everybody else’s. It certainly doesn’t belong to banks, but the industry is structured in such a way that it became very difficult to get that data.” (See Giles Andrews’s IPA talk.)
Although individuals can apply to credit rating agencies to get the data held on them, they cannot do much with it. Zopa helps empower individuals by using this data to rate their creditworthiness in a peer-to-peer lending market. Zopa’s service proposition is that both lenders and borrowers can get better rates than they would from banks. (Zopa stands for Zone of Possible Agreement—the overlap between what a person is willing to sell for and another is willing to pay.) To do this, Zopa needed to translate their financial thinking into a compelling service and social experience that people could understand and would want to use.
In fact, another opportunity insight for Zopa was the increasing social use of the Internet and the fact that by 2004, when the Zopa founders were starting up, eBay was the biggest online marketplace in the world. Zopa’s founders could not explain eBay in any rational economic way. After all, people seemed willing to take the risk of sending money to complete strangers with almost no security, something that a bank would never do. The only way they could explain it was in terms of eBay as a social experience in which people and personal reputations matter.
Zopa is a good example of an organization starting at the people end of the process, asking “What can we do for individuals who do not trust their banks, and how can we build a service business around that?” This is why service design takes a bottom-up, needs-based approach to designing services with people.
Returning to the development of the service proposition, it is important when sketching out the ideas at this early stage that the following three questions can be answered:
- Do people understand what the new service is or does?
- Do people see the value of it in their life?
- Do people understand how to use it?
We will revisit these questions in Chapter 7, and add some more as well, but for now let’s take a look at these three in turn.
Do People Understand What the New Service Is or Does?
This question may seem obvious, but unlike products, which have physical affordances signaling their potential usage, services can be abstract or even invisible. New services often chart new territory, so explaining what peer-to- peer lending is, to use Zopa as an example, is important. If people are used to borrowing money from banks, they might not understand the point of Zopa. Here is how it is explained on the Zopa website: “At Zopa, people who have spare money lend it directly to people who want to borrow. There are no banks in the middle, no huge overheads and no sneaky fees, meaning everyone gets better rates.”
So, now we have a pretty good idea of what the service does, but do people want it in their life?
Do People See the Value of It in Their Life?
Arguably, the biggest sin designers, engineers, and technologists commit is coming up with stuff they think is cool but nobody actually needs. History is littered with entirely useless products and services. History is also speckled with things people initially thought were useless but that turned out to be things we can hardly live without, such as text messaging, sticky notes, and websites with pictures of cats doing funny stuff.
If you are developing a service proposition, it is essential to think about how it adds value to people’s lives. This should, of course, be neatly based on the needs that you uncovered through the insights research, but projects also get steered from above within organizations. Watch out for service propositions that start veering more toward the needs of the business than the customers. The ideal is a proposition that is win-win for both service provider and service user, with each side providing value to the other.
This is how Zopa explained their value: “We hear you ask, ‘Why would anyone lend money to a complete stranger?’ Because, quite frankly, it gives a better return than saving with a bank. With over £160 [million] lent and a proven track record of managing your money better than banks, we think you should be asking, ‘Why not?’ ” (As of late 2012, the figure is now more than £230 million lent. Giles Andrews, personal communication, February 13, 2012.)
Many people feel that their bank is a necessary evil that is always trying to rip them off with spurious fees. For this reason, people feel little loyalty toward banks. Zopa confirmed this insight (a pretty obvious one, when you think about it) through their research. People do not trust banks to look after their best interests, but they do trust that their money will be locked up in a big vault somewhere, even if it is just a digital one.
Zopa looked at how they, as a start-up, could compete against this love-hate relationship that customers have with banks. The result was to “go for the soft side of trust,” according to Giles. (Both Giles Andrews quotes in this paragraph are from his IPA talk.) They came up with a tone of voice that is both friendly and straightforward, sometimes funny but not flippant. This guided the design and communication of all their touchpoints: they are as clear and transparent as they can possibly be about how they make money, what the charges are, and what happens if things go wrong. This is the complete opposite of what banks typically do. As Giles explained, “[Banks] have huge amounts of small print. They make their money out of people making small mistakes and they don’t make their money out of providing a fair service most of the time.” Zopa also emphasized the human side of lending and borrowing money (Figure 2), something that many people feel banks have lost sight of.
Figure 2—Zopa emphasizes the human stories behind lending and borrowing to differentiate themselves from traditional banks.
So, a combination of the service proposition’s underlying principles and how they are communicated across touchpoints helps people understand not only what the proposition is, but the value it has to them. The next thing to tackle is whether they understand how to use it in practice.
Do People Understand How to Use It?
You may have been working on a new service for a while, and the client you are working for should certainly know their business, but do the potential service users understand it? We know how to use a door handle, for example, because we have grown up with them and door handles have physical affordances that encourage us to push, pull, or turn them, but a peer-to-peer thingamabob? Potential users need to have some idea of what “peer-to-peer lending” means, which is why Zopa explain their service as “a marketplace for money.” They also explain how their service works, which is more than most traditional banks bother to do (Figure 3).
Figure 3—Zopa clearly explain how their service works in four simple points: (1) Lenders like you put money in; (2) Borrowers borrow money; (3) Zopa does the bit in the middle; (4) You enjoy great returns.
So now we know what the service proposition is, understand the value of it in our lives, and have a rough idea of how it works and how to use it. Zopa is charting new territory, so they have spent a lot of time and effort detailing the “how it works” sections of their website to help people understand the service and build up trust in it, which is central to the business.
Other service propositions can benefit from metaphors and piggybacking on existing, well-understood products or services. For example, WhipCar is a peer-to-peer car-sharing service that allows people to rent out their own cars to strangers when not using them. Because Airbnb, a service that allows people to rent out a spare room, an apartment, or even a house to strangers in the same way, was already an established service (Figure 4), WhipCar can describe themselves as “the Airbnb of car sharing” and half the job is done for them (Figure 5). Obviously, people need to know about Airbnb first, but many of WhipCar’s early adopters were also early adopters of other collaborative consumption sharing services such as Airbnb, so the comparison was well targeted.
Figure 4—The “community marketplace for unique spaces,” Airbnb makes a clear service proposition on its home page, even through the default text in the form fields.
Figure 5—WhipCar is a peer-to-peer car-sharing service that is like Airbnb, but for cars. Note the simple three-step “How it works” explanation.
Taking Slices through the Blueprint
You can see in the Zopa example that developing the service proposition requires the constant mental zooming in and out mentioned in Chapter 5. A detail, such as people’s trust relationship with conventional banks, leads to the development of a service and business proposition. This proposition has to be communicated back to the users, which means thinking about the detail of the tone of voice across touchpoints.
The service has to make money, so Zopa must take a cut or charge customers in some way. The communication of this element needs to be as clear and transparent as possible because unjust bank fees are part of people’s unhappiness with traditional banks. To do this, the Zopa website has a section titled “How we make our money.” Every business decision affects the service proposition and the delivery of that proposition. By the same token, details in the touchpoints can affect the entire business. If users do not understand something, such as how and why Zopa take their cut, it will lead to an erosion of trust and Zopa’s business will suffer.
The way to manage zooming in and out, from detail to big picture, is to use the service blueprint as a space in which different scenarios can be played out. The blueprint should show the essential parts of the service ecology so that you can track different user journeys through it in a number of “What if?” scenarios. This allows all stakeholders involved in the project—designers, users, staff, and management—to work through all the “If … then” decisions that will define the service proposition and experience.
It is at this stage that the real design happens, in the sense of the “coming up with ideas” part of the service design process. Having a blueprint based on solid insights allows the service design team to connect those insights to the business goals and strategy and to design a joined-up experience. The blueprint and other design specification documents ensure that everyone is on the same page.
Choose Where to Focus Resources
Every project has limited resources. Regulatory structures, environmental concerns, and manpower can limit the scope of a project, but most are limited by time and money. Although it would be nice to be able to design every touchpoint perfectly and every conceivable journey through a service, this is usually not possible. You will have to choose which touchpoints to concentrate your efforts on. Choosing a few key touchpoints that express the core of the service is a useful way to get started, whether innovating new services or improving existing ones.
If an existing service is being improved, the obvious touchpoints to work on will arise out of a combination of your insights research (Figure 6) and the business strategy. Some will be low-hanging fruit—touchpoints that are currently service fail points, that can easily be redesigned, and that will result in the most significant gains. Some touchpoints, like redesigning a bill, might be an easy graphic design task, but implementing that redesign may be complicated and require all sorts of changes to old and clunky backend accounting and billing systems. Your low-hanging fruit may not be so easy to pick after all.
If you come from another design discipline, you may be tempted to design the details of touchpoints earlier on in the blueprinting process. Sometimes this can be an entry point into a project. A client may employ you to work on the customer experience of a specific touchpoint, such as a ticket machine interface redesign, but after you have done the insights research you may find that the scope of the service elements that need improvement is much broader. You may find you need to design the entire channel or multiple channels over several phases of the journey.
Figure 6—Insights research may help you decide which touchpoints to focus your resources on. You can highlight or detail these on your blueprint in its early, rough stage.
To avoid ending up with the design process also being carried out in silos— with UX or interaction designers working on the screens, product designers working on the products, and so on—you must be clear about where each element fits into the broader context. The way to do this is to zoom out again, look at your blueprint, and design the service proposition, which may mean holding off on the details at first.
The ability to carry both of these levels of detail in your head at once is an essential skill in service design. Although you will mentally zoom in and out, you may find you also need to print out different levels of detail and pin them all up on the wall so that you can discuss them with others working on the project. Here are four useful ways of taking detailed slices through the blueprint.
Even for completely new services (and there are very few really new services—they are usually modifications, transpositions, or combinations of existing ones), you will need to choose which touchpoints to concentrate the bulk of the effort on. So, how to choose?
Apart from thinking about outcome value versus effort, the easiest way to choose is to track key user journeys through the blueprint. If you have developed personas (real or aggregate ones) from your insights research, you can start imagining how each type of user will move through the service. Mr. Analogue, age 70, might prefer the face-to-face contact channels, whereas Miss Technophile, age 22, might prefer to use online and mobile self-service channels. Typically, most users will experience a mix of channels and may switch between them depending on their context—at work, at home, while traveling, and so on—which is another reason why the coherence between the channels is important.
Service designers need to align insights from backstage staff with customer needs. Define where the experience breaks down or great opportunities exist in the customer journey, where channels and technologies play well together to produce value, and when they run counter to each other. Taking journeys through the blueprint is a way to iron out many of these issues (Figure 7).
Once you have mapped a particular user’s journey across the phases of the service experience and through his or her chosen subset of the touchpoints, you can put together a journey summary. This is essentially a scenario storyboard of each phase of the journey (or steps, if you are looking into finer detail) with a description of what happens and what kind of experience the user should have (Figure 8).
Figure 7—Tracking a user journey through the blueprint
Figure 8—A journey summary describes a particular user’s journey through the main service phases, or through a more detailed set of steps. It shows what is going on visually, and the text describes the experiences and interactions with the chosen touchpoints.
Phase and Step Summaries
Apart from allowing you to map journeys across the entire ecosystem of the service, the grid nature of the blueprint allows you to interrogate the rows and columns. Each one of the service phases (Figure 9) or steps (Figure 10) can be seen as a column that comprises the customer/user experience across all of the touchpoint channels, right through to the backstage stakeholders and activities that are relevant to it.
Figure 9—Each phase is represented by a column that comprises all of the touchpoint channels and the backstage services that support them.
Figure 10—You can also examine a more detailed step across all the touchpoint channels.
From this you can create a more detailed phase or step summary document that describes what the user experience should be across all the channels at that stage of the journey (Figure 11). This summary should also document the connections between different backstage elements of the service and how they need to interact to deliver the required frontstage user experience. It details what kind of experience you want to offer the customer and the implications this has for the technical delivery and business process. You may want to use it to flag certain mission-critical elements or activities.
As with any other interaction or product design, it is important to break down the various interactions into their component elements and map out all of the interactions across all channels. Do third-party services need to be engaged? Do new products or technologies need to be designed and developed? What kind of screen-based interactions are involved? Is the service experience coherent across all these channels? Are parts of the service ecosystem out of your control, and can you mitigate for potential problems here?
Figure 11—A phase summary document describes what the user experience should be across channels and what backstage and business elements need to be in place to support it.
For example, joining a service might involve signing up in person, online, or with a mobile phone. This process will probably involve some kind of payment system or registration confirmation response. Other services may include physical elements, such as sending a welcome pack or an access ID card in the mail.
In both the phase and journey summaries, your notes can also include material from your insights research. This may be either what existing users have said about the current service or the needs your insights uncovered that have led to the proposed new service. Moving back and forth between the concept development and the insights research keeps your design process grounded in reality. It is all too easy for ideas to blow out into feature-laden fantasies that people do not actually need, as is often the case with marketing-driven product or service development (we’re looking at you, Microsoft Office).
If you take a horizontal slice through the service blueprint along the row of a single channel, you can examine how that entire channel works over the life cycle of the service.
This view also allows you to put together a comprehensive specification or briefing document describing the experience of that channel (Figure 12). Over several pages, document each moment of interaction with that channel as defined by the phases and steps of the user journey. This specification might be used for a large project, such as the redesign of a service’s website, to ensure that the design process does not happen in isolation but, crucially, in the context of the other channel interactions and over time.
Figure 12—The first page of a channel specification, which describes each phase or step of the user interaction with a specific touchpoint channel. Subsequent pages detail the other touchpoint interactions (2 & 3) highlighted across the channel row.
Specifying Individual Touchpoints
An individual touchpoint is the intersection of time—the phase or step in the journey—with a channel, such as a customer signing up for a service using a form on a website. In the service blueprint, this is an individual cell, and it describes the what, how, and when of the touchpoint. “User registers online” may be a touchpoint, but it is hardly a design brief. You will need to break down each touchpoint into a detailed description so it can be designed or improved (Figure 13). This description will form the basis of the briefing and specification document that is passed to other designers and developers to guide their work.
Figure 13—A briefing document for an individual Web touchpoint for a youth banking and insurance package launched by Gjensidige.
When you do get to this final level of detail, service design teams are likely to use a range of methods appropriate to the design discipline that the touchpoint involves. Web and mobile interactions require UX wireframes and walkthroughs, products require 3D sketches and renders, connections to IT services require descriptions of database transactions, and print touchpoints may involve everyone from marketing to billing as well as graphic designers and printers. You may also make a storyboard for some kind of time-based communication of the service, such as a video or slideshow with a simple voiceover talking through the service experience over stills or animations that illustrate the stages.
This convergence of skills is probably the most common reason why people from other design and business disciplines perceive service design as the same thing that they already do. At the individual touchpoint level, this is often true. Service design projects draw upon specific expertise where appropriate, and the blueprint and associated material is the design specification for these other capabilities. The difference is that the entire service ecosystem is also designed and connected together. It does not just happen by accident because the various parts are in the same service. The entire purpose of service design blueprinting is to ensure that all the different elements across all touchpoints are not designed in isolation. The blueprint leads to the design specifications for each touchpoint and acts as a way to orchestrate them all. Service design is both broad and deep.
Blueprinting is not only an essential service design tool, it is extremely useful when working together with clients as a way to talk about the service concept and how the elements fit together. It breaks down barriers between business units by helping everyone involved in the project understand how his or her part fits into the bigger picture. It also reveals opportunities to join up processes and create more seamless experiences by making sure that there are no gaps in the delivery that everyone thought somebody else was responsible for. Politely ask the client to print out a copy of the blueprint, hang it on the wall, and bring a copy to meetings. (Thanks to Anders Kjeseth Valdersnes for this tip.)
Gathering insights to feed into the design of a service is great, but the service also needs to have a business idea behind it—the service proposition. Without this, even the best ideas will not be economically viable and sustainable. Key to the service proposition is being able to answer three questions:
- Do people understand what the new service is or does?
- Do people see the value of it in their life?
- Do people understand how to use it?
Taking slices and journeys through the service blueprint allows you to explore whether each touchpoint adequately communicates the answers to these questions from the service user point of view. You can then develop each touchpoint cell in the blueprint into a detailed design specification for the creation of the touchpoint.
Buy Service Design Using Your UXmatters Discount
To learn more about service design, get your own copy of Service Design: From Insights to Implementation. For a 20% discount on this and other Rosenfeld Media books, purchase them on the Rosenfeld Media Web site, using the discount code: UXMATTERS.