Skip to main content

Service Blueprinting

Posted on Tags: service blueprint

What is a service blueprint?

A service blueprint provides a comprehensive overview of how a service and its related experience are delivered, end-to-end, front-to-back, and across various channels.

It is a diagram that visualises the relationships between different service components, including people, physical or digital evidence encountered by users, and processes directly tied to steps in a specific user journey.

It builds on a user journey map (which visualises a user’s experience when using a service), adding the ‘frontstage’ and ‘backstage’ people and processes involved in delivering that service to the user, as well as internal supporting processes.

Why do we need a service blueprint?

  • It assists in understanding the various aspects of a service, such as service administration, offline parts of the journey, and offline users.
  • It serves as a valuable basis for discussions with potential service owners/operators.
  • We need to consider solving a whole problem for users, and providing a joined up experience across different channels. Mapping the entire service, along with connected services, helps identify all potential touchpoints and their necessary interactions.

Evolution of the Short-Term Lets Register Service Blueprint

Throughout this Alpha phase we have been iterating on the service blueprint during collaborative workshops, as well as weekly blueprint updates with members of the team, to facilitate ongoing discussions and inform decision-making.

Photo of the team’s first collaborative service blueprinting workshop at Made Tech’s London offices. It shows 5 members of the team in a meeting room gathered around a large printout of a draft service blueprint stuck up on the wall. 1 team member is writing on a sticky note on the printout.

Initial draft

We started by creating an initial draft based on insights from discovery, early user testing, and assumptions about the service’s functionality.

This draft was divided into three main phases: pre-registration, registration, and post-registration.

Each phase was further broken down into subphases. We included user actions, online/offline interactions, and potential processes for various stakeholders.

Screenshot of the initial draft of the service blueprint, which we reviewed during the first blueprinting workshop. It shows Phases (Pre-Registration, Registration and Post-Registration) across the top, with Sub-phases, Main User Actions, Online and Offline Interactions in 4 rows of sticky notes underneath. Down the left-hand side there are 5 groups of swimlanes: User Experience, Frontstage Touchpoints, Backstage Touchpoints, Internal Interactions and Other Considerations. Within each group of swimlanes there are several rows of differently coloured sticky notes, representing the actions of different stakeholders potentially involved in the service (e.g. Booking Platforms, Local Authorities), systems or considerations at each step in the service.

Version 1

During the first workshop in Sprint 2, we discussed the ‘Pre-Registration’ and ‘Registration’ phases in detail.

We ran this as an in-person workshop, to make it easier for lots of people to contribute to discussions and thinking around how the service will work, and to enable easier initial review of the already wide and tall blueprint.

Key points discussed included:

  • The importance of stakeholder involvement in raising awareness among users about the new regulations and their responsibilities
  • The potential need for a “Becoming Compliant” stage before registration, and potential delays in the registration process due to compliance requirements
  • Questions around the assisted digital journey and how that would be administered
  • The potential need for an internal service to enable users of the data collected to access that data
  • The possibility of a phased rollout approach to mitigate risks and ensure a smooth transition

Version 2

Throughout Sprint 2, we continued refining the service blueprint by:

  • Adding new sub-phases for ‘Becoming Compliant’ and ‘Validation’ to reflect previous discussions
  • Adding detail to steps discussed in the first workshop
  • Capturing questions and actions coming out of the first workshop, and assigning these to team members
  • Incorporating new insights from stakeholder interviews, including booking platforms, Visit England, the Scottish Government, and other government departments (OGDs). These insights covered areas such as awareness-raising, data usage, and potential challenges with compliance and registration validation.
Screenshot of Version 2 of the service blueprint. It includes additions from the first blueprinting workshop, such as additional sub-phases, additional details for steps discussed in the workshop or from insights from various stakeholder interviews, and questions (in red text). It no longer includes the left-hand side groupings of swimlanes, but still has differently coloured swimlanes for different stakeholders’ actions, and Supporting Processes and Systems, Data, Metrics and Other Considerations in grey swimlanes below.

During our 2nd Blueprinting Workshop, we reviewed Version 2 of the blueprint, concentrating mainly on the ‘Registration’ phase:

  • We discussed the user journey on GOV.UK
  • We explored assisted digital and offline options
  • We discussed the complexities of compliance validation and enforcement

These discussions highlighted the need for a simplified blueprint, to facilitate stakeholder communication and address questions around service ownership and administration.

Version 3

Between Sprints 2 and 3, we developed a simplified “1-minute” version of the blueprint to facilitate discussions with stakeholders.

This shows at a very high level what the main user actions are across the service, and the role that different stakeholders might play at each of those interactions.

As part of this overview of the service, we have kept the service owner and admin deliberately separate from the rest of the actors, in order to show the additional actions that whoever administers this scheme will need to be responsible for.

Screenshot of the ‘1-minute’ version of the service blueprint. This shows a simplified version of the blueprint, with 7 Phases along the top row, and 7 coloured swimlanes below the phases. These swimlanes feature high-level actions (represented by small circles, joined by straight lines), for 7 different actors or stakeholders in the service: Service owner and administrator; Short-term owners and operators; DCMS; VisitEngland; Local authorities; Management companies; and Booking platforms. It does not include the Supporting Processes and Systems, Data, Metrics and Other Considerations swimlanes.

Version 4

During Sprint 3, we continued iterating the blueprint based on insights from additional stakeholder interviews and findings from the second round of user research.

As the blueprint grew in complexity, we split the original 3 phases into 6 main phases. This included dividing the pre-registration phase into ‘Awareness’ and ‘Preparation’ to distinguish between the various steps involved in communicating the scheme and users preparing for registration. Similarly, we split the post-registration phase into ‘Confirmation’, ‘Operation’, and ‘Continuation’ to capture all the steps and actions covered within them.

We focused our conversations around outstanding questions about compliance requirements and validation, leading us to continue exploring the possibility of a staggered rollout as a potential solution to these challenges. We formulated a new assumption relating to this staggered approach, and decided to test its viability by creating a version of the blueprint that adheres to this model, allowing us to gather feedback from stakeholders.

We developed Version 4.2 to reflect this staggered approach, eliminating the stage for compliance validation and checks during Phase 1. Instead, the ‘Awareness’ and ‘Preparation’ phases are leveraged, to educate users about their responsibilities and ensure they are ready for compliance enforcement during Phase 2.

In Sprint 4 we brought the team together in person again for a 3rd workshop, to review Version 4.2 and discuss in more detail the final phases of the service, ‘Confirmation’, ‘Operation’, and ‘Continuation’.

We updated the blueprint again following this workshop; and subsequently discussed identity validation, payment by offline users, and the potential steps for a management company completing the registration on an operator’s behalf. The question of who’s legally responsible in this scenario for the details provided in the registration (including ensuring compliance to the listed health and safety requirements) is something our policy colleagues will need to grapple with in due course.

During Sprint 5, we further refined the blueprint into Version 4.3 by incorporating additional insights from local authorities, focusing mainly on their role within the scheme, as well as the offline journey and support for residents needing digital assistance.

We also added insights from management companies, particularly on their involvement in the early ‘awareness’ and ‘preparation’ stages of the journey, and the journey for them registering on behalf of their clients.

This latest version also includes additional considerations for subsequent rollouts, including plans for the beta phase.

Screenshot of Version 4.3 of the service blueprint. It reflects the ‘staggered’ approach, so no longer contains the ‘compliance’ sub-phase. It includes updated details across all swimlanes, reflecting discussions in the third service blueprinting workshop and subsequent conversations, and further insights from local authorities and management companies. It also includes additional considerations for subsequent rollouts.