Turning fragmented medical records into clinician-ready decisions.

The difficult part

A complex patient arrives with 34 pages of scanned PDFs: labs from three providers, a genetics report, a supplement list from memory. The information a clinician needs exists. It is just unreadable at the speed of a consultation.

The product tension sat one level deeper. AI can extract and summarise all of it, but an AI-generated health report that reaches a patient unreviewed is a safety problem, not a feature. Every design decision had to keep the clinician visibly, structurally in control: AI supports clinical judgement. It never replaces it.

The product story

I was the sole designer across product, brand, and documentation on a ~23-person team, and I designed all 10 modules from concept to production: records, biomarkers, diagnoses, procedures, genetics, medications, reports, patient management, billing, and onboarding.

1. Upload recordsA six-screen modal flow handles PDFs and images, upload progress, AI analysis, and every failure state. Designing the unhappy paths took longer than the happy one, as it should.
2. AI extracts structured dataBiomarkers, diagnoses, procedures, genetics, and medications land as structured, coded entries with reference ranges and history, not as a wall of summary text.
3. Clinician reviews and editsEverything the AI produces is editable. Review states (pending, in review, reviewed) are first-class objects in the interface, so trust is visible, not implied.
4. Generate the health reportThe Comprehensive Health Report combines all of it into a patient-facing document. It went through 8 design experiments and a 28-parameter quality checklist before shipping.
5. Clinician approves, then sharesApproval is an explicit act with an explicit record. The report a patient holds has a doctor's judgement behind it, by design.

The hardest sub-problem was biomarker trends. A number tells a clinician very little; the story lives in six months of movement and in how markers move together. I researched nine health platforms, wrote the graphing approach up in depth, and built six interactive HTML prototypes (sparklines, pinnable cards, a dedicated graph page, split views) so the team could argue about behaviour instead of screenshots. The final pattern: progressive disclosure, showing the most important correlation first and letting the clinician dig.

Design system and interaction thinking

The platform runs on a design system I built from zero: 80+ components, 86 documented colours, a 64-icon library, 48 button variants, and full state coverage for tables, inputs, toasts, and empty states. Every biomarker table knows how to be empty, loading, failed, filtered, and sorted.

One decision I would defend in any review: two separate visual languages. The platform is teal, Inter, dense, and fast, because clinicians live in it. The patient-facing report is navy, serifed, and calm, because it needs to feel like a trusted medical document on a kitchen table. One system serving both would have made both worse.

I also wrote the platform's documentation system: 26 files covering every module, component, and user journey, merged into the engineering repos. Design that only lives in Figma dies in Figma.

Result

“Outstanding job! In just one week, it felt as though we had been working together for over a month.”

Jasper Middendorp, Engineering Lead, N1 Healthcare

What changed in my thinking

Before N1, I treated documentation as the chore after the real work. Here it was the work: on a 23-person team with one designer, the system and its documentation were the only way design could be in every room at once. And I learned that in clinical products, trust is an interface element. You do not write “you can trust this” on a screen. You show the review state, the edit history, and the approval, and let the structure say it.