How service blueprints evolve through the design process
By Alex Wotton
Service blueprints are a fantastic design artefact for communicating how a service works for users. They are delivered by the service design process–which is all about designing complete ‘end-to-end, front to back’ experiences.
The best way to imagine a service blueprint is by considering how an architect designs plans for a building.
A service designer creates a diagram that illustrates the plan for the service, that includes the structure (the number of steps and interactions involved), the people (who engages with the service and why) and technology (what do people use to interact with the service).
Communicating design intent is the main purpose and value of a blueprint. However, they are also an incredibly powerful tool for facilitating conversations and building a shared consensus across stakeholders and business silos.
This blog demonstrates how a service blueprint evolves throughout the government design process — Discovery, Alpha, Beta & Live (see the gov. service toolkit for more information). This process isn’t exclusive to government — there are similar design phases across the private sector too.
The GDS design process
The design phases are part of the service lifecycle. Typically, discrete segments of work to develop a service from nothing to something.
- Discovery — before committing to building a service, you need to understand the problem to be solved by talking to users and understanding the technological and legislative landscape
- Alpha — explore different solutions to the problems uncovered in Discovery through prototyping — validating the most challenging parts of the service
- Beta — take the best idea(s) from alpha and start building for real, developing solutions to replace and/or integrate with existing services
- Live –supporting the service in a sustainable way, whilst continuing to iterate and make improvements
Even though these are the steps named by central government, they are generic phases digital design projects follow; doing research; creating prototypes; developing code; launching products; and sustaining a solution.
The two types of blueprints in Discovery
Blueprints are created when trying to understand how an existing service works (known as an ‘as-is’ blueprint), or to paint the picture of a future service (known as the ‘to-be’).
The ‘as-is’ blueprint is normally the first service design artefact generated in Discovery. By mapping the as-is service, journeys can be identified that highlight key interactions and pinch points — brought to life by the findings from research.
The blueprint is split into two halves, the frontstage and backstage.
- Frontstage — everything customers can see (e.g., website and hotel reception staff)
- Backstage — everything past the point of what customers can see (e.g., booking systems and kitchen staff)
This first blueprint is just a snapshot of how things work today.
The ‘to-be’ blueprint is one of the next main service design artefacts. They switch the focus from the current state to the future state — prescribing how a proposed service should function going forwards. However, this snapshot will have to be updated as more is learned about the service over time — which is an evolutionary process.
For five reasons, the information in a to-be blueprint (by the end of Discovery) should be high-level:
- The initial research will demonstrate needs across multiple user groups, providing the foundation for how the existing service should change to meet them
- The understanding of the technology proposed to underpin a service will be indicative at this stage, and may not reference actual vendors/providers
- The blueprint is designed as a strategic document to portray a perspective into how the future state service could feel and work
- The blueprint should act as a communication tool to provide the evidence to stakeholders that a new service is required
- The blueprint only needs to demonstrate enough evidence about whether a service should be transformed (or not)
This means, instead of documenting every step of the service, the steps may be grouped into stages that contain numerous interactions/touchpoints, giving a flavour for who’s involved, the capabilities required and the overarching process.
Finally, the fact that the first ‘to-be’ blueprint is not prescriptive to the nth degree, allows the following Alpha team room to innovate and generate multiple solutions to test.
This is the highest-level blueprint, the one that provides the strategic birds eye view.
Example: Generating a ‘to-be’ blueprint in Discovery
When working on a Discovery with a central government department, our research covered many different types of user groups as well as existing physical and digital government services, many of which had clear pain points associated with them.
To rectify the issues experienced with existing services, over 100 ideas were generated through collaboration workshops and distilled into five discrete service concepts. These concepts articulated functionality that would help people better access specific information and keep up to date with changes that would affect them.
The blueprint demonstrated the main steps and touchpoints across the service — highlighting where new functionality supported user need. It also importantly providing direction for what could be prototyped in Alpha.
If we hadn’t created a blueprint at the end of Discovery, we wouldn’t have been able to show how the new functionality joined together to illustrate the end-end journey–the service ecosystem.
Breaking down the blueprint in Alpha
The blueprint will evolve through the phases of the design process. In the second phase, Alpha, the blueprint will be taken through its next iteration to provide the foundations for prototyping.
In Alpha, the team will decide which part (or parts) of the to-be service need to be explored in more detail to test the riskiest assumptions and validate hypotheses.
To understand exactly what to prototype, the blueprint will need to be expanded to get a better idea of the number of steps involved (which will demonstrate the initial user journeys).
This means taking the blueprint to the next level of granular detail. Exploring how each step can be broken down into specific tasks, to understand the level of functionality required–even dismantling the blueprint into multiple documents.
The result is the second iteration of the blueprint. A larger document (or set of documents) that represent the specific user journeys that people go through to complete their tasks. Joining up the customer transactions with business processes.
Once prototypes have been designed, tested, and iterated, the next job will be to update the blueprint and reflect how the service has evolved throughout Alpha.
This is the functional blueprint, the one that describes the detailed reality.
Example: Iterating a blueprint to provide explore the service design in Alpha
When working with a Scottish Government agency, we were looking to validate the need for a new service that would change how a sector is regulated.
The blueprint delivered in Discovery showed that there were a number of stages to the service, similar to the ones listed below:
- Pre-apply
- Consult
- Apply
- Assess
- Award
It was deemed that there were risky parts of the ‘pre-apply’ stage. This meant the blueprint had to be broken down to unpack the discrete journeys within this stage of the service.
This resulted in the breakdown of the Discovery blueprint into three separate (more detailed) Alpha blueprints. The new blueprints described:
- how applicants would upload large files
- how applicants would complete and submit a new webform
- how regulators would manage submitted pre-applications through a new workflow
These blueprints helped the interaction designer to get a better understanding of the number of pages, types of transactions and capabilities required to underpin the discrete journeys, and prototype the service to test its value.
The Alpha outcome was a validated set of technologies and discrete experiences for the pre-apply stage, providing evidence that the new frontend experience and backend technology met the needs of users and should move into Beta.
We wouldn’t have been able to prototype the riskiest parts of the service if we hadn’t been able to breakdown the blueprint into smaller discrete journeys.
Understanding discrete service journeys in Beta
Blueprints are really useful to onboard the Beta team. It’s crucial that new teammates can quickly understand the goal of the service, what needs to be built and how it will work. The blueprint is the most tangible artefact that explains the end-to-end service.
But blueprints do become less relevant in Beta…
At the stage of development and releases, the backlog will have more detail than the blueprint and will drive design and development in Beta. The backlog is a longlist of user stories that describe the known totality of the required functionality to be built. User stories are short descriptions of system features, written in the perspective of the user/customer or the system.
The blueprint will still need to be worked on in Beta, because there will be unknown elements of the service that haven’t been fully understood yet. This is because parts of the service may not have been prototyped during Alpha.
Like the Alpha activity, the unknown steps of the Discovery blueprint will have to be broken down into smaller discrete user journeys, so the tasks, interactions and flow can be explored in detail–this will include things like edge cases and error messaging.
It’s clearer step-by-step user journeys like these that will provide the direction for Interaction Designers and Developers to create detailed designs and clickable frontend code to be validated through larger scale user testing.
The design output based on the user journeys and evidence from user testing update the backlog with user stories for development. The blueprint may also be updated to reflect the most recent service design.
This is the final ‘blueprint’, a set of blueprints and journeys that are closest to the service that will be released.
Example: Breaking down a blueprint in Beta
When working with an executive agency of government, we were trying to launch a service that helped citizens better understand their eligibility to apply for a service.
The scope of this service was fairly contained, and only for citizens (there was no ‘backstage’ transactional part that the executive agency operated). So, the main artefact to describe the service was a ‘frontstage’ user journey — like the one pictured above.
As we were in Beta, the focus was on delivering the service through development activities. This meant everything was being driven by the backlog that had been prioritised, categorised, labelled and mapped to the user journey and needs of users. Therefore, in this case, the user journey superseded the need for a service blueprint.
So, what does this mean when developing service blueprints?
Blueprints aren’t a one and done artefact. They are dynamic, as the collective understanding of a service evolves over time through ongoing user engagement, prototyping and feedback loops. This means when following the Discovery, Alpha, Beta, Live process the blueprint will develop as you move through the design phases.
The Discovery blueprint will likely be the most high-level, as it’s the first articulation of a future service based on initial research, and yet to be explored through design techniques.
This first iteration is the single artefact that communicates the intention for the service transformation, and provides a talking point to gain endorsement to take the project to the next phase.
The Alpha blueprint will be more detailed. With specific a lens into parts of the service that need to be tested through Alpha. Meaning the original Discovery blueprint may be broken down into separate documents that allow the team to better define discrete journeys.
The Beta blueprint will help new joiners to the team, but following onboarding, the blueprint will be superseded by the backlog to drive development.
The blueprint still needed to be broken down even further into detailed user journeys (like in Alpha), so the steps and interactions users go through can be designed and built — with further scrutiny around logic flows and edge cases.
Ultimately the service blueprint is a communication tool that provides the direction for design and development teams to deliver tangible service designs to the end user. As long as the blueprint is clear, unambiguous and prescriptive, it will provide the value needed to support the design process.
In my next blog, I’ll talk more about building a service blueprint from scratch.
Key take-aways
- Service blueprints are evolving artefacts that grow through the design process, based on how much detail and context is required to communicate the service at each phase
- As-is service blueprints illustrate an existing service
- To-be service blueprints show what a future service could be
- A service blueprint is ultimately a communication tool — used to explain how things will work to team members and stakeholders
- It’s ok to for the first blueprint to be quite high-level, as Discovery is a strategic phase of the design process
- Breaking down a Discovery blueprint into multiple blueprints or user journeys is a good way of exploring detailed parts of a service–especially if they need to be prototyped or built
- Blueprints are throwaway — they are just being snapshots in time or representations of the future. When you have created that future, they can become redundant
- Backlogs supersede blueprints when it comes to the build phase, as user stories are a better mechanism for development
