Accessible service design — some thoughts

Accessibility continues to be addressed as an afterthought for many organisations. So, i'd like to take a look at its role in service design and how it affects the design and build of 'good services'.

Defining service design

Quoting Lou Downe former Director of Design for the Government Digital Service:

"Service design is the design of services. To a user, a service is simple. It's something that helps them to do something - like to learn to drive, buy a house or become a childminder."

Good services

Returning to Lou Downe, in their role as Head of Services and later Director of Design, they created a set of principles which described things that need to be in place to build 'good services'.

All of the principles contribute to removing barriers to accessibility in some way.

Organisations often invest money and effort into improving their public-facing touchpoints -- such as their website, emails and mobile applications. But, they may only be addressing the symptoms of user experience issues. A key factor that separates 'service design' is that it considers the internal machinations of an organisation and how this influences the user experience, too.

To provide an example, if the call centre staff is offshore and cannot access the same customer complaints database as, say, operations what might this might mean in terms of providing a connected and positive end-to-end experience for customers contacting with an issue or query?

WCAG role in good services

Even if you feel unsure where to start with the design and build of an accessible service, the principles aren't new. The steps should be familiar to anyone who is aware of, for example, the Web Content Accessibility Guidelines (WCAG) — or various other related principles and heuristics — including Jakob Nielsen's 10 heuristics.

Let's look at the Good Services principles by Lou Downe and how they compare with guidance in WCAG:

Be easy to find (1)

This principle would encompass the WCAG check of 'Multiple Ways' which asks that people are given multiple ways to locate and navigate content within a website.

Require the minimum possible steps to complete (8)

This principle would encompass the WCAG check of 'Redundant Entry' which asks us not to make people enter information which has already been supplied.

Be consistent throughout (9)

This principle encompasses various items in WCAG but, specifically, 'Consistent Navigation' which requires websites to position navigation in the same relative order each time they are repeated. It also encompasses 'Consistent Identification' which requires websites to make sure functionality which is repeated across pages is identified consistently. For example, if we include a log-in button in the header and footer, it should be labelled as 'Log in' across both.

Be usable by everyone, equally (11)

This is accessibility and inclusion.


I draw this parallel between ideas in WCAG and the principles of 'good services' in the hope of showing how you can begin to introduce accessibility to the service design process - and, hopefully, it will be easier than you may think.

What this means is we can use the pre-existing requirements provided by WCAG to help us to identify and prevent accessibility barriers in the early stages of service design. Even if the WCAG wasn't explicitly designed for such a job.

It is, however, true that service design is characterised by a broader outlook than the guidance provided by WCAG -- which is concerned mainly with interfaces within certain digital channels. How might we zoom out and remove barriers to accessibility and inclusion across not just pages but channels, teams and tools?

From this point, I should note that when I use the term 'accessibility' I mean removing barriers to people with disabilities and when I use the term 'inclusion' I mean where we consider more than disability as a barrier to using a service - including such things as: gender, race or socio-economic background.

Traditional accessibility approaches vs service level thinking

My observation is that a lot of accessibility work that gets commissioned is still relatively constrained in scope. By this, I mean that it tends to be completed at the interface level and is backwards looking (looking at stuff that has already been built). I'm suggesting this is more closely aligned with a product-focussed rather than service mindset.

Important:If the above is true then inclusive service design would: take a cross channel view, look to feed into business outcomes and, ideally, influence at a policy and strategy level.

How might we re-use WCAG for services

Returning to WCAG, what are some practical examples in which specific WCAG criteria could be abstracted in a cross-channel service design context?

Let's look at a single success criterion and see how this could be used by a service designer.

Consistent Help (3.2.6)

At an interface level, this criterion says we must place help support in a consistent position across web pages. This helps ensure the route to finding support is predictable from a cognitive point-of-view and simplifies the task of finding help for people who use assistive technology.

While the WCAG focusses on 'help' across web pages, the kernel of the guidance is about making help easy to find, in general. In the service design world, we might use this check to focus the mind on signposting and providing help clearly, consistently across, for example: letters, emails, web pages, mobile apps and then across all our products.

Imagine a situation where a brand new customer, based in certain geographical location, can benefit from online chat-based support but customers based elsewhere with older products must phone in. This 'fails' Consistent Help but abstracted to the service design level!

With this mindset, the WCAG can be considered by service designers as a guide which can be slightly tweaked in scope and specificity and deployed to remove barriers for a broader more holistic purpose.

Prompts for service designers

Here are some more general prompts for considering accessibility in your service:

Inaccessible service design: documents

Let's look at a simple but common example of inaccessibility in service design.

Many companies I work with make great progress fixing issues in their web pages. Even if we work hard to identify problematic content types during the standard scoping process, we may later find that important features of their service are trapped in inaccessible PDFs or that they have integrated inaccessible chat components or, often worse, accessibility overlays. The accessibility is dictated by the weakest link in the chain.

A PDF may be a single document but, if the information within is important enough (and no alternative is offered), it may affect completion of goals across steps and channels. It may present a significant barrier and potentially straddle the gap between not just preventing completion of goals within that interface but rather inclusion to the service in general.

Monzo seems to have understood the importance of moving away from relying on PDFs for key information and has provided a well structured simple web-based version of their terms and conditions. While it could be further improved, it's a nice example of making their core information more accessible: Monzo terms and conditions

Service design and deceptive patterns

The process of cancelling a subscription is infamous from a customer experience perspective. It is often easy to start a service (online) but in an attempt to cancel, one is required to use expensive call centre phone numbers and wait for unacceptable amounts of time to speak to someone. For most people this is beyond stressful. This process not only penalises people from a monetary point-of-view (call centre phone call costs) but also requires people to pay a tax from an attention and patience point-of-view. The barrier this creates is multiplied for people who experience cognitive disability or impairment of any kind.

A common theme of bad services is the 'deceptive pattern'. This is a a certain type of content or feature designed to fool users into a certain course of action. While something can be technically 'accessible', it can still be highly detrimental. One example of this is when certain airlines have been known to add travel insurance to the user basket in such a subtle way that it is only possible to detect once it is too late.

Positive steps for inclusive services

Here are a few more prompts to help you avoid inclusion barriers and build better services:

Further reading