By Clara Greo and Kara Kane
The purpose of government is to make our lives better.
Ministers do this by advocating for the things that their constituents want, need and value. Policy professionals do this by designing policy interventions to generate specific outcomes. In government digital transformation, we do this by delivering equitable services which meet the needs of people who use them.
We’ve found that the best way to make sure services do what users need in the most efficient way for government is to practice user-centred design (UCD).
We talk a lot about UCD in government: it’s an approach, a job family, and a community. But most importantly it’s a way of putting users first. It helps us stay focussed on the purpose of it all. It makes sure we minimise the risk of wasting time and money on developing services that do not work, do not meet policy intentions or that do not produce equitable outcomes.
User-centredness has been at the heart of the Government Digital Service (GDS) since its inception, and this has followed through to digital transformation across the UK government, and around the world. It’s the first Government Design Principle. It’s the first point in the Service Standard, and the first point in the Technology Code of Practice. You can find it on the first page of Baroness Martha Lane-Fox’s report Directgov 2010 and Beyond: Revolution Not Evolution, which kick-started GDS: “For me, the acid test for Directgov is whether it can empower, and make life simpler for citizens”.
In Spring 2020, Clara Greo and Kara Kane presented at a GDS remote all-staff conference on the topic: ‘What is UCD anyway?’. Here is how they describe it for government.
We use the term UCD in government as opposed to other terms like human-centred design, planet-centred design, and design thinking because of the context in which we are designing. Most of the time people have no choice but to use a government service, because there are no alternatives to achieve their goal. People are users of our services and we think it is important for civil servants to remember that — the interaction, the service, as well as the regulations public digital services need to meet.
What does it look like without UCD
Without a user-centred approach, the work is riskier, more costly and can cause unintended harm.
When we work with stakeholders who are not used to working in a UCD framework, they often initially feel like they have lost control and they’re not sure what will be delivered. What they soon realise is that while they no longer have direct control of what the end service looks like, they have much more control over the risk of the product not working, not doing what it was intended to do, or not creating equitable outcomes for all users.
Without doing research and fully understanding the problem, a team carries assumptions with them throughout the design and build of service. The team can get to the end-product and end up with something that does not meet user needs or solve a problem. Without an iterative process, where a team is learning as they go to inform the service a team can spend a lot of time, and therefore money, on the wrong solution.
If things like accessibility and content strategy are not considered from the beginning then a service will have a poor user experience, it will be inaccessible, and it can cause unintended harm such as creating barriers for marginalised groups to use a service.
What does it mean to be user-centred?
Based on our experience advocating for and building capability in UCD we came up with 9 points that are necessary to be user-centred in government:
- Service and policy decisions are guided by user needs
- There are research and design skills on every team
- The team iterates and learns as we go
- We design everything in context, zooming in and out
- We design services end-to-end, front-to-back and cross channel
- We understand that content is our product, the words are the service
- We work to the Service Standard
- We use the GOV.UK Design System by default
- We consider equity, inclusion and accessibility from the start
1. Service and policy decisions are guided by user needs
All decisions, in all phases of the service lifecycle and all parts of the service team, should be guided by user insights. We have to know that the thing we are going to build will work and will achieve the outcome we need it to achieve, and this can only be done by understanding users and designing in this context.
To do this, we must join up the service creation and delivery process, from policy right through to delivery and operations. These parts must work together and must be focussed on the same outcomes.
2. There are research and design skills on every team
To work in a user-centred way you need research and design skills on your team. Whether that’s a full UCD team of a researcher, designer and content designer or technical writer, a UX team of one, or people who have acquired those skills to put them into practice.
And it’s not just service teams that need these skills, it’s all teams in your organisation including recruitment, strategy, tech ops, and the service desk.
All of these teams provide services, they all have users and if they are designed without users in mind, they will waste time and money.
We talk about all teams having these skills because internal services are just as important to be well designed. We say ‘civil servants are users too’. We do not mean they are proxies for doing user research for a public facing service, rather we mean we follow UCD to design for internal services that civil servants use too.
3. The team iterates and learns as we go
No one ever gets it right the first time. The only way to minimise risk and make sure you’re not investing time and money in a solution that is not going to work, is by testing your service early and often.
User researchers have ways of finding out what is going to work and what users need at every phase of a service, and this is invaluable when you want to make sure that bad ideas fail fast, and that the best ideas are seen and built on. Every idea gets tested and every assumption gets validated.
The cycle of trying something, getting feedback and research insights on it, and then trying something else, is the only way to know for sure that your product is going to be a success.
4. We design everything in context, zooming in and out
To design a service you need to understand its context — the wider system the service sits within and the conditions and circumstances in which it’s used. The process involves zooming in and out and deciding where to focus.
This quote from Eliel Saarinen describes it well:
“Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan.”
Without the process of zooming in and out, you can end up designing something that does not work because of external factors, or you can create unintended barriers within the system.
5. We design services end-to-end, front-to-back and cross channel
We design the whole service, not just the bit on a computer screen.
From end-to-end — this means we consider the first time a user hears about a service, how to find the service, what the experience of using it is, what happens at the end, how data gets processed and decisions get made, how the user finds out the outcome of using the service and what the eventual outcome is in terms of the initial user need that triggered them to use the service.
From front-to-back — this means all the policy, processes, technical architecture, piles of casework, weird old legacy systems. All of it is part of the service and can impact what users experience and whether or not it is a success.
Cross-channel — this means all the channels that a user could interact with including in person, on paper, on the phone and online. They all need to join up and work together.
6. We understand that content is our product, the words are the service
When working on digital services, the majority of the service is words on a webpage. Content design ensures that the content is understandable, usable, and easy to navigate.
We use plain English to ensure the words we use are understood by everyone no matter their level of expertise or specialism. In government we adhere to the GOV.UK style guide and use content design best practice in our work.
7. We work to the Service Standard
To ensure quality of government services we have established a binding service standard. When teams have a service assessment, this is the standard the assessment team measures large digital services against. Teams are assessed against the standard to move between phases of the service lifecycle: alpha, beta, live.
In July 2019, the standard was updated after extensive user research from 18 points to 14. The first 3 points are: Understanding users and their needs, solve a whole problem for users, and provide a joined up experience across all channels.
8. We use the GOV.UK Design System by default
The GOV.UK Design System makes the most common components of an online service easy to get right, so teams can focus on what makes their service different. It captures 1000s of hours of research and design, and provides styles, components and patterns that are accessible, usable and easy to implement.
One of the biggest benefits of working in government is the ability to draw on the knowledge and experience of 100s of teams all across the country. Sharing is encouraged and can provide huge savings to taxpayers.
Not using the patterns in the design system is wasting time and money on questions that we already have really good answers to. It gives you a huge head start with the design of your service.
9. We consider equity, inclusion and accessibility from the start
Working in a user-centred way means that equity, inclusion and accessibility are considered and addressed from the start. It cannot be an add-on at the end, or something that we only address in phase 2 or after an MVP is delivered.
We scan for unintended consequences regularly, and consider groups or communities who might be disproportionately excluded or harmed by our service. We test our designs with disabled people, and consult experts and accessibility organisations throughout the service lifecycle.
The Public sector equality duty is part of the Equality Act 2010. It says that we have a duty to advance equality by:
- Removing or minimising disadvantages suffered by people due to their protected characteristics.
- Taking steps to meet the needs of people from protected groups where these are different from the needs of other people.
Building an accessible service is the law — Public Sector Bodies Accessibility Regulations means that all new public sector websites must meet the regulations before being published.
What are the benefits of UCD?
The benefits of UCD are:
- Build products and services faster
- Build products and services that people use
- Reduce risk in projects
- Save money
- Be more efficient by failing fast
- Do better quality design
- Be more accessible and equitable
At the start of the Covid-19 pandemic, GDS quickly shipped five brand new services including Coronavirus updates. They were able to be built at this speed because of the GOV.UK Design System. That’s over 60 individual web pages, designed and built in a matter of weeks.
There were an extra 23,000 visits to the GOV.UK Design System website over 2 weeks early on in the pandemic. Having the Design System, and the team behind it is helping government ship services fast when they need to be shipped fast.
We regularly publish blog posts to capture case studies and share learnings about the benefits of UCD across government. Here a few examples:
Lessons on maintaining staff engagement — the GDS Internal Communications team shared how they used research to identify and improve the impact of their work and where to focus their efforts.
Transforming the flood service: responding to users — The Flood information service team followed a UCD approach and now “operate a more streamlined, reliable, and accessible service”.
Showing the rewards of user-centred service design at scale — a team at the Home Office tasked with replacing a legacy licensing system created a new service that “was delivered on time, on budget and meets all 14 points of the updated Service Standard”.
How user-centred is your team?
Take this UCD maturity quiz to find out how user-centred your team is, with some suggested next steps at the end.
How to find out more:
- Services in government blog
- Design in government blog
- User Research in government blog
- Accessibility in government blog
- Service Manual community page
- UK Gov Design YouTube Channel
We’d love to hear your thoughts and experiences. Comment below or find us on Twitter @ClaraGT and @KaraKane_KK.
——
Clara Greo is a designer and researcher who has been working in the industry for over 15 years. She has done a lot of work in building capability through training and community-based education. She is determined to bring equity and justice into public sector digital transformation. She’s Australian, an immigrant, a part-time worker and a parent.
Kara Kane is a designer and community builder whose expertise is in building design culture in large scale organisations. She managed the UK’s user-centred design community and co-founded the International Design in Government community bringing together design-minded public servants from over 70 countries.
