
When it comes to strategic thinking in the delivery of complex digital services, my mind defaults to the classic trope of a famed college library sinking into the ground because its architect failed to take the weight of the books into account. It's a simple myth, but it reminds us that architects wouldn’t build a building without understanding how everything from, and in between, the roofing tiles to the shrubbery could impact the people who use it. So why should the creation of digital services be any different?
This is why frameworks and tools that help visualise complex digital services are a key part of my work as a service designer at HMRC Policy Lab. I use them extensively with policy and technology teams to provide a new way of understanding what a service is meant to do, define the resources and capabilities needed to deliver them, and then identify the key transformations needed to get there. They are fantastic levellers, contain a myriad of perspectives and ultimately, enable us to think strategically about the services we are creating and how to deliver them.
This article is both a breakdown and a reflection of the use of service blueprints and Wardley maps in the early development of public digital services in my work at HMRC Policy Lab.
In 2011, the introduction of the UK’s Government Digital Service (GDS) kick-started a change in how public digital services were being designed, developed, and delivered. In order to dramatically improve digital services for citizens, it turned the default technology-first approach ingrained into government on its head and looked to transform government from the 'top-down' by identifying common citizen outcomes across siloed services and build capabilities that could be reused across them (think Notify, One Login and Pay).
Naturally, this required the introduction of a whole host of professions and skills to navigate the complexity of government, with the emergence of Policy Labs in 2014 becoming a spearhead for user-centred thinking. Since then, the role of Policy Labs have evolved across government departments.
At HMRC Policy Lab, we focus on helping policy and technology teams centre their thinking around outcomes for citizens – exploring what they are trying to accomplish, not just what the government (as the service provider) needs from them – before then helping define the digital capabilities needed to deliver an effective digital service, efficiently.
Put simply, as a strategic exercise, we help policy and technology teams by defining the make up of digital services from the ‘outside in’. Focusing on what citizens need to accomplish before then looking inwards to define what capabilities the service requires and the direction and types of change needed to deliver them.
This is where blueprints and maps come in. The UK, in particular, is a labyrinth of legacy infrastructure, long-term technology contracts, and a countless number of monolithic programs of technological change that duplicate effort both within individual departments like HMRC and across them. Essentially, there's a lot to navigate, a lot to know and even more that's been forgotten.
Service blueprints and Wardley maps, as outcome-focused tools, create a 'complete picture' of a service. They not only drive the typical user-centred design processes of capturing user needs, identifying pain points, unintended consequences, and opportunities, but also act as artefacts that facilitate the collection of knowledge from across the organisation to create an understanding of how the service might be delivered over a period of time.
Fundamentally, they allow us to view and navigate the system of a service to identify significant interventions, make strategic decisions about how services should be delivered to citizens, and facilitate discussions with policy and technology teams through a shared, common language.
That’s enough context and theory though. Let’s get into some specifics.
Service blueprints are a powerful tool. I've used them for everything from presenting a high-fidelity futurestate service to a board of directors, to prototyping concept journeys with users and co-designing with tricky stakeholders.
At their core, they help us better understand the complexities and resources required to deliver a service. They create a single visual source of truth for what users are trying to achieve and how they experience it, enabling us to build an understanding around everything that's involved in delivering the service; from operational and frontline teams to technical capabilities and the data required to enable them.
Creating a service blueprint
I find that the creation of service blueprints is initially best done in small, fast-paced workshops with key stakeholders from policy and technology teams. Once this core set of stakeholders has had an opportunity to inform a first version of a customer journey, I then start to use this as a draft recommendation to provoke and gather knowledge with a broader set of stakeholders from across the organisation – identifying them based on their expertise, as appropriate.