Redesign of a US EHR for an outpatient clinic. The client was replacing a legacy EHR its staff had used for years. They knew all its workarounds, but everyday tasks took more steps than they should.
What changed
The interviews and walkthroughs gave us a clear list of gaps. Here’s what the redesign closed in the three flows I’m sharing. The sections below show how each one got there.
The work followed the five stages in the diagram below: Discovery, Define, Design, Validate and Build. Discovery and Define covered the whole EHR. Each flow then went through Design, Validate and Build on its own, and a loop sent Validate findings back to Design.
We started in Figma, before AI tools were common, then moved to v0, Obvious AI, and for the last five months Storybook with Claude Code. I prototype in code, so developers get something they can refine and ship. Figma stays for side-by-side comparisons and small layout tests. Several steps got faster, and design quality held.
We started by listening before designing anything.
Clinician input. The clinic’s head of communications gathered feedback from clinicians and became our main contact for how the clinic really works.
Legacy walkthroughs. Over several sessions, the clinic walked us through the old system: how each part worked, and why it was built that way.
Competitor walkthroughs. People who use Epic showed us how those systems handle the same tasks. They became our main reference.
Accounting team call. They opened with their frustrations, which became the starting point for Clinic Management.
With three designers, each of us owned specific areas. We built the foundations first (staff accounts, roles, permissions), then moved to dashboards and clinical flows.
Constraints
HIPAA. Every screen holds sensitive data, so each feature had to answer who sees what, and when.
A shared design system. New patterns had to fit what the team was building together.
Dev feasibility. This was critical for AI, where we designed only what the team could ship.
NDA. I can’t show the old screens, so I describe the problems instead.
The empathy map showed clinicians as people who work with a lot of data and are used to it. They want it dense and side by side, all in view, so they can read it like an X-ray. They also have little time, so every action has to be fast. That gave us one rule for the product: dense, but manageable and quick.
Before choosing where to go deep, we worked from a map of the whole EHR. A fellow designer drew it, and we came back to it whenever we needed to check how the structure fit together. It covers far more than the three flows in this case study: staff and admin management, scheduling system, patient billing and plans,patient charts and visit flow, etc.
I worked on many parts of the EHR on my own. I picked Vitals, Clinic Management and the AI assistant for this case study because they are the complex interesting to work on. Also, important to mention that I changed visual design to keep confidentiality of the project but all stages, logic contents are preserved as it was.
Here the focus moves from the whole EHR to three flows I owned. Each went through the same four stages.
Discovery
Discovery started with conversations with the team and executives, including the clinic’s accounting side. I recorded the calls in Otter and used NotebookLM to pull out the repeated frustrations, then turned them into jobs to be done. From those jobs I built the information architecture, broke each task into tables, and moved from a refreshed low-fidelity layout to the final design.
Clinic Management is the analytics area for the clinic’s executive and accountants. The old app had nothing like it, so I started from a blank page.
Define
No old version existed, so I started from the clinic’s accounting team and their frustrations.
The executive review added two asks: more patient and revenue data, and paid vs. outstanding bills as a trend.
Design
These have been selected:
The first screen shows how the clinic is doing right now: revenue vs. target, collections, payroll.
Detail sits one scroll or one click down, like the Expenses table.
Edit mode: each person shows or hides the cards they care about. The pencil in the header opens an edit bar that stays pinned while you scroll.
Validate
My colleague and I walked clinic staff through online prototypes.
Show/hide came straight from those sessions.
I ran design QA on every state afterward.
Build
I prototyped in code with Claude Code and Storybook. Developers refined and shipped it.
Screens: default, edit mode, scrolled, open Expenses table.
Clinic Management page. Presenting Edit Mode
Scrolled view. Collections and the detail behind the headline numbers sit one scroll down
Discovery
Since the clinic had no earlier AI version, discovery looked at how Epic and Oracle approach AI in their products in the extent it was possible at the stage. The goal was to find where an assistant could help without getting in the way. Those findings shaped the information architecture and the flows, which I prototyped in code with developers.
Define
No old version existed. I used the same inputs as Clinic Management. Lumen works like a smart colleague who helps untangle a case. Three jobs:
When I have a full day of patients, I want a quick read on each one, so I walk in prepared.
When results don’t add up, I want help connecting labs and history, so I can see what fits.
When I have a medical question, I want an answer with sources, so I can trust it.
Design
Two modes. General has no patient data. Patient shares the selected chart and is clearly marked.
Calm start. Home greets the clinician with a few suggestions. Detail waits until asked.
Honest answers. Every answer shows sources and a “verify before use” cue. The clinician decides.
Projects. Related chats and files stay together.
Validate
The executive and the team reviewed it. I didn’t test it with clinicians, so I treat it as a first version.
Build
I prototyped in code with Claude Code and Storybook. Developers refined and shipped it.
So the the final version has the following screens.
Home: a greeting and three suggestions.
General answer: sources and a verify cue on every answer.
Projects: instructions, files and threads in one place.
Project view: one topic, all its context.
Patient brief: last visit, problems, medications, labs.
Lumen AI Assistant Drawer Screens
Discovery
Discovery began with an audit of the legacy vitals screens to see what people relied on and where they struggled. I compared the same tasks in Epic and Oracle to see how they handle abnormal values and history. That led to a simpler structure: customizable visible vitals, abnormal values sorted first, and quick entry. The first version was built quickly and reviewed with developers.
Define
Vitals was the one flow with an old version, so I started from the legacy walkthroughs: what clinicians had to dig through to find a number.
The job: When I open a patient’s vitals, I want to see what’s off first, so I can decide what needs attention.
Design
Abnormal first. Out-of-range values are tagged and sorted to the top.
Your vitals, your view. Show or hide any vital, or add a custom one.
Fast entry. Add a value in a couple of clicks, without leaving the page.
Two views. Cards for a quick read, a list for scanning.
History and charts. Open any vital for its history and an expanded chart.
Validate
Our team has approved v1. I didn’t test it with clinicians, so I treat it as a first version.
Build
Designed in Figma.
Adding New Vital. Card/List View.
Vitals Modal Screens
This project showed me how much B2B SaaS depends on fit. Every clinic works its own way, so customization mattered as much as the screens themselves.
Finding the balance between dense and simple was my favorite challenge, even when I didn’t get it right.
I prototyped with AI and in code, and developers refined and shipped it. Next time, I’d test more at every stage and measure each part as it ships.
