Healthcare services · 2024
Corvus Care
Booking that works on the first attempt
Corvus runs eleven clinics and takes most bookings through a patient portal built in 2016. Patients could not complete a booking without calling, and staff spent their mornings fixing appointments rather than making them. We redesigned and rebuilt the scheduling flow around the two things that actually matter: availability people can read, and a form that forgives mistakes.
- Product design
- Accessibility
- Scheduling
- Client
- Corvus Care
- Sector
- Healthcare services
- Year
- 2024
- Disciplines
- Development, Design
Challenge
What was in the way
The portal asked for insurance details before showing whether an appointment existed, so most people abandoned it and phoned instead. One booking in six generated a support call, and the average completed booking took four minutes and twelve seconds.
Accessibility was the harder problem. A significant share of patients use screen readers, magnification or keyboard navigation, and the calendar was a table of unlabelled buttons that announced nothing useful. For those patients the portal was not slow, it was unusable.
Approach
How we worked
- 01
Show availability first
We inverted the flow. Location, clinician and open slots come first, personal and insurance details last, with the appointment held for ten minutes while the form is completed. People now know there is something to book before being asked to prove who they are.
- 02
Built for assistive technology from the first commit
The calendar is a real grid with roving focus, announced dates and live-region confirmation of every selection. We tested with screen readers and keyboard only at every milestone rather than auditing at the end, and eight patients using assistive technology tested the build before launch.
- 03
Forgiving forms
Validation happens on blur and again on submit, never on every keystroke. Errors are described in plain language next to the field, summarised at the top of the form, and focus moves to the first problem. Partially completed bookings survive a dropped connection.
Deliverables
What we handed over
- End-to-end redesign of the scheduling flow
- Accessible component library with documented patterns
- Front-end rebuild with typed API integration
- Assistive technology testing with real patients
- Staff-facing admin views and reporting
- Accessibility statement and remediation guide
Results
What changed after launch
62%
Fewer support tickets
Scheduling-related contacts over the first three months after launch.
90s
Median booking time
Down from four minutes twelve seconds on the portal it replaced.
100%
WCAG 2.2 AA on core flows
Verified by third-party audit across booking, rescheduling and cancellation.
“The phones went quiet. That is the whole review, really.”
Stack and tools
What it runs on
Build
- Next.js
- TypeScript
- Typed API client
- Server-side rendering
Accessibility
- WCAG 2.2 AA
- Screen reader testing
- Automated axe checks in CI
Operations
- Audit logging
- Role-based admin
- Uptime and error monitoring
Timeline
How long it took
- Weeks 1 to 3
Research
Call-log analysis, staff shadowing, and usability sessions including assistive technology users.
- Weeks 4 to 7
Design
Flow redesign, accessible component patterns, prototype tested twice with patients.
- Weeks 8 to 15
Build
Scheduling flow, admin views and integration work, with accessibility checks on every pull request.
- Weeks 16 to 18
Pilot and rollout
Two clinics first, then a staged rollout across the network with staff training.