A space for Service design
Published on
A follow-up to blurred lines and job titles this time looking at some of the crossovers and myths around Service design in Government.
Published on
A follow-up to blurred lines and job titles this time looking at some of the crossovers and myths around Service design in Government.
Published on
In April 2019 I wrote blurred lines and job titles. It was about the blurred lines between design and front-end development roles as well as constantly changing job titles.
I focused on what was a hot topic at the time thanks to the post Front end design by Brad Frost.
Brad’s post matched my career almost perfectly, switching between user experience design and front-end development but never feeling completely at home in either role.
The short version is I ended up an interaction designer, and everything clicked into place.
That was then.
In the post I stopped at Interaction design, I could have gone one to talk about the emerging crossover in my working world between Interaction Design and Service Design.
At the time I felt under qualified to comment on Service Design as a role in Government (I still do actually). But the definition of each role is becoming more and more ingrained in my day-to-day job.
Hard lines and ring-fenced roles create resentment, nobody likes being told what they are, or are not allowed to do.
A lot of my early experiences of Service Design in Government were of people talking about end-to-end journeys, offline channels, and joining things up. None of this was anything I hadn't thought about before. I’ve certainly never willingly designed just the digital interface of a service and left the rest to sort itself out.
The emergence of the Service Design role rightly or wrongly created a little bit of fear, fear of becoming just that person that prototypes the digital bit.
The DDaT definitions define the two roles like this:
An interaction designer works out the best way to let users interact with services, in terms of both overall flow and at the level of individual design elements.
Service designers design the end-to-end journey of a service. This helps a user complete their goal and government deliver a policy intent. Their work may involve the creation of, or change to, transactions, products and content across both digital and offline channels provided by different parts of government.
These two definitions are similar which can lead to people announcing they are able to do both. Or one of my favorite and probably more accurate descriptions of occasionally wearing a Service Design hat.
This is not necessarily a problem on its own, but it is a problem when you need to clearly explain these roles to non-designers, create job descriptions, and recruit people.
It’s also hard to sell something that we can’t pin down and we are definitely still in the selling phase.
A lot of jobs I see are looking for service designers to join a Discovery phase, to design the end-to-end journey of a single transaction, or to map out existing services.
If the project is a single transaction like applying for a permit ‘end to end’ can be covered by Interaction, Content, and User research. When service designers work on neatly scoped transactions or discoveries there will be a lot of overlap.
There are also fairly obvious benefits to the person doing the design being involved in understanding the problem their design will aim to fix. Using Service Design in Discovery can therefore create problems if they later throw that research over the fence to interaction designers in Alpha. There's that fear of being the ‘prototype builder’ again.
When it comes to mapping a lot of the issues I’ve encountered have been specifically about who is responsible for mapping as-is or to-be journeys.
As much as I understand the links between Service Design and mapping it might help if we could do more to articulate why maps are produced and emphasise the service prototyping and touchpoint design elements of the role.
If Discovery is the stage where teams start exploring a problem space, someone somewhere will have already made decisions about what the problem to be solved is. This is the part where I think service designers can add more value, working outside of the research space before Discovery to understand the relationships between existing services and processes highlighting inconsistencies, inefficiencies, dependencies, pain points, dead ends, etc. And then helping teams identify what should or shouldn’t be worked on.
To put it simply service designers help frame and diagnose the problems to solve. User research leads on understanding those problems more deeply, interaction and content designers take this understanding and use it to create useful solutions.
By involving service designers earlier in the process, we can reduce risk by ensuring we solve the right problems, avoid duplication and avoid service silos.
By working across products and sub-services we can start to solve problems that sit outside the normal remit of Interaction and Content Design. Helping us to build context and highlight organisational/structural issues that prevent good service outcomes.
There will always be crossover tasks with many other roles because Service Design is horizontal looking sideways across multiple pieces of work.
We can reduce the friction with clearer descriptions of what service designers do and more importantly the spaces they operate in.
Could we do better with the definition of Service Design? And would that help us to more clearly differentiate the role from User Research, Interaction Design, Business Analysis, and others?
I started trying to list out responsibilities of service designers in the Discovery, Alpha, and Beta phases, something we’d already done for Interaction Design, but it wasn't really making things any clearer.
That's probably because Service Design doesn't fit neatly into that delivery cycle.
One of my favorite Service Design definitions is this:
The majority of products that we encounter are actually part of a larger service network. In some cases, those touchpoints have been designed. But in many cases, they have just happened organically, with no thought for the whole picture. That’s where service design comes in.
This relates to a lot of government services that are already in existence and formed organically around the organisation's structure, data sets, funding silos, etc.
Another is problem framing leaving the problem solving to Research, Content, and Interaction design:
look at new upcoming initiatives, customer problems, and goals and to be able to identify what should / should not be worked on as well as ensure all the dots across the business are connected
This relates to the upfront work needed to shape future projects to be worked on as well as making sure everything we do ties into what has already gone before and a shared program vision or goal.
The definition we are starting to use is...
A service designer makes sure we design and deliver the right service. They work in program teams that may support multiple product teams. They also work in the space before Discovery shaping and scoping future work.
Program teams:
Services as end-users would know them transcend delivery or product teams. Service designers work across a program of work to design the interactions and building blocks that make a service.
Project scoping:
This stage is about establishing the problem/costs/issues that you want to look at including the people and skills you are likely to need for Discovery. A service designer will work with the business and policy upfront to understand what we have, define the problem(s) to be solved, and the desired outcome(s).
Using this definition we can start to describe what service designers do outside of the usual Discovery, Alpha, Beta phases.
Working alongside Policy, Business Analysis and Architecture to understand the main business drivers, problems to be solved, and desired outcomes before moving to Discovery.
A service designer will:
Slightly different from the more common existing set of products and sub-services. Sometimes new policy, legislation or incentives mean we need to create new services.
In this space a service designer will:
Service designers work within existing programs to help connect discrete digital projects to deliver a joined-up service vision, provide cost efficiencies, and increase the effectiveness with which end-user benefits are delivered.
A service designer will:
We’ve been using these definitions and role descriptions to create new roles in Defra and to help explain how Service Design differs from other professions.
It’s early days and we’re still learning but through these roles, we are starting to demonstrate the value that can be brought to new and existing programs of work by creating the right spaces for Service Design, hopefully without stepping on anyone else’s toes.
These are webmentions via the IndieWeb and webmention.io.