There’s usually no alternative to using government services so they have to work for everyone. Making your service inclusive means making sure anyone who needs to can use it as easily as possible.
You must consider the barriers different groups of users might face when trying to use your service, and how to address them.
Do this by:
- recruiting user research participants who represent your users - make sure you design for their needs and continually test your service with them
- using research techniques that help to include harder to reach groups
- looking for points in the service that could exclude particular groups
Making your service accessible to disabled users is an important part of making your service inclusive. So is providing assisted digital support to people who lack digital skills or internet access. But you’ll need to consider whether you’re excluding other groups as well.
You must also operate your service in line with your department’s Welsh language scheme, if there is one. Here’s an example of a Welsh language scheme.
Groups to consider
Some groups are more likely to be excluded from services than others. This can be because of a disability, lack of resources or other life circumstances.
For example, people with caring responsibilities might not have much choice over what time of day they use government services, while people without stable accommodation might find it difficult to provide the right documents or reply to notifications. Again, it’s fairly unusual these days for people to own printers, which makes it difficult for most people to engage with government services using printable forms.
There’s also a legal duty under the Equality Act 2010 not to exclude protected groups.
When you’re providing a public service, it’s usually against the law to discriminate against someone because of:
- gender reassignment
- being married or in a civil partnership
- being pregnant or having recently given birth
- race, nationality, ethnic or national origin
- religion, belief or lack of religion or belief
- sexual orientation
Designing for inclusion makes things better for everyone
Most of the time, an inclusive service is the same thing as a good service. Everyone has different needs at different times and in different circumstances. So when you design with groups who tend to be excluded in mind, you often end up helping everyone. For example:
- when you create a website page with a clear layout you’re helping both people with visual impairments, and people using older computers with low resolution monitors
- when you minimise the file size of a website page you’re helping people who have limited mobile data plans - but it also makes the service faster for everyone
- when you give people the option of using a service online or over the phone rather than face to face, you’re helping both people with mobility problems and people who live a long way from your offices
Finding pain points where users could be excluded
Making your service inclusive means understanding and addressing points in your service where users experience problems or distress.
Your service will have specific pain points depending on what it does and who your users are. It’s up to you to find these points.
For example, somebody who’s pregnant for the first time may already be a parent. Maybe they’re in a same-sex relationship and their partner was pregnant with their first child. This makes answering the common question “is this your first baby?” problematic.
In this case it’s probably more helpful to think about what the service needs to know from the person. If it’s whether they have been pregnant or given birth before to establish how many antenatal checks they need - ask that.
Start with work you’ve done to understand how users interact with your service, such as your user journey map.
You can also consider common examples of pain points and whether they’re present in your service, for example:
- insisting on the exclusive use of one channel
- setting inflexible deadlines
- accepting only a limited range of documents and evidence
- failing to signpost or refer users to other services
- distorting users’ experience of your service through the way you measure its performance
Insisting on the exclusive use of one channel
Your service will likely be available over different channels - on GOV.UK, for example, and potentially over the phone or by talking to someone in person.
You risk excluding people if you force them to use a channel they are not able to access. For example:
- deaf users can be excluded if you screen users over the phone before they can get another form of support
- users who do not have regular access to the internet can miss notifications if the only option is to get them by email
- users in insecure employment may find it difficult to make a face to face appointment, so you risk excluding them if you require them to do this
When designing your service, it’s important to provide the mix of channels users need for each interaction, and make it easy to move between channels.
Setting inflexible deadlines
Inflexible deadlines can cause problems for some users because their circumstances affect how quickly they can act on messages.
For example, homeless users or users without stable accommodation cannot easily charge their phones or check email. They’ll also be difficult to contact by post.
Remember that interacting with government takes time and effort that’s not influenced by how fast a method communication is. Do not assume users will respond quickly just because you’ve sent them an email or text message rather than a letter.
Accepting only a limited range of documents and evidence
Asking for birth certificates or other documents about users’ lives can cause particular problems for:
- users born in non-UK jurisdictions who may face significant challenges getting hold of the right paperwork
- transgender users, if you’re asking them to ‘out’ themselves without good reason
Many users do not own a printer and do not get paper bank statements or bills.
Some users lack a permanent address, or move frequently, so cannot provide proof of address. Remember that 1 in 4 households with children live in rented accomodation.
Consider carefully what information you need to ask for, and whether you need evidence to back up that information. Only ask for something when you truly need it.
Accept as wide a range of evidence as you can if you do need users to back up what they tell you with proof.
Failing to signpost or refer users to other services effectively
Some users have to make a significant effort to interact with government services, and if you cannot help them they might not seek further help. For example people on low incomes might not be able to afford travel or call time to pursue an interaction. Or users who feel marginalised might not have the motivation to interact with another part of government after one part has failed to help them.
Consider the best way to deal with users who need help you cannot provide:
- signposting - making users aware of another service (for example, by giving them a leaflet) and leaving it to them to initiate contact
- referral - asking another service to help the user, giving the other service responsibility for getting them to use it
Signposting is less likely to be the right approach for someone whose situation means they lack the capability or motivation to help themselves.
Start by learning about related services run by other organisations and teams. This will help you plan onward journeys for users you cannot help. Consider points in your service where you can learn more about why a particular user has come to you - the better you understand their problem, the more effectively you’ll be able to signpost or refer.
Performance measures with unintended consequences
Be careful how you set performance targets. For example, a strict time limit on appointments might mean it takes a greater number of appointments (and therefore more time and money) to solve a user’s problem.
Users who are vulnerable to being excluded may be less likely to take that time.
And problems that are not solved quickly and effectively can get worse and become more complex, meaning they’re more expensive to solve in the long term.
Guidance first published