Is this service design?

As Lou Downe said in What we mean by service design:

But how do we design better services:

• in areas with conflicting or competing priorities?
• in areas with multiple leadership teams?
• with a reliance on politics?
• across different competent authorities and government departments?

When this is the case, hiring service designers into existing teams or structures won’t help us to change the things we design and build.

Defining design

Before we hire service designers we need to…

1. Define what we mean by a service
2. Define the role of the service designer
3. Define the spaces in which service designers should work

This work is covered in more deatil in previous blog's A space for service design and Designing whole services. Once this is done we should be able to hire service designers into the right spaces and onto the right work.

But what does that look like in practice?

Getting started

Joining an existing programme of work is like jumping onto a moving train, or 7 moving trains all going in different directions.

The programme I work on includes 6 main services with each having up to 400,000 transactions per year and around 5 core supporting services, products or platforms. The programme sits under 2 different directorates, multiple competent authorities and across multiple government departments. In total across the programme there are over 10,000 variants of end-to-end journeys.

Understanding our users

The first thing I wanted to do was try to get an understanding of who was using the services, what they were trying to achieve and how. To do this I ran a workshop to get all the researchers on the programme together, to discuss each service and to get all our known user needs out in the open, highlighting any gaps that might need filling.

The 2 key takeaways from the workshop were:

• We had areas of work with no user research or design presence
• In a lot of cases the user needs we had were quite product or feature specific

This doesn't help us to understand what users need from our service away from existing systems or technology.

Understanding our service

The second thing I wanted to understand was the whole service as it is now from start to finish. This includes things that happen before and after the parts that we can control.

These maps helped us to spot patterns in behaviour, things that could be improved, areas of complexity and how different systems are, or are not connected. They are also useful to understand the flow of events or the relationships between events which should inform any service design work.

By mapping these journeys we can start to see areas of duplication and places where we could start to build some common capabilities. We’re not re-designing anything yet, but working out how we could incrementally improve what already exists.

Another key output of the journey maps is highlighting gaps in knowledge and using this to help plan future research activities.

Creating the right conditions

Most of the work that came out of these 2 exercises was about trying to create the right conditions for a service approach.

Building a community

Starting with some obvious things like building a design and research community. We introduced some regular programme wide community meetings, show and tells and drop in sessions. Making sure people are aware of other projects and able to share insights and design work across teams.

Increasing capability

I ran sessions on user centred design, the service standards and accessibility to raise awareness of the value research and design bring to teams. This has helped us to grow the UCD team and to get people on to the projects and teams that had previously had no research or design input.

Process maps

The next thing I did was create some process maps or low-fi blueprints to help teams understand how their services fit into a wider system. The maps helped to identify dead ends in proposed new service, offline journeys, and areas teams would need to consider designing new business processes.

This was intentionally quite provocative to try to change the way people viewed the things we deliver.

Taking a broader view of user research

The most important thing was trying to take a broader view of user research. To start thinking about our service as a whole we need to understand our users and their needs away from the constraints of what exists already.

Getting broader insights is the starting point for moving teams away from building something the right way to making sure we are building the right thing. And for positioning research as something that guides decisions instead of validating (or not) decisions that have already been made.

To help with this we introduced a research framing process and roadmap to re-frame requests around the problems that needed to be solved. This helped us shift requests from “Can I have a researcher to look at APIs” to “How can we improve the application process. This is about delivering better research, not hiring more researchers. Fewer people doing the right research is better than lots of researchers validating existing ideas.

One of the biggest benefits to come out of doing this was highlighting how often we commissioned the same piece of work in different teams with differing ideas on solutions.

Is this service design?

None of this work feels like service design, its mostly been about building an understanding of the service, the people, the teams, and the ways of working.

Going back to the definition of service design

Incrementally improving what exists is valuable work, but can only ever go so far, particularly if what exists includes services or systems that exist because of failure elsewhere. At some point we will need to take a fresh more holistic approach and start to actually re-design services.

Unfortunately when or if this happens is usually out of our control.

Laying the foundations

What we can do is make sure when that time arrives we’re in a position to effectively communicate what our users are trying to do, what issues they face and how we might be able to improve things for them.

We started to do this by collecting insights with the broader research pieces discussed earlier and through some exploration work, pulling together users, systems, pain points, and opportunities helping us to create high level themes and problems to solve. These insights can be shared across the whole programme to help us to start thinking about the work as one whole service.

As well as preventing the need for each team to re-do this work, it also gives us a reference point to keep returning to. Is the work we are doing solving these problems? These artefacts should be the foundations for any future service design, strategy or vision.

Service blueprinting

A service blueprint or to-be map of the service may have been useful to start much sooner. But if no one is asking for one where is the value? We need everyone to recognise what we are delivering as one whole service, before we start to map out common touchpoints, interactions, and areas where we might introduce common capabilities.

One of the biggest benefits in producing a blueprint is the process itself, waiting to be asked to produce one means we have a cross team understanding of how the whole service cuts across multiple deliveries, and more chances of getting the right people involved in co-creating one. After 12-months working across this service, we are only now starting to map the full end to end, with all the touchpoints, technology, data, people etc. Working alongside policy and programme team members from 2 different directorates.

Project scoping

The second part of the deffenition was project scoping, this stage is about establishing the problem/costs/issues that you want to look at. So as service designers we should work with the business and policy upfront to understand what we have, define the problem(s) to be solved, and the desired outcome(s).

Just jumping back to the programme level work for a second, the biggest blocker to getting stuff done in that space is meetings. It’s really easy to end up in an overseeing role sitting across somewhere between 10 and 15 teams. And that quickly turns into a really reactive role, dealing with issues as and when they arise.

The questions we should be asking are:

• why are there so many teams?
• why is there so much work?
• and where is all the work coming from?

To get a grip of it we need to look at the way work is designed and managed. The research framing process I mentioned earlier was a useful stepping stone for this but it’s still reactive work, re-setting briefs that come to us from various sources.

Current landscape

As much as we might want to position ourselves as a partner, the role of service design sits under digital and is almost always seen as a supplier. And as a supplier we react to requests for work. Because these requests come from multiple places it’s possible for us to get competing requests, duplications and contradictions.

To really start to design whole services we need to be more proactive, we need to move from being a supplier providing a solution, to a partner working collaboratively to shape work around problems or outcomes.

Moving from “Here is something we want you to build” to “Work with us to understand the problems we should to address” requires the process of how work is created to be re-designed. This is something we have started to do by first capturing the as-is process and using that to create a future state.

Triage process

In the new process the first thing we did was add a triage step, to shape requests for work, aligning them to the wider strategy, defining the problem to solve and the desired outcomes and success measures.

Triage questions:

• What is the problem to be solved
• Short background to the problem space, team etc
• What are the expected outcomes
• What work has been done to date?
• How will we measure success?

This should help us to get service design involved further upstream, and to create consistency across the programme, removing any duplication and contradictions.

Then we split work into 3 lanes:

1. Discovery, because there is a well defined problem to solve
2. Continuous improvement, we have a valid problem but the work is better suited to being added to an existing teams backlog
3. Exploration, this problem is too big for us to solve all at once

The first 2 are pretty self explanatory, the third one can be a bit more controversial.

Exploration or pre-discovery has a reputation for adding time and cost to a project without adding much value. I’ve definitely seen this happen and we definitely dont always need this phase. But if we have a statement as broad as “How might we better facilitate trade” we need space to break the problem down into more manageable chunks.

A good exploration phase should be short, with a small team, it could be:

• a problem framing workshop
• a short piece of work like a design sprint
• or a phase of exploratory work that might lead to multiple problem statements that need to be prioritised

Exploration is done when we have a clear and well scoped problem statement(s) to tackle at discovery.

The final part of the process is the feedback loops, making sure research and learnings in the teams make their way back into the process to help prioritise future work.

Summary

Designing and delivering better services is about having a shared service vision and outcomes, aligning around problems to solve, and continuously measuring value. This isn’t something that succeeds or fails based on the inclusion of any individual role.

Simply having a service designer won’t remove any of the barriers to good service design. Most of the work is aligning and working together with the right people in the right space, whoever and wherever that might be.

Some of the key takeaways have been:

• there is a constant balancing act between improving what exists and planning for what could exist
• before we can really progress we need to design our internal structures and design a process for how work is created and delivered

Share on Bluesky

Share on Twitter