Designing trust into an AI-assisted clinical workflow.

The difficult part

Medical records arrive as PDFs, lab results, genetic reports, and long health histories. The information is valuable, but its original format makes it difficult to review as one coherent record.

The product tension sat one level deeper. AI could extract and organize information, but the interface could not imply that an automated output was final clinical truth. The workflow therefore had to make the human checkpoints explicit: AI supports clinical judgment; the clinician remains in control.

The product story

I worked across the product flow, the visual system, and the documentation that made the work easier to build. The central design question was always the same: how do we make dense information reviewable without making the interface pretend to know more than it does?

1. Upload recordsThe flow starts with medical records in supported document and image formats, with visible processing and failure states.
2. Organize extracted dataBiomarkers, diagnoses, procedures, medications, and genetic markers become structured entries instead of one long summary.
3. Review and editExtracted values and report sections stay editable. Processing, review, and approval are states the interface shows directly.
4. Shape the reportI explored different Client Health Report directions and narrowed the work toward clearer tables and the issues the product could communicate reliably.
5. Approve, then shareSharing follows clinician review and approval. That order is a product rule, not a line of marketing copy.

The other major thread was trend visibility. The existing path to a biomarker graph took several interactions, so I reviewed nine health and data products, compared patterns, and built interactive HTML prototypes for highlights, sparklines, comparison views, and a dedicated graph page. The work was research and prototyping, not a usability study, so I am presenting it as explored direction rather than a measured improvement.

System work that made the flow possible

I documented the product across five sections: overview, journeys, features, components, and appendix. The documentation made states, empty cases, and handoff decisions visible beyond the Figma file.

The app and the report needed related but distinct reading modes. The product interface could be dense and interactive; the report needed to feel calm, structured, and safe to review and print. A single visual language would have made one of those contexts worse.

The work also included eight CHR design directions and a documented icon set. Those counts describe the design and documentation effort; they are not being presented as user or business impact.

Result

The result was a clearer design direction for a high-stakes workflow: visible review states, a more deliberate report scope, reusable chart patterns, and documentation that another team could build from.

“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

I am deliberately leaving out a time-saved or clinical-accuracy percentage here. The available evidence documents the work and the artifacts, but not a measured usability study or shipped analytics.

What changed in my thinking

In clinical products, trust is an interface element. You do not create it by writing “you can trust this” on a screen. You show the source, the review state, the editability, and the approval step, then let the structure carry the promise.