Patient Portal Design
service example
A service example, not a client case study, showing how we approach accessible healthcare interfaces.
Service example. This page describes how FindX approaches a type of work. It is not a client case study, and no client, person, metric, or testimonial is represented here.
A patient portal is used by people who are unwell, anxious, or helping someone else. This example describes how we approach that context: reduce the number of decisions a patient has to make, and make every screen legible to the widest possible audience.
Accessibility is a design constraint, not a final check
Contrast, focus order, target sizes, and plain language are decided while the layout is being drawn, not retrofitted afterwards. Treating accessibility as a constraint early is what keeps it affordable later.
Reduce the decisions, not the information
Appointments, records, and care plans stay complete, but they are grouped around what a patient is trying to do rather than how the organisation is structured. A patient should not need to know which department holds a document.
Build for the team who maintains it
A portal is only as good as the next change made to it. We hand over component patterns and content rules so the internal team can add new care features without reintroducing inconsistency.
Tools we use
- Design: Figma, accessibility-first UI
- Frontend: React, Next.js
- Standards: WCAG-oriented component patterns