Even if it’s your first time doing so, this guide will help you create a service blueprint. A service blueprint is a living document. It will grow and change as you gather information from different teams and/or as the service itself grows and changes.
This toolkit can help you:
- Align interdepartmental teams by establishing a shared understanding of the service.
- Discover critical moments, inefficiencies, and pain points.
- Identify opportunities for improvement, for both end users and the people who provide the service.
A service blueprint is:
A map or diagram that visualizes a service. It shows how all of the people, processes, systems, and dependencies work together to provide the service for end users.
Before you get started, it’s important that you and your team align on some terms so that you all share a common language as you’re creating a service blueprint. Here are a few useful definitions:
End users: the people who use a service to accomplish a goal
Service: a utility or system that helps end users (the general public or civil servants) achieve a goal
Service blueprint: a map or diagram of all the people, processes, systems, and dependencies involved in delivering a service
Service goal: what end users are trying to accomplish
For example, the USPS is a service. End users are the general public. Mailing a letter is a service goal.
Steps to create a service blueprint
Here’s a brief outline of the steps you’ll take to create a service blueprint:
Workshop a first draft of the service blueprint with a small team.
Validate the service blueprint with key users and stakeholders.
Engage other teams to add details about technology, policy, or operations.
Apply what you’ve discovered to align teams and improve services.
Plan a workshop
Create a first draft of your service blueprint with a small team. This will give you a baseline understanding of the service from the end-user’s perspective and what happens behind-the-scenes to deliver that service. It will be a tangible and visible diagram that you can share with other people on other teams to build consensus and gather more information.
Who to invite
The first time you blueprint a service, invite:
Someone with insight into the entire end user experience, like a program supervisor
What to bring
Sample agenda (60 min)
Define the goal of the service you’re blueprinting. (10 min)
Map the end users’ steps and tools. (20 min)
Map staff and management’s steps and tools. (20 min)
Identify any open questions, assumptions, or gaps and who you need to consult with next. (10 min)
Service blueprint example
This is a basic example to help you structure your own service blueprint. But service blueprints are as unique as the services they document. Adjust the columns and rows to suit your own needs.
Workshop your service blueprint
Define the service goal of the service you’re blueprinting
What are your end users ultimately trying to accomplish? Your answer is your service goal.
This will help you know exactly what your blueprint should capture. Examples of a service goal might be getting a driver’s license, enrolling in health insurance, or mailing a letter.
Map the end users’ experience
All service blueprints build on what you and your team already know about the actions an end user takes to accomplish their goal.
Steps and tools
Note each step an end user will take, from first learning about the service to reaching their goal. Also note the tools they may use to accomplish each step. Consider:
How do end users learn about this service?
What kinds of decisions do end users make to progress from one step to the next?
What tools, both digital and non-digital, might they use to complete each step?
What information do they need to successfully complete each step?
Are there common mistakes or challenges they might encounter?
How much time does each step take?
Are there specific deadlines or timelines end users must adhere to?
Later, you should plan to validate this information with end users. But for now, it’s okay to note if you’re unsure or making assumptions about a step.
Communication channels and notifications
As they progress through a service, end users may interact through multiple communication channels. Examples include website, phone, mail, and in-person interactions.
For each step, note:
What communication channels are available to the end user?
How is information about the end user’s steps saved or communicated to frontline staff and/or management?
How do end users know that they can move on to the next step?
Map staff and management’s experience
Add each step frontline staff takes to help provide this service. Note any communication channels, tools, or systems frontline staff uses. Consider:
How does frontline staff know that the end user has done something?
How does frontline staff respond to each of the end users’ steps?
You may need to add new steps between the end users’ steps to describe what happens when a frontline person receives information or requests from end users.
For each step, note:
What communication channels, tools, or systems does frontline staff use?
What information does frontline staff need to progress to the next step?
Is this step difficult or easy to get wrong?
Is this step directly supported by the tools currently available?
How much time does each step take?
Are there deadlines or timelines frontline staff must adhere to?
Again, make a note if you have any questions or are making any assumptions.
Managers and leadership staff may or may not be taking steps alongside frontline staff and end users. Either way, they need to know whether or not systems and programs are working. Direct reporting systems, manual data pulls, or even spreadsheets from system vendors might support management’s experience. Whatever the case may be for your service, note the following:
What steps do program managers take to ensure that end users are being served?
How do managers know that frontline staff are operating effectively at each step?
What kinds of information do managers need to make that assessment?
How do they receive that information?
Are managers’ needs directly supported by the tools currently available?
Are there deadlines or timelines managers must adhere to?
Identify gaps and who you should consult next
Revisit your notes to identify:
systems or tools you need more information about.
open questions or assumptions that need to be answered or verified.
Schedule time to consult with the people who can help you complete these gaps as best as possible.
Develop and validate the blueprint
In the meantime, confirm the current understanding of the service with stakeholders. You can also add additional layers, like technology, policy, or operations. The more details you have about the service, the more opportunities you may find for improvement. Gathering more information can help teams identify and prioritize both short-term changes that can be acted on quickly and larger phases of work that will help achieve the long-term vision of the service.
Validate the current version with key users and stakeholders
Talk to end users about their experiences with the service. Ask them to walk you through their steps to ensure you’ve captured their interactions as accurately and thoroughly as possible. You may want to ask:
How did you learn about this service?
What tools, both digital and non-digital, did you use to complete each step?
Did you make any mistakes or face any challenges?
How long did each step take you?
Where is each step happening? (At a physical or digital location?)
At which steps did you communicate with staff?
Note any discrepancies or additions you discover
Meet with stakeholders and talk through the service as you understand it. Note any clarifications, questions, or corrections from the stakeholders.
Engage other teams
Once you have a solid draft of the end user and frontline staff steps, schedule sessions to fill in details about technology, policy, or operations. These sessions will help bring clarity to additional (and sometimes invisible) parts of the service.
Add the technical systems that end users, frontline, and management staff rely on to complete the service goal. Usually, these systems document information about the interactions end users have with a service and the actions taken by frontline staff and/or management. Consider:
Where is information about end users stored?
Does the technical system help workers make a decision or progress to the next step? What system(s) are involved in accomplishing that task?
If there is more than one system involved in this step, how does information move between them? How much time does it take for information to be transferred?
Are there any gaps between systems?
If relevant to your service, you may want to document how managers assess technical systems. This can provide insight into capabilities or business needs that you may need to account for in proposals to change the service. Usually, assessments involve monitoring factors like service availability and whether or not key interactions are being properly logged. You might consider:
How do technical managers know that all of their systems are operating effectively?
Where are logs stored? What are those logs used for?
You may want to add details about agency or program regulations, third-party services, or relevant legislation if they impact your service.
Apply what you’ve discovered
Hopefully, drafting a service blueprint has given you a pretty good understanding of the service and the factors that influence end users’ ability to meet their goal. Now you can take what you’ve learned and:
help your team or interdepartmental teams understand any existing challenges,
build trust among stakeholders who are responsible for maintaining the service,
and propose changes to improve the service.
Whatever you do, don’t email a service blueprint to team members. It’s best used as a discussion tool or conversation starter — in person.
Get in touch
If you use this guide, we’d love to hear from you. To share questions or feedback, email us at email@example.com.
Director of Design