Designing services that work for everyone

Across Scotland, organisations are adopting AI chatbots, app-based services, and digital-only pathways to modernise and reduce costs. Many are doing so without considering who gets left behind. The evidence is clear: digital adoption without deliberate inclusion design creates new barriers for the people who already face the most.

The AI problem — named and cited

The House of Lords went further: organisations adopting machine learning "would further disadvantage digitally-excluded groups" because the systems learn from existing digital users — which systematically excludes the people who couldn't access digital services in the first place. An AI customer service tool trained on confident digital users will be optimised for them, not for the person who most needs help.

THINK Digital Partners named the compounding risk directly in February 2026: as AI-enabled services become the norm, those already excluded face "a growing class of people who cannot reliably access, use or benefit from digital services essential to modern life." Every AI capability added without an inclusive fallback is a new barrier installed.

Further reading: House of Lords Library — Digital Exclusion report summary.

Who is digitally excluded — and it may not be who you think

Ofcom's 2024–25 research challenges the assumption that digital exclusion is primarily an issue for older people. The remaining offline population is significantly skewed toward younger people facing financial barriers. 2.8 million people in the UK are still entirely offline — though that is down from 13% of the population pre-pandemic to 5% today. A further 27% of the population are "narrow" internet users who rely on a limited range of online activities. Separately, Lloyds Bank's Essential Digital Skills research puts the number of UK workers lacking essential digital skills for work at around 10 million.

Digital exclusion is shaped by income, disability, device age, data costs, digital skills, language, and authentication barriers — not simply age. Any service design that assumes "our users are digitally confident" is making an assumption that the evidence does not support.

Further reading: Good Things Foundation — What the main UK datasets tell us (September 2024, PDF).

Seven practical principles

These are drawn from the NHS England framework, the UK Government's Digital Inclusion Action Plan, the GOV.UK Service Standard, and the evidence above.

1. Never digital-only — always maintain a non-digital pathway

   The single most prominent theme in responses to the UK Government's Digital Inclusion Action Plan was this: phone and face-to-face access must remain available alongside digital services. NHS England's Inclusive Digital Healthcare framework is explicit: "digital approaches must be complementary to non-digital services." When you add a chatbot, an app, or an online portal, ask who this replaces for rather than supplements.

2. Test with digitally excluded users — not just confident ones

   The GOV.UK Service Standard requires teams to research with users who struggle with digital services and provide assisted digital support. If your user testing sample does not include people with low digital skills, people on basic mobile contracts, and people without smartphones, you are designing for the already-included. Actively recruit these users to your testing sessions — not as an afterthought, but from the start.

3. Do not require a smartphone for authentication

   Two-factor authentication via a smartphone app is standard security practice. It is also a lock-out for older people on basic handsets, people in temporary accommodation, and anyone whose device is too old to run the required app. Offer SMS codes (not just app-based authentication), phone call verification, or staff-assisted authentication as alternatives. Universal Credit itself has created barriers here — do not replicate the problem.

4. Consider the cost of data poverty

   An app that requires a download of 50MB, runs regular background syncs, or streams video to explain features has a financial cost that your service design team likely never sees. People managing on 1–2GB mobile data plans per month will either not download your app or will ration every interaction. Design for data poverty: optimise app size, avoid autoplay, offer low-data modes, and explain data usage clearly before download.

5. Do not assume the latest operating system

   Setting a minimum OS requirement that excludes devices two or three years old is a design decision — and it is rarely made with the user in mind. It falls hardest on people who cannot afford or do not want to replace a working device. Understand what devices your users actually have, not what devices you would like them to have. There is no regulatory requirement forcing organisations to consider this — which is exactly why you should do it deliberately.

6. Use plain, human language — especially in AI-generated content

   AI-generated text tends toward formal, complex language. It regularly uses passive voice, abstract nouns, and long sentence structures. For people with lower literacy, cognitive impairments, or English as a second language, this is a barrier to understanding. If you are using AI to generate content, correspondence, or service responses, audit it specifically for plain language — do not assume the model's default output is appropriate for your audience.

7. Meet WCAG 2.2 AA as a minimum — and go further

   Web Content Accessibility Guidelines 2.2 Level AA is the legal baseline for public sector organisations in the UK. It covers screen readers, keyboard navigation, colour contrast, and much more. But WCAG compliance does not guarantee your service works for digitally excluded users — it is a floor, not a ceiling. Accessibility and digital inclusion are related but distinct. Treat WCAG 2.2 as the start of a conversation, not the end of your obligations.

   For practical, plain-English guidance on actually meeting — and going beyond — WCAG, The A11Y Project is worth building into your workflow rather than treating as a one-off read. It's free, community-maintained, and built around checklists and patterns rather than dense spec language.

Published standards that apply to your organisation

Where to actually learn accessibility practice

Standards tell you what's required. They don't teach you how to do it. For that, WIRES points organisations to The A11Y Project — a free, community-driven effort to make digital accessibility easier, built by practitioners rather than a standards body.

Sources on this page are from published reports, parliamentary committees, and statutory bodies. If you know of guidance we have missed, tell us.