A space for Service design

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.

That's my 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:

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.

Blurred lines

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.

Is it all about positioning?

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.

Looking sideways

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.

Back to definitions

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:

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:

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.

Service design in Defra

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.

Feasibility study or Pre-discovery

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:

• gather existing insight about the users of any current service and high-level pain points
• align proposed work to strategy and program vision
• work with the team to define the problems we are trying to solve
• work with the team to define the outcomes we want to deliver
• work alongside Business Analysis to understanding the people, processes, and data involved in any as-is process
• create as is user journeys, highlighting pain points, dependencies, areas for improvements, and hypothesis to test
• frame and create problem statements for discovery

New programs of work

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:

• develop a strategic vision for the service
• design the interactions and building blocks that make up the service
• create service prototypes to test ideas and assumptions
• understand user needs and track interactions across departmental and organisational boundaries
• influence performance reporting so we measure and target improvements to things that matter to users
• lead on ensuring that interactions and user journeys across the program are rational and consistent

Existing programs of work

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:

• align and lead communication with service managers, product owners, and policy colleagues to define user journeys and articulate the vision for products and services
• visualise/map existing products and processes, highlighting inconsistencies, inefficiencies, dependencies, pain points, and dead ends
• visualise/map relationships between different products or sub-services
• identify opportunities for service improvement and cost reduction
• identify opportunities to align internal processes
• identify opportunities to align our services with user journeys and tasks
• lead on ensuring that interactions and user journeys across the program are rational and consistent
• understand user needs and track interactions across departmental and organisational boundaries
• influence performance reporting so we measure and target improvements to things that matter to users

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.

Share on Twitter