Blue Badge Digital Companion

The paper trail was failing the people who needed help most

The Blue Badge scheme provides parking concessions to around 2.5 million disabled people in England. Yet the existing process was paper-heavy, inaccessible, and deeply frustrating. Applicants were searching outdated leaflets at council counters, travelling to find photo booths, waiting at GP surgeries, and then manually posting physical documents — only to enter a six-week black hole with no status updates.

Historically, 20% of applications were lost in the mail or rejected due to unclear handwriting. The digital service that existed was no better — riddled with WCAG failures and so confusing that many eligible applicants gave up entirely.

The As-Is vs To-Be service map I created during discovery — mapping the four pain points in the paper process against the digital solution's value adds at each stage.

• Searching outdated leaflets at busy council counters with no clear guidance
• Travelling to find a photo booth — a significant barrier for people with mobility impairments
• Long waits at GP surgeries to get evidence letters
• Manually posting physical documents — 20% lost or rejected due to unclear handwriting
• A 6-week verification blackhole: no status updates, no acknowledgement, no way to check
• Screen reader and keyboard navigation failures on the existing digital service

Gerald Thompson (72) — severe arthritis, uses trackball mouse, prefers physical mail. Goal: complete forms independently with dignity. Sarah Chen (28) — tech-savvy caregiver, frequent mobile user. Goal: efficiently organise tasks for family.

Understanding the people behind the application

Before any design work began, I ran a structured discovery phase: reviewing analytics to identify drop-off points, shadowing council phone support agents, and conducting contextual interviews with applicants across three eligibility categories — including participants with mobility impairments, visual impairments, and cognitive disabilities.

I coordinated stakeholder alignment across council processing staff, DfT policy teams, and accessibility specialists — translating diverse requirements into a single, coherent design direction. I also conducted a full heuristic audit of the existing service, mapping every failure point against WCAG 2.2 AA criteria.

GOV.UK Design System as the structural backbone

The GOV.UK Design System's question-per-page pattern was the structural foundation of the redesign — each screen presenting only what was needed, progressively revealing complexity only when necessary. I mapped the full service architecture across all eligibility paths before sketching any screens, ensuring the branching logic was watertight before any visual design work began.

The key decision: I chose the question-per-page pattern over a single long form, despite early pressure from stakeholders to reduce 'the number of clicks.' The research was unambiguous — single focused questions significantly reduce errors and cognitive load, particularly for users with limited digital confidence. Every extra click is worth it if it means fewer abandoned applications. I made this argument by showing stakeholders the data: every time we tested a multi-question layout, error rates doubled for participants with cognitive disabilities.

The inclusive user flow I designed — annotated with GDS pattern references and WCAG decisions at each branching point. Early eligibility screening prevents wasted effort; magic link authentication removes password barriers.

The Standard of Trust — my GDS component audit mapping every UI component against WCAG 2.2 AA criteria. Where standard components met the need, I used them. Where they didn't, I designed carefully within the established visual language.

From GDS wireframes to accessible high-fidelity

Low-fidelity wireframes were tested early with real users — including participants using screen readers, switch access devices, and keyboard-only navigation — before any high-fidelity design work began. I used GOV.UK Design System components wherever they met user needs, introducing new patterns only where existing ones genuinely couldn't serve the user.

Low-fidelity wireframes — tested with real users before any high-fidelity work began:

Low-fidelity wireframes applying the GOV.UK question-per-page pattern. Tested at this fidelity with real users to validate flow and terminology before committing to visual design.

WCAG 2.2 compliance matrix

Nine WCAG 2.2 AA criteria were formally assessed — each with specific implementation evidence, testing methodology, and a documented historical issue from the old system that the new design resolved. 100% pass rate across all assessed criteria.

The formal compliance matrix — each criterion evidenced with implementation detail, testing method, and the historical issue from the old system it resolved. Audit date: March 2026.

High-fidelity screens — built directly in the GOV.UK Prototype Kit using authentic GDS typography (GDS Transport), spacing, and components. This fidelity was deliberate: users like Gerald need to trust the environment before submitting sensitive medical documentation.

Screen 1: GDS Task List — application overview with status badges

Screen 2: Evidence upload — dual input method, 44px+ targets, success confirmation

Screen 3: Magic-link email confirmation — passwordless, no cognitive function test

Measurable impact for 2.5 million eligible users

100% task completion in moderated usability testing across all user groups — including participants using screen readers, trackball mice, and keyboard-only navigation. Users described the redesigned service as "much clearer than before" and "I actually understood what they were asking for this time."

The service passed GDS assessment standards at first review. Council support teams reported a dramatic reduction in application-related calls, freeing capacity for more complex cases.

What I learned