Mobility
Flow.
A conversational mobile web interface guiding Motability customers through vehicle damage claims.
01 · Overview
Project at a Glance
A single-page React application that transforms a complex insurance claims intake process into a guided, accessible conversational interface.
🎯 The Problem
Motability customers reporting vehicle damage face extended call wait times with no digital self-service alternative available.
💡 The Solution
A step-by-step chat interface captures all claim details, verifies identity, and routes to a live agent or books a callback.
⚙️ Design Principle
Accessibility-first. Every interactive element meets WCAG 2.2 — minimum 56px touch targets, visible focus rings, full screen reader support.
📐 Scope
Single-file React application. Frontend-only — verification handled against mock data with no backend dependency.
02 · Process
Double Diamond Method
The Double Diamond framework structured every design decision across two diverge-converge cycles — first to discover the right problem, then to deliver the right solution.
Phase 01
Discover
Stakeholder interviews with Motability operators and claimants. Mapped pain points in the existing phone-only intake flow. Identified cognitive overload and wait-time anxiety as primary friction.
Phase 02
Define
Synthesised research into a single problem statement: claimants need to begin a claim at any hour with confidence their data is secure and their case is progressing.
Phase 03
Develop
Three divergent prototypes explored: form wizard, voice interface, chat-based flow. Usability tests showed chat best matched the existing mental model from phone calls.
Phase 04
Deliver
Converged on a single validated solution: chat-driven mobile interface with inline identity verification, office-hours-aware handoff, and a parallel agent console.
Research Methods Used
Stakeholder Interviews
Structured 30-min sessions with 4 Motability operators and 6 claimants. Focused on confusion moments, abandonment triggers, and unmet expectations in the current phone intake process.
Journey Mapping
End-to-end experience map from damage event to claim resolution. Identified 12 friction points — 8 occurred during the initial intake call before any claim was formally opened.
Usability Testing
Moderated prototype tests on 3 variants (form wizard, voice, chat). Chat scored highest on task completion (94%) and user confidence, confirmed by post-task SUS scores.
03 · User Flow
App Walkthrough
Seven screens from first contact to confirmed handoff. Tap any card to reveal the design rationale.
Good morning. To find your plan, please enter your Vehicle Registration, Policy Number, or Postcode.
AB12 CDE or L1 2AB…
The assistant greets the user and asks for VRM, Policy Number, or Postcode. Progress bar initialises at 15%.
Three entry points reduce friction for users who don't know their policy number
Input is normalised (uppercased, spaces stripped) before matching
56px minimum height on all interactive targets throughout
AB12CDE
Plan located. For security, please enter the first line of your address and postcode.
After plan lookup, a second security layer verifies the first line of address and postcode. Two failed attempts escalate to phone.
Verification badge appears inline — no modal or page transition
Error message uses role='alert' for screen reader announcement
After 2 failures the bot escalates to phone — never a dead end
Could you briefly describe what happened to the vehicle?
Describe the incident in your own words…
Free-text field captures what happened in the customer's own words. No validation constraints — the goal is frictionless recall.
No character limits or format constraints
aria-live polite region announces bot responses to screen readers
Textarea auto-grows to show full input without scrolling
To process your claim digitally, we need to send you SMS verification and updates. Do you consent?
Yes, I consent
No, cancel
Explicit, binary consent gate before digital processing begins. Refusing routes immediately to a phone number — no dead end.
Consent is binary and explicit — no pre-ticked checkboxes
Declining routes to a phone number immediately, not an error state
Both buttons are full-width and equal-sized to avoid accidental tap
Submit 2 Photos
Optional evidence capture with a dynamic 3-column grid. Button label switches once images are attached.
Upload is optional — Skip & Continue always available
Button label updates to 'Submit Photos' once images are added
Each uploaded cell shows a confirmation checkmark immediately
Secure Claim Code
DL-K7P2
Call 0300 037 3737
Secure claim code presented. Real-time office hours check determines live call CTA or callback booking.
Claim code generated client-side at submission
Office hours check uses device clock — no server required
Callback slot computed from next business morning if office is closed
Alex Smith · AB12 CDE · L1 2AB
Flag
Open File
Light-mode operator dashboard showing claim queue, verification flags, correspondence preference, and callback booking.
Light-mode inversion signals context switch to operator
All verification flags surfaced immediately without navigation
Claim queue uses left border colour to indicate urgency state
05 · Accessibility
WCAG 2.2 Compliance
Every interactive element was designed against WCAG 2.2 AA from the outset — not retrofitted. Accessibility is treated as a core constraint, not an audit checklist.
1.4.3 Contrast (AA)
Colour Contrast
All text maintains minimum 4.5:1 contrast. Warm White (#F0EEE9) on Obsidian (#080A0C) achieves 17.6:1. Ash (#A8A49D) on dark surfaces meets 4.6:1.
#F0EEE9 on #080A0C = 17.6:1
2.4.7 Focus Visible
Focus Rings
Every interactive element shows a visible amber focus ring (4px, orange-400) on keyboard navigation. Meets the enhanced 2.4.11 Focus Appearance criterion from WCAG 2.2.
4px amber ring · 2px offset
2.5.3 Touch Target Size
Touch Targets
All interactive elements enforce a minimum height of 56px — exceeding the 44×44px WCAG 2.2 requirement. Buttons span full width to maximise the tap zone.
56px minimum · full-width buttons
1.3.1 Info & Relationships
Semantic Roles
Chat messages use role='status' for bot responses. Error messages use role='alert' for immediate announcement. Navigation uses semantic landmarks.
role='alert' on all errors
3.3.1 Error Identification
Error Messages
Validation failures surface inline with a warning emoji, descriptive text, and an example of correct input. No colour alone conveys the error state.
Inline · descriptive · example-led
4.1.3 Status Messages
Live Regions
The chat container uses aria-live='polite' so every bot message is announced by screen readers without moving focus. The typing indicator carries aria-label.
aria-live='polite' on chat
All Criteria Met
| Criterion | Requirement | Implementation |
|---|---|---|
| 1.1.1 Non-text Content | Alt text for images | Camera icons carry aria-label; SVGs use aria-hidden |
| 1.4.1 Use of Colour | Not colour-only | Error states combine icon + text + border colour |
| 2.1.1 Keyboard | Full keyboard access | All buttons operable via Tab + Enter/Space |
| 2.4.4 Link Purpose | Descriptive link text | All icon-only buttons have aria-label |
| 3.2.2 On Input | No unexpected context change | Form fields do not auto-submit; progression is always explicit |
| 3.3.2 Labels | Input labels present | sr-only labels on all inputs; placeholder text is supplementary |
06 · Inclusivity
Designed for Vulnerable Customers
Motability serves customers with physical disabilities, cognitive impairments, and age-related challenges. Every design decision was evaluated through this lens — not as an edge case, but as the primary use case.
Physical & Motor
Large, Forgiving Touch Targets
All interactive elements are minimum 56px tall and span full screen width. No small icon buttons in the primary flow. Accommodates tremor, reduced dexterity, and single-switch navigation.
Visual
High Contrast & No Colour Reliance
Text contrast ratios start at 17.6:1. All status indicators combine colour with icon or label. Fully usable in high-contrast browser mode.
Cognitive
One Question at a Time
The chat metaphor reveals a single question before asking the next. Progress shown continuously with a labelled percentage. Error messages include a correct example.
Auditory & Screen Readers
Screen Reader First
Bot messages use role='status' so they announce without focus disruption. Errors use role='alert'. All form inputs have sr-only labels. No audio-only content.
Keyboard & Switch Access
Full Non-Pointer Operation
Every interaction is operable via Tab, Enter, and Space alone. Focus order follows visual reading sequence. Amber focus ring always visible. No time-limited interactions.
Language & Literacy
Plain English Throughout
Bot messages written at Grade 7 reading level. No jargon without explanation. VRM clarified inline. Correspondence preference uses plain labels — 'By Letter' and 'By Email'.
Escalation Paths
No Dead Ends
Every failure state provides a phone number. Security failures escalate after two attempts. Refusing SMS consent routes to a call, not an error. Phone number is a tappable tel: link.
Device & Context
Mobile-First, Low-Bandwidth Safe
No background requests, no lazy-loaded content. Entire claim flow works offline after initial load. Photo upload is optional. Operable one-handed in portrait orientation.
Design Principle
"Design for the hardest case first. If it works for someone with low literacy, a tremor, and a slow connection — it works for everyone."
The Motability customer base includes people with serious physical and cognitive conditions. Designing to the mean would exclude the customers who need this service most. Every constraint applied here makes the experience better for all users.
07 · Technology
Technology
A deliberately minimal stack — selected for zero build-step demonstrability.
React 18
useState · useEffect · useRef
Tailwind CSS
Dark theme · mobile-first classes
lucide-react
Shield · Phone · Camera · ArrowRight
CSS @keyframes
shimmer · animate-in · zoom-in-50
Native Date API
checkOfficeHours · getNextBusinessSlot
Blob URLs
Self-contained iframe sandbox
Why React without a build step?
Loading React from CDN via Babel standalone allows the app to run with no Webpack or Vite configuration.
Why Tailwind for a dark mobile UI?
Tailwind utility classes map directly to the zinc-950/900/800 palette — consistent dark theme with zero custom CSS for layout.
Why no routing library?
The entire flow is a single-page state machine. View state and step state drive all screen transitions.
08 · Trade-offs
Considered Trade-offs
Three architectural choices that define the character of this project.
01 —
Accessibility First
Every element was designed against WCAG 2.2 before any visual styling.
02 —
Chat as Progressive Disclosure
The chat metaphor reveals exactly one question at a time.
03 —
Runtime Office Hours
checkOfficeHours() computes availability from device clock — no network call required.
| Attribute | Decision Made | Alternative Considered |
|---|---|---|
| State management | useState + prop drilling | Redux / Zustand (overkill for 2 views) |
| Identity check | Client-side string match | API call (no backend in scope) |
| Animation | Tailwind animate-in + keyframes | Framer Motion (CDN weight concern) |
| Icon library | lucide-react (stroke-based) | Heroicons (similar, lucide more composable) |
| Theme | Dark zinc-950 palette | System preference toggle (deferred) |
Mobility
Flow.
A conversational mobile web interface guiding Motability customers through vehicle damage claims.
01 · Overview
Project at a Glance
A single-page React application that transforms a complex insurance claims intake process into a guided, accessible conversational interface.
🎯 The Problem
Motability customers reporting vehicle damage face extended call wait times with no digital self-service alternative available.
💡 The Solution
A step-by-step chat interface captures all claim details, verifies identity, and routes to a live agent or books a callback.
⚙️ Design Principle
Accessibility-first. Every interactive element meets WCAG 2.2 — minimum 56px touch targets, visible focus rings, full screen reader support.
📐 Scope
Single-file React application. Frontend-only — verification handled against mock data with no backend dependency.
02 · Process
Double Diamond Method
The Double Diamond framework structured every design decision across two diverge-converge cycles — first to discover the right problem, then to deliver the right solution.
Phase 01
Discover
Stakeholder interviews with Motability operators and claimants. Mapped pain points in the existing phone-only intake flow. Identified cognitive overload and wait-time anxiety as primary friction.
Phase 02
Define
Synthesised research into a single problem statement: claimants need to begin a claim at any hour with confidence their data is secure and their case is progressing.
Phase 03
Develop
Three divergent prototypes explored: form wizard, voice interface, chat-based flow. Usability tests showed chat best matched the existing mental model from phone calls.
Phase 04
Deliver
Converged on a single validated solution: chat-driven mobile interface with inline identity verification, office-hours-aware handoff, and a parallel agent console.
Research Methods Used
Stakeholder Interviews
Structured 30-min sessions with 4 Motability operators and 6 claimants. Focused on confusion moments, abandonment triggers, and unmet expectations in the current phone intake process.
Journey Mapping
End-to-end experience map from damage event to claim resolution. Identified 12 friction points — 8 occurred during the initial intake call before any claim was formally opened.
Usability Testing
Moderated prototype tests on 3 variants (form wizard, voice, chat). Chat scored highest on task completion (94%) and user confidence, confirmed by post-task SUS scores.
03 · User Flow
App Walkthrough
Seven screens from first contact to confirmed handoff. Tap any card to reveal the design rationale.
Good morning. To find your plan, please enter your Vehicle Registration, Policy Number, or Postcode.
AB12 CDE or L1 2AB…
The assistant greets the user and asks for VRM, Policy Number, or Postcode. Progress bar initialises at 15%.
Three entry points reduce friction for users who don't know their policy number
Input is normalised (uppercased, spaces stripped) before matching
56px minimum height on all interactive targets throughout
AB12CDE
Plan located. For security, please enter the first line of your address and postcode.
After plan lookup, a second security layer verifies the first line of address and postcode. Two failed attempts escalate to phone.
Verification badge appears inline — no modal or page transition
Error message uses role='alert' for screen reader announcement
After 2 failures the bot escalates to phone — never a dead end
Could you briefly describe what happened to the vehicle?
Describe the incident in your own words…
Free-text field captures what happened in the customer's own words. No validation constraints — the goal is frictionless recall.
No character limits or format constraints
aria-live polite region announces bot responses to screen readers
Textarea auto-grows to show full input without scrolling
To process your claim digitally, we need to send you SMS verification and updates. Do you consent?
Yes, I consent
No, cancel
Explicit, binary consent gate before digital processing begins. Refusing routes immediately to a phone number — no dead end.
Consent is binary and explicit — no pre-ticked checkboxes
Declining routes to a phone number immediately, not an error state
Both buttons are full-width and equal-sized to avoid accidental tap
Submit 2 Photos
Optional evidence capture with a dynamic 3-column grid. Button label switches once images are attached.
Upload is optional — Skip & Continue always available
Button label updates to 'Submit Photos' once images are added
Each uploaded cell shows a confirmation checkmark immediately
Secure Claim Code
DL-K7P2
Call 0300 037 3737
Secure claim code presented. Real-time office hours check determines live call CTA or callback booking.
Claim code generated client-side at submission
Office hours check uses device clock — no server required
Callback slot computed from next business morning if office is closed
Alex Smith · AB12 CDE · L1 2AB
Flag
Open File
Light-mode operator dashboard showing claim queue, verification flags, correspondence preference, and callback booking.
Light-mode inversion signals context switch to operator
All verification flags surfaced immediately without navigation
Claim queue uses left border colour to indicate urgency state
05 · Accessibility
WCAG 2.2 Compliance
Every interactive element was designed against WCAG 2.2 AA from the outset — not retrofitted. Accessibility is treated as a core constraint, not an audit checklist.
1.4.3 Contrast (AA)
Colour Contrast
All text maintains minimum 4.5:1 contrast. Warm White (#F0EEE9) on Obsidian (#080A0C) achieves 17.6:1. Ash (#A8A49D) on dark surfaces meets 4.6:1.
#F0EEE9 on #080A0C = 17.6:1
2.4.7 Focus Visible
Focus Rings
Every interactive element shows a visible amber focus ring (4px, orange-400) on keyboard navigation. Meets the enhanced 2.4.11 Focus Appearance criterion from WCAG 2.2.
4px amber ring · 2px offset
2.5.3 Touch Target Size
Touch Targets
All interactive elements enforce a minimum height of 56px — exceeding the 44×44px WCAG 2.2 requirement. Buttons span full width to maximise the tap zone.
56px minimum · full-width buttons
1.3.1 Info & Relationships
Semantic Roles
Chat messages use role='status' for bot responses. Error messages use role='alert' for immediate announcement. Navigation uses semantic landmarks.
role='alert' on all errors
3.3.1 Error Identification
Error Messages
Validation failures surface inline with a warning emoji, descriptive text, and an example of correct input. No colour alone conveys the error state.
Inline · descriptive · example-led
4.1.3 Status Messages
Live Regions
The chat container uses aria-live='polite' so every bot message is announced by screen readers without moving focus. The typing indicator carries aria-label.
aria-live='polite' on chat
All Criteria Met
| Criterion | Requirement | Implementation |
|---|---|---|
| 1.1.1 Non-text Content | Alt text for images | Camera icons carry aria-label; SVGs use aria-hidden |
| 1.4.1 Use of Colour | Not colour-only | Error states combine icon + text + border colour |
| 2.1.1 Keyboard | Full keyboard access | All buttons operable via Tab + Enter/Space |
| 2.4.4 Link Purpose | Descriptive link text | All icon-only buttons have aria-label |
| 3.2.2 On Input | No unexpected context change | Form fields do not auto-submit; progression is always explicit |
| 3.3.2 Labels | Input labels present | sr-only labels on all inputs; placeholder text is supplementary |
06 · Inclusivity
Designed for Vulnerable Customers
Motability serves customers with physical disabilities, cognitive impairments, and age-related challenges. Every design decision was evaluated through this lens — not as an edge case, but as the primary use case.
Physical & Motor
Large, Forgiving Touch Targets
All interactive elements are minimum 56px tall and span full screen width. No small icon buttons in the primary flow. Accommodates tremor, reduced dexterity, and single-switch navigation.
Visual
High Contrast & No Colour Reliance
Text contrast ratios start at 17.6:1. All status indicators combine colour with icon or label. Fully usable in high-contrast browser mode.
Cognitive
One Question at a Time
The chat metaphor reveals a single question before asking the next. Progress shown continuously with a labelled percentage. Error messages include a correct example.
Auditory & Screen Readers
Screen Reader First
Bot messages use role='status' so they announce without focus disruption. Errors use role='alert'. All form inputs have sr-only labels. No audio-only content.
Keyboard & Switch Access
Full Non-Pointer Operation
Every interaction is operable via Tab, Enter, and Space alone. Focus order follows visual reading sequence. Amber focus ring always visible. No time-limited interactions.
Language & Literacy
Plain English Throughout
Bot messages written at Grade 7 reading level. No jargon without explanation. VRM clarified inline. Correspondence preference uses plain labels — 'By Letter' and 'By Email'.
Escalation Paths
No Dead Ends
Every failure state provides a phone number. Security failures escalate after two attempts. Refusing SMS consent routes to a call, not an error. Phone number is a tappable tel: link.
Device & Context
Mobile-First, Low-Bandwidth Safe
No background requests, no lazy-loaded content. Entire claim flow works offline after initial load. Photo upload is optional. Operable one-handed in portrait orientation.
Design Principle
"Design for the hardest case first. If it works for someone with low literacy, a tremor, and a slow connection — it works for everyone."
The Motability customer base includes people with serious physical and cognitive conditions. Designing to the mean would exclude the customers who need this service most. Every constraint applied here makes the experience better for all users.
07 · Technology
Technology
A deliberately minimal stack — selected for zero build-step demonstrability.
React 18
useState · useEffect · useRef
Tailwind CSS
Dark theme · mobile-first classes
lucide-react
Shield · Phone · Camera · ArrowRight
CSS @keyframes
shimmer · animate-in · zoom-in-50
Native Date API
checkOfficeHours · getNextBusinessSlot
Blob URLs
Self-contained iframe sandbox
Why React without a build step?
Loading React from CDN via Babel standalone allows the app to run with no Webpack or Vite configuration.
Why Tailwind for a dark mobile UI?
Tailwind utility classes map directly to the zinc-950/900/800 palette — consistent dark theme with zero custom CSS for layout.
Why no routing library?
The entire flow is a single-page state machine. View state and step state drive all screen transitions.
08 · Trade-offs
Considered Trade-offs
Three architectural choices that define the character of this project.
01 —
Accessibility First
Every element was designed against WCAG 2.2 before any visual styling.
02 —
Chat as Progressive Disclosure
The chat metaphor reveals exactly one question at a time.
03 —
Runtime Office Hours
checkOfficeHours() computes availability from device clock — no network call required.
| Attribute | Decision Made | Alternative Considered |
|---|---|---|
| State management | useState + prop drilling | Redux / Zustand (overkill for 2 views) |
| Identity check | Client-side string match | API call (no backend in scope) |
| Animation | Tailwind animate-in + keyframes | Framer Motion (CDN weight concern) |
| Icon library | lucide-react (stroke-based) | Heroicons (similar, lucide more composable) |
| Theme | Dark zinc-950 palette | System preference toggle (deferred) |