Blue Badge Digital Companion

User research & persona development

I constructed two primary personas representing the spectrum of need. Gerald, 72, is a motor-impaired veteran with severe arthritis who uses a trackball mouse — drag-and-drop is unusable for him, and small tap targets cause misclicks. His goal is to complete forms independently, with dignity. Sarah, 28, is a tech-savvy caregiver completing the application on behalf of a family member, managing multiple appointments and relying on her mobile. Both personas shaped every design decision that followed, and were used to stress-test each WCAG criterion against real user behaviour.

Inclusive user flow mapping

I mapped the full end-to-end application journey as an inclusive user flow — covering the primary path from landing page through eligibility screening, authentication, evidence upload, and submission, with clearly annotated branching paths for users who fail eligibility, need alternative transport support, or require third-party carer access. Each decision node was annotated with the GDS pattern applied and its accessibility rationale.

GDS component audit — the standard of trust

Before drawing a single wireframe, I conducted a structured component audit to categorise which GDS patterns applied and where custom innovation was justified. The audit identified two categories: standard GDS components (radios, checkboxes, task lists, file upload, error summaries) — and one custom innovation: a Photo Guidance Component with an oval silhouette overlay to improve photo submission quality and reduce the rejection rate caused by poor uploads. Every component was mapped against specific WCAG 2.2 criteria including 1.4.11 Non-text Contrast, 2.5.8 Target Size, and 3.3.7 Accessible Authentication.

Low-fidelity wireframes — structure before colour

Three key screens were wireframed to validate information architecture, task flow logic, and component placement before any visual decisions were made. The GDS Task List pattern replaced a percentage-based progress bar — screen reader users find percentage progress vague and non-actionable. The file upload screen introduced both drag-and-drop and a traditional file picker, providing redundant entry (WCAG 2.2) for users like Gerald. The magic-link screen removed password memory entirely.

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

Screen 2: File upload — drag-and-drop + file picker redundancy (tablet)

Screen 3: Magic-link authentication — passwordless flow (mobile)

High-fidelity screens — GOV.UK Design System in full

High-fidelity screens were built directly in the GOV.UK Prototype Kit using authentic GDS typography (GDS Transport), spacing, and components — making the prototype indistinguishable from a live government service. This fidelity was deliberate: users like Gerald need to trust the environment before submitting sensitive medical documentation. Key accessibility implementations: custom high-contrast yellow/black focus rings, 44×44px minimum touch targets, magic-link login (WCAG 2.2 3.3.7), and auto-save every 30 seconds (WCAG 2.2.1 Timing Adjustable).

Hi-fi Screen 1: GDS Task List with Completed / In Progress / Not Started status badges

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

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

Usability testing with assistive technologies

I conducted usability sessions with five participants using screen readers (NVDA, JAWS, VoiceOver) and switch access. Two critical pivots emerged from testing:

• Upload button: Users with tremors were confused by the Upload button — iterated to support both drag-and-drop and a traditional file picker (WCAG 2.2 Redundant Entry).
• Progress bar: Screen reader users found percentage-based progress vague — replaced with the GDS Task List pattern, giving named, navigable sections.
• Focus rings: Verified custom yellow/black focus rings remained visible at 400% zoom using ZoomText.
• Session timing: Confirmed auto-save every 30 seconds eliminated anxiety around data loss for users with fatigue.

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.

• 2.4.11 Focus Not Obscured — custom focus rings visible at all zoom levels
• 2.5.7 Dragging Movements — all uploads accessible via click-to-browse, no drag required
• 2.5.8 Target Size — all interactive elements minimum 44×44px
• 1.4.4 Resize Text — all content resizable to 200% with no loss of functionality
• 1.4.10 Reflow — single-column layout, no horizontal scroll at 320px
• 2.2.1 Timing Adjustable — no session timeouts; auto-save every 30 seconds
• 3.2.6 Consistent Help — 'Contact Council' link in identical position on all 7 pages
• 3.3.2 Labels or Instructions — every field has visible label, format example, and error guidance
• 3.3.7 Accessible Authentication — magic-link login removes cognitive function test

GDS Task List over a progress bar

Screen reader testing revealed that a percentage-based progress bar communicated nothing actionable. The GDS Task List pattern gave users a clear, scannable overview — showing exactly what was complete, in progress, and not yet started, with links to jump directly to any section. This also supported the save-and-return flow for users with chronic fatigue or pain.

Magic-link authentication (WCAG 2.2 – 3.3.7)

Requiring password creation introduces a cognitive function test that WCAG 2.2 explicitly flags. A time-limited magic link sent to email removes this barrier entirely — reducing abandonment for users with memory impairments, cognitive disabilities, or anxiety, while maintaining security through token expiry and 15-minute windows.

Dual upload method — redundant entry (WCAG 2.2)

The original system required drag-and-drop upload — completely inaccessible for Gerald and users with motor impairments. Providing both drag-and-drop and a traditional file picker satisfies WCAG 2.2 Redundant Entry and ensures no user is blocked by their assistive technology or physical capability.

Save and return — designed for chronic conditions

A 20-minute form cannot be assumed completable in a single sitting for users managing chronic pain, fatigue, or cognitive load. Auto-save every 30 seconds and an explicit 'Save and come back later' route treated this not as an edge case but as a primary use pattern — recognising that the very users who need a Blue Badge are often those for whom continuous form completion is hardest.

What I would do next

• Conduct a full GDS Service Assessment with a live prototype and real assistive technology users
• Extend the third-party carer permission flow — currently scoped but not fully designed
• Build out the post-submission SMS status update experience to eliminate 'the black hole'
• Test the Photo Guidance Component with users who have low dexterity and vision impairments
• Partner with a local authority to pilot the service and gather real-world analytics