Standardising, not centralising
Service design patterns for local government in the UK
by Lizzie Bruce and Sanjay Poyzer
The UK Government Digital Service (GDS) exists to transform the relationship between citizen and state. We’re at the centre of government, but don’t look like you might expect a government body to — there’s post-it notes everywhere and we throw around words like ‘digital’ and ‘agile’ like they’re going out of fashion. But of course these buzzwords and neon notelets are just the veneer. What we’re doing is helping government provide better public services. Services that are inclusive, adaptable and built for users.
Government is very big, and it is very old
5.4 million public sector employees help deliver hundreds, if not thousands, of services across the UK. The figure’s a bit less daunting if we focus on central government, the departments delivering national services and policy. That’s just under half a million people. So, when GDS was formed 6 years ago, we focussed on central so that we could scale up to have big impact fast. Now we have more than 800 services on GOV.UK, many with millions of users, run by agile service teams. And costing millions of pounds less than their offline predecessors.
The missing piece is local government. In the UK 418 different councils deliver local services. Services needed in different parts of the country vary, and councils manage their own budgets, so historically there’s been no national policy on running them.
Before the internet, you’d interact with local services by going to your town hall, library or equivalent. Now things are different. People expect to be able to interact with government online. That means all these local governments across the UK are solving the same digital design problems again, and again, and again…
In central government, we solve common problems once. We use shared components and design patterns. Shared components are parts of services we build centrally. GOV.UK Notify sends texts and emails, GOV.UK Pay allows services to receive payments from users, and GOV.UK Verify lets users prove their identity online. Building these components centrally mean we can invest design and research time into making them work really well for lots of services. And service teams can focus on getting their service right.
Design patterns are the agreed best practice way of solving a design problem. Patterns like ‘Check before you start’ — where, instead of making users read complicated eligibility rules, we ask people a few questions to check if the service is right for them before they start. We’ve got patterns like this being used by hundreds of teams across central government.
New frontiers
This year I joined a team looking at how local government could start using patterns and components. It was a new frontier for GDS and we went boldly etc. We expanded the concept of design patterns from being a common way of designing a small part of the service, to the whole end-to-end journey. In other words we created ‘local government service patterns’. We’re pretty excited by the idea, because it represents a big shift in how local governments could work, both in the UK and worldwide.
The idea is simple: if you apply for a parking permit, book a bin collection, pay your council tax or whatever, the process you go through should be similar across the UK. It’s not that the design is standardised for its own sake, it’s the best way to deliver that service.
So this sounds sensible. But if there’s one thing I’ve learned from working in government, it’s that just because something is sensible, it doesn’t mean it’s easy to do.
Starting with needs
At GDS, we always start projects off with a Discovery phase. We do user research to get clarity on the needs for the service and we do some business analysis to find out what can be achieved. The aim is get to a place where we can make informed hypotheses about what the service looks like, and then test those hypotheses with prototypes in Alpha.
We’re pretty comfortable with this way of working, but it’s a little bit less common in local government. Research and design is seen as part of delivering the service, which of course it is, but the problem comes from service delivery being outsourced. Which means historically service design and working out what the service should actually do have been handled separately, with only the latter being done internally. More pressingly for our project, it’s left local government without much skills or experience in doing research or design.
When it came to establishing our first local government service patterns, we knew we had to change the paradigm. It wasn’t the case that local government service managers didn’t want to do research and design, they just didn’t have the right set up for it. So we provided training in research techniques, and encouraged them they to talk to real users. The result? Our group of 17 councils interviewed over 150 people. The team at GDS then collated that research, looking for commonalities and differences.
What we found was that across the country these services were far more similar than they were different. That means we could use this shared research to design a service that worked for all of the councils, with variations where relevant.
As we moved into Alpha, we built a digital prototype for the fictional council of Argleton. After one round of user testing on this version, we got the councils to add their design, to brand the prototype like their own website. We also added any local variations needed due to local policy or technical constraints. For example, one council only allowed residents to have one parking permit each. Other councils allowed many, but wanted to make sure users owned the vehicles they were buying a permit for. This is where things got really complicated…
Our users are colleagues, not customers
Let’s take a step back. When we first dreamt up these end-to-end patterns, we thought the big question was “How will we get people to use them?” We’d fallen into the trap of the Sales Mindset.
This is pretty common in government because government is very big (and did we also mention very old?) so we often have to work across different organisations. In the private sector, external people are either your customers, or you’re theirs. That’s the common model of organisation relations, but in the public sector it’s a false equivalency. Public organisations are not competing for market share. We’re all here to help support society.
But we fall into this trap. We build a thing, and then we ask do we need to tempt our users with a ‘carrot’ or do we force them to use it with a ‘stick’? This is the wrong mindset for government services.
So how do we escape this trap? Well firstly, this is a service, so we need to design it in the way we design services for citizens, asking:
1. What do our users need?
2. What is our goal and how do we think we’ll
achieve it?3. What do we need from our users to achieve that goal?
Asking these questions makes it clear we need to treat the users of government service patterns as colleagues, not customers. That’s because:
1. Our users need to design and deliver local government services.
2. Our goal is for those services to work well for users whilst being cost efficient. We think we’ll achieve that with common components and patterns.
3. What makes the goal achievable is for users to actively feed back when those patterns don’t work for them.
Clearly our users’ needs and our goals align. And, most importantly, we’re not just building a thing for our users, we’re building things with them.
This wasn’t a lightbulb moment in the project, but a slow realisation. As we got more feedback on the feasibility of implementing what we thought was best practice, we realised we’d been a bit naîve about how easy it is to completely transform these services in different local contexts. The needs for the service might be similar, but years of doing things in a certain way meant there would be knock-on effect on other services, that didn’t make sense for some councils. If the patterns were going to work, they’d have to be adaptable to their local context. And that meant listening to what that context was.
So it became obvious to us that we weren’t really delivering a service to local governments, any more than a team member delivers a service to their team. Patterns are a two way conversation, with a deep level of respect flowing both ways. Our role in creating these patterns was facilitating the sharing of knowledge between councils, just as the primary role of any designer is facilitation.
We learnt this isn’t the kind of process that can be automated. We couldn’t just make a place online for people to dump their research and expect best practice documentation to emerge. We need a structured, critical discussion.
The future is collaborative
The idea of local government service patterns is still really new. We’ve made two — resident’s parking permits and older people’s bus passes — and they’re being used by a handful of councils. The patterns are published openly on the web, so more may be using them.
But the exciting thing is that our pilot councils are giving us their feedback as they build, so we can continue to iterate the pattern. They’re also using our common components, and as that involves technical integration through apis we have a dialogue about this too. And with the components we’re learning — again — to build not just with users at the centre, but in collaboration with them.
Government is big, and it is old. But it’s maturing into one agile team.
————
Lizzie Bruce is a content lead and UX writer. She worked as senior content designer for various parts of the UK government.
Sanjay Poyzer works at the Government Digital Service in London as a service designer. He developed new services with 17 UK councils.
