Introduction
Design in the public sector or in health and care means building end-to-end services. This may mean collaborating across organisations, and delivering across multiple channels. The focus are services that work well for everyone in Scotland, organised around people and their needs across whatever channel, interface, or provider involved.
Why is this important for designing services?
First and foremost, providing services that meet everyone’s needs is a core role of the public sector and the NHS. Anyone in Scotland could be and is using these services. Secondly, an inclusive service causes less problems to the organisation which runs it, it is cheaper to run, involves less interactions and more successful outcomes, and translates into more time and money for both users and organisations. There really are no excuses for not putting in the work of making your service work well for everyone.
The problem
How do we go about understanding and designing for all these users and user groups however? How do we divide them into manageable groups without blocking our efforts to build a service that works well for everyone?
Traditionally, the answer has been grouping users by demographic – for example age, protected characteristic such as disability, a diagnosis, or gender. Of course this is important, for example when offering the best pronoun options when asking for someone’s gender, or making sure services are not structured in a way that might exclude or alienate black people. However, and especially in health, we then face the challenge of an infinite list of different conditions or characteristics. We might develop ever more granular ways of describing how people are different from each other, and yet have no way to take into account the impact of interesectional inequalities. In a service that aspires to work for everyone, it is simply not possible to ‘cover’ or involve everyone necessary in its design at all stages.
Another approach has been to instead group users by the channel they are using – for example digital user, non-digital user, accessibility related user. From a design perspective however, this can quickly result in a circular argument. If digital channels are designed in a way that does not work for certain people, but we then label those people non-digital users, this will never help us to actually improve our digital channel and make it work for everyone.
The solution
What works best is grouping the reasons for why someone is struggling with a service rather than segmenting the people who experience them. This is what we call the universal barriers to access. The government digital service has over time received a lot of phone calls from people who struggled to use part of it. They have collected a large amount of data which has led to the identification of these 12 universal barriers.
Universal Barriers as a Design Method
I have been experimenting with several ways to turn this framework into practical methods that can be used throughout the design process. Here is one of my favourite ones:
Step 1 Familiarise yourself with the barriers. We are currently working on adding evidence from existing research to each barrier – showing more of the context, adding detail, and evidencing that a particular barrier is experienced by many people in Scotland.
Step 2 Pick a story / a person / an insight. There are many amazing resources out there that describe people’s experiences in health and social care and beyond, for example the Alliance’s Humans of Scotland, which can be accessed here.
Step 3 Pick a service or product. This could be an existing service you are trying to evaluate or identify barriers in, or a concept or prototype or feature you are in the process of developing, or two services you are comparing such as a new digital service vs a traditional face-to-face option.
Step 4 Imagine what it would be like for the person from Step 2, to use the service in Step 3. Think about what your service requires in terms of the barriers. For example, would someone need evidence or enthusiasm or trust? Is this a small barrier or a high barrier? Also think about if there are any barriers your service actively avoids compared to other options – for example using video conferencing software over needing to get to an upstairs room without lift for clinical appointments.
Step 5 This is where design comes in. Think about how we might design out the barriers you identified in Step 4, so that the person can access the service easier. Which means, try not to inadvertently build new barriers in. You should also consider how big of an obstacle a particular barrier is, and how this stacks up against what barriers the service in question might be removing. For example, while it is perhaps easier for the person to access a laptop on their kitchen table as opposed to an upstairs room – this could be negligible compared to all the barriers they might experience when accessing clinical conversations online.
Bigger than a channel
This approach allows us to capture and talk about all challenges someone might face when accessing a service. For example, to use a digital interface does not only require digital skills – it requires the money for a decent internet connection, the time to familiarise yourself with the interface, the evidence that a login process might require, the enthusiasm and self-confidence to try a digital service, sufficient trust into a private wifi network to enter your details, and even the awareness to know this service exists in the first place. These of course can also change over time and depending on the situation, for example I might trust my bank’s online banking website, but not their banking app as last time I used this something went wrong. This is why considering people whose characteristics and situation of course constantly change is less helpful.
Bigger than a characteristic
This also shows why focusing on barriers can replace our never-ending list of conditions. For example, someone might struggle to access an upstairs room without a lift because they are less mobile due to breaking their leg last week, due to having a small child and a pram with them, or due to using a wheelchair since the last 10 years. There will be many other people who struggle with climbing stairs for various reasons. As long as we know access to an upstairs room is a barrier that our service should avoid, we cover all these cases.
Using the Barriers to Access
Most importantly, this approach shifts the question from “what is wrong with this person?” to “what is wrong with my product or service” or “where does my service or product put up unnecessary barriers for this person?”. Of course, this is incredibly useful in a design process! As a designer, I am not interested in (and it is rather impossible) changing people, my task is to change the service or product I am creating in a way that works well for people, and in fact for everyone in Scotland in the case of NHS Scotland.
A perspective shift
Championing this approach at NDS, I have introduced it to various colleagues and ongoing processes where the barriers proved a powerful way to shift the conversation. We are now using barriers to access as an approach to:
- In Equality Impact Assessments conducted by the NDS Equalities leads
- Recruitment strategies for ongoing work on cancer pathways
- Thematically coding and analysing qualitative data
- Partner with third sector organisations to bring their hugely valuable insights about people into the NHS and into our design process
- Evaluate existing services and products, and importantly prototypes or early concepts for future services and products
Using the barriers to access for designing services around users and their needs
As a designer, my role is bringing insights about real people and their needs into our design process in a way where it is useful and practical tool, and directly informs design decisions me or my team are making. Of course, the best way to do so is co-designing with users and doing user research. This is not a replacement. It can complement it or be used within those activities. It helps me identify what users to recruit and what questions to ask, to code and analyse the resulting data, translate insights into actions, and use existing research. It also helps me consider inclusion when engagement is difficult or delayed for a variety of reasons.
And to work with organisations closest to people’s lives and with most insights, do not necessarily connect into the places where decisions, designs, or digital technology are being developed. Even when this connection exists, it can be difficult for teams to work out how to use often complex and detailed or very broad insights in their design process. The barriers are a great method to create this bridge, and to make insights useable, and to prototype inclusive services.
Again, this is not intended as a replacement to a full design process, to understanding your users, designing with your users, or testing your concepts and prototypes. It is another tool in a designer’s toolbox, which can complement the above, or even used within those activities. The barriers will help you to ask the right questions within your design process – namely, what does my service or product have to do differently to work for people as opposed to what is wrong with people. I find this incredibly empowering as a designer, products and services have been designed, which means they can be redesigned and reimagined to work better.
Next Steps
The universal barriers to access tie in with my work around service patterns in health and social care. The aim and ambition is to build up a library of design interventions that have been proven to work to alleviate certain barriers. For example, if we identify that a certain existing or future service has a high potential barrier around self-confidence and interface skills – we know that this is often improved by designing a particularly easy and encouraging tutorial as part of a digital product. Service patterns are all about reusing components that we know work well in our service designs – and the barriers are part of the answer to the important question of what does “good” look like. More on service patterns here.