Design for everyone
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?
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 inadvertently blocking our efforts to build a service that works well for everyone?
A common approach to inclusive design is grouping users by demographics—such as age, gender, disability, or specific diagnoses in healthcare. This can be important, for instance when offering inclusive pronoun options or avoiding structures that alienate marginalised groups. But in practice, it quickly becomes unmanageable. You end up with an ever-expanding list of categories, each more granular than the last, without getting closer to knowing how to design for them. It also overlooks intersectional inequality—where overlapping identities create unique barriers. In services aiming to include everyone, it’s simply not feasible to represent or involve all possible identities at every stage of design.
Another tactic is to group users by the channel they use—for example, “digital” vs “non-digital” users. But this can trap teams in circular logic. If your digital service doesn’t work for someone, and you then label them a non-digital user, you’re not solving the problem — you’re naming its consequence. Both of these framings focus on user characteristics rather than system design. That limits the types of solutions we imagine. How we frame problems directly shapes the ideas we generate — so it matters if we start by asking “what’s wrong with the user?” or “what’s wrong with the system?”
The solution
What works better is grouping the reasons someone struggles with a service, rather than segmenting the people who experience those struggles. This is the basis of the Universal Barriers to Access approach. Over time, the Government Digital Service received thousands of calls from people unable to use parts of its services. By analysing this data, we identified 11 common barriers—recurring patterns that explain why services fail for users, regardless of their background or situation.
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:
Universal Barriers as a Design Method
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.
Beyond channels and characteristics
Designing for everyone means looking beyond surface categories like demographics or digital skill. A digital interface doesn’t just require technical ability — it asks for time, trust, money for data, a quiet moment, a private connection, confidence, and even awareness that the service exists. These factors shift constantly based on a person’s context, not their identity. Likewise, access issues don’t belong to one group. Someone might struggle with stairs because they use a wheelchair, have a pram, are injured, or are simply tired. The reasons differ, but the barrier is the same. Instead of segmenting users endlessly by condition or identity, this approach focuses on what’s getting in the way — and how we can fix it.
Using Barriers to Access in design
The “Barriers to Access” framework helps shift our thinking from “What’s wrong with this person?” to “What’s wrong with this service?” That mindset change is powerful in design — because we’re not here to change people. We’re here to change services so they work for everyone. The goal isn’t a perfect, barrier-free service — that’s not realistic. What matters is understanding which barriers exist, how large they are, and whether we’re offering meaningful support or options that reduce their impact. The framework doesn’t give you answers, but it helps you ask better questions.
Flexible, practical, contextual
There’s no single way to use this tool — and that’s the point. Good design adapts to context. Here are some ways I’ve applied it across NHS Scotland and beyond:
Research & Analysis
- Informed recruitment strategies
- Shaped interview questions
- Helped code and make sense of qualitative data
Collaboration & Strategy
- Built shared language with clinical and policy colleagues
- Brought third-sector partners into design discussions
- Grounded Equality Impact Assessments in lived experience
Evaluation & Co-Design
- Evaluated existing and proposed services and products
- Supported trauma-informed co-design sessions
- Prototyped more inclusive service pathways
What matters is operationalising these insights into your process, in ways that support real decisions and real users.
Making insights work
Barriers to Access is not a replacement for user research or co-design — it supports and strengthens those activities. It helps identify who to involve, what to ask, and how to use insights meaningfully. It’s also a useful bridge when engagement is delayed, limited, or incomplete.
And crucially, it helps connect lived experience — often held by organisations closest to communities — with the places where design, decisions, and technology happen. Even when those connections exist, they can be hard to navigate. This approach helps teams translate rich but complex insights into practical, inclusive design decisions.