Our aim over this parliament is to transform the relationship between the citizen and state: to transform government, together. Service design is a big part of how we plan to do that, so it seemed timely to give a short outline on what we mean by it.
What we mean by service design
First, let’s be clear - service design is the design of services.
To a user, a service is simple. It’s something that helps them to do something - like learn to drive, buy a house, or become a childminder.
However, search online for service design right now and you’ll find a seemingly endless array of ‘toolkits’ and ‘design processes’. Five circled grids. Double diamonds. Mental models. You’d be forgiven for thinking that it was about the process of design, rather than changing outcomes for users.
This is changing though. Service design is moving inside organisations, and inside government. For us, service design isn’t about mental models or double diamonds. It’s about working with users and delivering services.
Redesigning services in government is difficult
Government is the UK’s oldest and largest service provider - providing services is our main function. Just as if your business was making chairs, you’d hire a furniture designer - government needs service designers to design services.
With that history, comes challenges. Government services are sometimes split into tiny pieces: lots of isolated transactions, products, and content provided by different parts of government that need to be used together by a user to achieve their goal.
Service design is the activity of working out which of these pieces need to fit together, asking how well they meet user needs, and rebuilding them from the ground up so that they do.
It’s not complicated, but it is hard.
There’s lots to be done
Government delivers a lot of services - it’s what accounts for the majority of our spending.
If these services aren’t immediately understandable and easy to use it can confuse users and lead to mistakes being made. This increases casework and phone calls for government - and the amount of time spent by users trying to fix their problem. All of this costs money.
Basically, bad services are expensive and require more time investment from the point of the user. This has a knock-on impact on user’s ability to do to other things and the economy itself.
The other unwanted consequence of bad service design is that we neither meet a policy intent or a user need.
That’s why we’re interested in service design.
Common problems
Unfortunately, the operational needs of government often overshadow the needs of the end user. It’s not surprising - operating government services in a digital age is hard work. Especially given that the way our services work largely has its origins prior to the adoption of the internet, and in some cases computerisation.
But just because something's hard, doesn’t mean it can’t be done.
Good services should reflect what the user wants to do and don’t require a working knowledge of the inside of government to use. As I’ve written before: good services are verbs, bad services are nouns.
Quite often that means interacting with more than one part of government to get something done, meaning that users have to act as go-between, working out how multiple licences, forms or regulations relate to their needs and sequencing them appropriately into a ‘service’ on their own.
How we work
Digital capability in government has grown beyond all recognition in the recent years.
Alongside other important digital, data, and technology skills, there are now over 300 designers in government - a mixture of service designers, interaction designers, and graphic designers.
Service design is a relatively new addition to this. I was one of the first back in 2014 and since then we’ve developed a new generation of service designers who’re moving inside government to get close to hard problems and design solutions to fix them at scale.
We work fast and we make things in code - not wireframes or diagrams. We test our assumptions through research. It’s the results that matter - better services.
Given the vast, defracted nature of pre-internet services - the job of a service designer in government is 90% archeology - finding out which transactions are involved in which user need, what their original purpose was and whether they’re still effective at doing that.
The next 10% is a lot harder - stitching them together into a coherent service that a user can use unaided.
The work of government service designers is informed - and often driven by - digital but we don’t exclusively work building websites or digital things. Some of the biggest challenges in service design are in the transitions between physical, offline, and digital transactions.
We design whole services:
- from end-to-end: this means from when the user starts trying to achieve a goal to when they finish - including both content and transaction agnostic to the department providing it
- from front to back: this means the user-facing service, internal processes, supporting policy or legislation and organisational, financial and governance structures of the service
- in every channel: digital, phone, post, face to face and physical elements
How we’re scaling up
With so many services, our biggest challenge is how we scale.
Just as we’ve used interaction design patterns to speed up how we deliver online services, we’re now starting to develop service patterns. These are ways of identifying and standardising commonly-used transactions, so that when teams are building a service they can reach for off-the-shelf solutions to common problems and save their energies for focussing on difficult, unique problems.
But we can only get there together. At GDS we’re working with the rest of government to formalise the design profession to do that. We need more designers in government, and more friends and allies for them to work with at the very top of our organisations.
I’ll talk more about this in another post.
Follow #ServiceDesign this week
We’re talking about #ServiceDesign on social media for the week, sharing lots of new videos, case studies, images and blog posts.
Join our live Periscope Q&A where I'll be talking about service design in government and taking your questions. It's on Thursday 21 April at 11.30am. See you there.
3 comments
Comment by Peter Parslow posted on
About half way through before realising that this is about services in the computer / web sense, not the normal sense of 'government service' which I would argue is about delivering human interaction, e.g. home care, youth counselling.
The give away is where you say "we make things in code".
I believe there are lessons to be learned form this 'service design' (ITIL for example) for the human services too. But I guess that's not GDS?
Comment by Colin Foley posted on
How does GDS see the roles of business architecture and service design working together most effectively?.
Both seek to work at from end-to-end and from front to back. Both are relatively new to government. Both have a lot to offer in terms of customer focussed, value for money delivery.
However, there is overlap in the rhetoric (incl in this post) and in practice. How do you see those approaches working together in unison?
Comment by Tom Wynne-Morgan posted on
@colin, my answer would be that the approaches are not at odds, so there is no question of how they work in unison.
As i understand it, business architecture is about describing an enterprise's governance structures, business processes and business information in order to align strategic objectives with tactical demands. This, as you say, is a scope that requires end-to-end and front to back thinking.
However, this does not address the full picture or go into requisite detail in order to be truly people centred or agile and iterative.
Services get designed and implemented through the application of a range of techniques, skills and methodologies. I think Business Architecture is a part of that design/implementation as much as User Experience (UX) design is, for example.