Problem and Context

In 2013, SDL went on the journey of integrating all their software product related to customer experience management into one integrated cloud based offering, called the Customer Experience Cloud. With this came not only the need to align the user experiences of the various product user interfaces, but also all related marketing and support touchpoints. We had a variety of different customer journeys, ranging from upselling existing on-premise customers all the way to new customer that would “consume” the new services in a SaaS subscription format. As we had many teams and internal silos to coordinate and align, we needed a tool to map the best possible experience we wanted for our customers and break it down somehow to see who needs to do what (and in what order and priority).

For this context I developed a service design blueprint workshop format, tested it with the UX design team in our annual UX Summit first, and applied it to a variety of different products and services with cross functional teams after. Service Blueprints work particularly well for exploring new services experiences that bridge multiple different touchpoints, including digital and non-digital, and help the team to understand on the one hand what journeys and experiences they want and on the other what technical capabilities they need to make such experiences happen.

Workshop Format

Even though I developed several variations of this workshop format to adjust it to the different journey types, team sizes, and simply the time that was available, the raw format stayed the same. Assuming you gathered a cross-functional group with little to no experience in UX or service design (and in some cases even with product development in general), it’s important to start with setting the scene.

A general introduction explains what service experiences are using everyday examples everybody can related to (e.g. requesting a new driver’s license including all steps and interactions involved) and how they are different from individual user experiences (that focus on interacting with one touchpoint only).

Important take away for every participant in this introduction is the level of abstraction services experiences are being design upon and that this can only happen with an outside-in perspective. Perceiving the world from the customer’s perspective, emphasizing with their needs and contexts, and from that vantage point designing the service experience.

It means to provide the journeys first and from there breaking it down into required touchpoints, products, user interfaces, and features. Quite the opposite to how most product companies are still working, despite agile frameworks and lean transformation programs.

After the introduction to service design I usually introduce the concept of service blueprints and the process of designing them. This includes personas, user journeys, story boards and storytelling.

Service Blueprints as a tool are best explained using the restaurant metaphor where the line of visibility (for the customer) is the door to the kitchen. You design the experience that the guests have while they spend time and eat in the restaurant, but you also map out everything that needs to happen behind “closed kitchen doors” to make this experience happen.

Some examples make it all more tangible before the group is split into separate teams and gets hands on.

Personas and User Journeys

Each team starts with describing and drawing the persona(s) they are designing a service experience for including a good description of their context and needs. It’s very important to leave time so the group can sufficiently discuss and agree on which problem they want to address for whom during the workshop.

Ones this is set, the group starts brainstorming an optimal customer journey for their persona and the given problem. The group should apply some storytelling and can use any tool or method they have at their disposal. A simple story board will do the trick for most groups.

Breaking down the user journey into a Service BluePrint

That’s the core part of the workshop, each group maps the customer journey at the top of the Service BluePrint canvas and then starts to break it down. For each step in the storyboard: What are customer actions? What are actions of the service provider? What is the touchpoint? This will usually fill up the upper part of the service BluePrint first that only describes the direct interaction of the customer with the service provider staff.

In a second step the team then discusses the supporting services (by staff or technology) that are required to allow for the customer-service provider interactions as described earlier. Here lays the real power of this method for large projects in technically-savvy and complex organizations: This outside-in method starts with the desired customer and service experience first, and uses this as the lens to look into technical requirements for backend systems.

Outcomes

The final step of this workshop focuses on the breakdown of the required systems and interactions into system and technical requirements. What information do I need when where? Should a customer get access to these information from a support agent or via a self-service portal. The service Blueprint helps to formulate specific requirements for the separate individual touchpoints that all members of the cross-functional group can take home to their respective teams. There they can run a more typical iterative design and development process while being ensured that the result will fit into the larger service journey designed together upfront.