Create a service blueprint
One service design method that has the power to bring many factors to the forefront is the service blueprint. Just as an architecture diagram creates alignment for approaches to building, a service blueprint provides insight into shared responsibilities, the flow of information, and the dependencies of the system. It accounts for user roles, internal business rules, and actions taken by the people and technology involved. Rather than segmenting responsibilities by functional group or working team, a service blueprint orients to the customer’s experience with the product. This brings together the business operations and customer touchpoints into a holistic view of the system supporting it.
Service blueprints are oriented around a customer’s experience across each touchpoint they have with the product. It is a series of moments lined up over time, with lines connecting the moments to track who owns each part of the process being successful. New risks and opportunities emerge. Each aspect of the experience individually in dedicated lanes and aligning each activity over time clearly showing what is happening at every moment, and who is driving progress forward.
A great digital experience is similar to creating a well-rehearsed stage production. Similarly, a service blueprint uses terms familiar to the theater world like roles (e.g., the customer) and front and back-stage activity (e.g., the interface/the internal processes).
There are three essential actions needed for effective service blueprints.
Document the customer journey
Orchestrate a seamless experience
Track technical and support processes
Let’s take a closer look at each.
Documenting the customer journey
Mature delivery teams know the value of a user-centered approach. In practice, a service blueprint takes a wider view of the customer’s journey—including moments before, during, and after using the product. Understanding the moments just before and immediately following using a product allows for the intentional design of both the onboarding and offboarding experience. Using an example of ordering a pizza, being hungry, and eating the pizza are the important parts of that journey. The app used to order it is the conduit for value.
Each action the customer takes builds the foundation. Their actions are supported by the touchpoints they have with the front-stage experience. With the customer driving the process, the app used to order the pizza comprises the front-stage of the experience. Their touchpoints with the app move their journey forward. Each of these touchpoints through the front-stage drive additional action behind the scenes. The back-stage roles include the pizzeria team making the pizza and the driver delivering the pizza. There are additional support processes involved, for example, the pizzeria’s equipment and appliances, the navigation app used for delivery, and the systems of order management and payment processing.
Consider each possible interaction, active and passive, that a customer might take through various touchpoints (e.g., seeing pizza ads, ordering a pizza via mobile app, receiving push notifications/emails). The front-stage experience is often the interface of the application but can also be a direct interaction with another person or other explicitly customer-facing aspects of the process, such as forms and printed material. Tracking each of these individually helps to identify the subsequent back-stage processes that make everything possible.
When drafting the customer journey, document the best planned path through the system. Exercise caution when crafting this picturesque state, as too-perfect-case scenarios could provide an unrealistic baseline for future decisions. Anchor these explorations to reality. To do this, interview prospective users. Talking to sample users with structured interviews provides actionable data to drive better understanding and deliver a successful experience.
Orchestrating a seamless experience
There are two operational aspects documented in a service blueprint: the front-stage and back-stage. The actions taken within these parts of the experience include back-of-house processes and operational duties that impact success or failure. The quality of the experience is defined by how well back operations support the front-stage experience (and vice versa). Back-stage operational efforts and systems support their front-stage counterparts (e.g., automated processing, shared microservices, and individuals or departments that require additional manual steps to complete a task). Successful front-stage and back-stage processes generate both operational and performance success.
These processes create the customer’s expectations and impressions of the experience. Each interaction contributes to a successful or failed outcome for the customer journey. Documenting each touchpoint, along with the rationale behind each action, is important for tracking results. Identify internal metrics for handoffs within the workflow, including response time, processing time, and transactions processed over time.
Tracking technical & support processes
The supporting processes are the glue that holds the entire process together. Supporting elements of the infrastructure (e.g., automated processing engines, recommendation frameworks, or external dependencies for information and services) are not always in the team’s immediate control. Regardless, the team still needs to understand the constraints and limitations supporting elements present. Good or bad, within the team’s control or not, support processes impact the product’s success.
When support processes drive the experience, customers are hands-off. Therefore, their expectations need to be managed from start to finish. To track successful outcomes, document each supporting interaction noting which system or group owns each action and what actions define success.
Draw the lines of interaction to show how agency moves within the system, and which moments in time are dependent on triggering the next moment. As a result, individually measurable moments that impact the customer experience are uncovered.
Compile a list of moments to factor into the backlog and actionable items to tackle in the build.
Compare the list of opportunities against business priorities. The overlap between the two, informed by the challenges in the system, is the strongest space to begin building the initial product release.
Consistently review and iterate on the service blueprint. Throughout each release, the experience changes. The document should continually evolve, serving as a common reference point for stakeholders and team members—as well as designate a healthy regular release cadence for the product and future dependencies.