Say it once.

Scope

One problem, taken all the way

EHR.ai is a clinic management system. It does scheduling, pharmacy, labs, billing. None of that is this case study.

This is about the ten to fourteen minutes a doctor loses per patient writing the visit down — and what happens when the note writes itself from the conversation that already happened, with the doctor reviewing rather than typing.

The second column matters as much as the first. Scoping this to documentation — and refusing to drift into clinical judgement — is what kept the trust model simple enough to ship.

The problem

The record competes with the patient

A physician running a twenty-minute outpatient slot has two jobs in the room and only enough attention for one. Either she types while the patient talks, and the patient watches the top of her head, or she waits and writes afterwards — and the notes stack up until they get finished at nine at night. Clinical informatics has a name for the second one: pajama time.

Neither option is a workflow problem you can schedule your way out of. The note has to be written, it has to be accurate enough to defend, and it has to print onto clinic letterhead for the patient to carry home. The only variable is who does the typing.

That third number became the whole thesis. The note already exists as speech. It is being thrown away and retyped.

Research

Nine doctors, two clinic days, one diary study

I needed to know three things before drawing anything: how long documentation actually takes, where in the consultation it hurts, and what a doctor would need to be true before letting software write into a medical record.

Five findings that shaped the product

Who it's for

Two people have to say yes

A doctor who will only adopt this if it is faster than typing, and a skeptic who will only adopt it if it is more accurate than his transcriptionist.

The brief

What the design had to do

The visit note should exist by the time the patient stands up — without the doctor typing it, and without her trusting it blindly.

How might we

Constraints I designed against

Feature set

What made version one, and what didn't

The longlist ran to nineteen ideas. Most were good. Shipping them would have turned a documentation tool into a clinical decision system, which is a different product with a different risk profile and a different regulatory conversation.

Information architecture

Grafting a new branch onto a product that already exists

EHR.ai had six top-level areas and a settled mental model. The transcription flow couldn't be a seventh destination in the sidebar — documentation isn't a place you visit, it's something you do to a visit. So it lives inside the patient branch, one step from the visit overview, with manual notes as its permanent sibling.

User flow

Including every way it goes wrong

The happy path is four steps. The design work was in the other branches: consent that hasn't been captured, consent withdrawn mid-sentence, a weak microphone, a file that's too big, and a section the doctor disagrees with. Each of those has to fail without destroying the visit.

Journey map

The same twenty minutes, twice

Mapping the consultation end to end made the shape of the problem obvious. The doctor's experience is fine — good, even — right up until the moment the patient stops being the thing she's paying attention to.

Sketches

Six ways to put a microphone in a consultation

The first question wasn't what the recorder looks like — it was where it lives. A modal interrupts. A separate page loses the patient's context. A docked bar is always present, which is exactly wrong for a feature that should only exist when consent has been given.

Low fidelity

Testing the layout before the pixels

Greyboxes went in front of four doctors on a laptop. Two things changed as a result. The transcript panel moved from below the recorder to beside it, because doctors wanted to watch the words land while still seeing the patient's risk flag. And the empty state stopped being blank — it now says what will appear and what to do to make it appear.

Final interface

Seven screens, one uninterrupted path

The flow runs from the morning list to a printed prescription without the doctor leaving the patient's context or typing a clinical sentence. Each screen below carries the decisions that produced it.

1

The morning list

The day starts here, and the visit reason column is doing real work. It carries enough clinical detail that the doctor walks into the room already oriented — which is what makes a short, high-signal consultation recordable.

• Start visit is a filled button only on the next two patients. Everything else offers Prep, so the primary action is never ambiguous.
• Visit reasons are written as clinical shorthand, not appointment categories, because that's what the doctor reads in the four seconds before the patient sits down.

2

The visit overview, where the fork happens

Two buttons, equal weight in the layout, unequal weight in emphasis. Transcribe audio is primary; Manual notes sits beside it permanently. The bar along the bottom explains the choice in a sentence rather than assuming the doctor knows what transcription will do to her record.

• Consent on file appears in the patient header line, next to the appointment slot. It's status, not a prompt — the coordinator already handled it at check-in.
• Labs, medications and conditions are on this screen and not the recording screen. The doctor reads them before the microphone opens, so recording time stays conversation time.
• The footer bar links to Consent settings rather than hiding them in the global settings area, because that's where the question occurs to people.

3

Before anything is recorded

The empty state names what will appear and what to do to make it appear. It also states the constraint that testing showed mattered most: draft outputs require doctor review. That sentence sits in the page subheading, not in a dismissible tooltip.

• The patient card repeats name, risk flag, visit type, room and clinician. During a recording, this is the only patient context on screen, so it has to be complete.
• Consent captured carries a check mark and a colour. Recording is not reachable without it.
• The file limit and accepted formats are printed on the dropzone, before the error rather than after it.
• Transcribe audio is disabled and stays visible, with the reason stated directly beneath. Hiding a disabled action makes people hunt for it.

4

Listening

The transcript is laid out as a conversation with speakers on opposite sides, because the thing a doctor scans for is attribution. "Patient reports tingling" and "on examination, tingling" are different clinical claims, and the note depends on getting that right.

• The recorder reports its own health: model, latency in milliseconds, input device, signal strength and input level in decibels. Dr. Shetty's objection was mishearing — this is the screen that answers it, continuously.
• Stop is tinted red and separated from Pause. Stopping ends capture; pausing doesn't. Those outcomes shouldn't look alike.
• The exchange count sits next to the generate button, so there's a concrete sense of how much material the note will be built from.
• Generate EHR note is dark and heavy — the one moment in the flow where the doctor hands work to the system.

5

The eight seconds of waiting

A spinner here would have been a missed opportunity. Naming the six stages — and the vocabularies each one uses — does two jobs: it makes the wait legible, and it quietly establishes that entities are being mapped to SNOMED CT, RxNorm and ICD-10 rather than invented.

• Stages are named after clinical outcomes, not engineering steps. "Generating chief complaint and history", not "running inference".
• The final line reads Review-ready and carries the doctor's name. The system is explicitly handing the note back, not finishing it.
• The page behind stays visible and dimmed. The transcript is still there if the doctor wants to check something mid-generation.

6

The note arriving, section by section

Sections fill in sequence and the print preview builds alongside. The doctor can start reading chief complaints while examination is still being written, which is why time-on-task fell further than raw generation speed accounts for.

• Every section has its own microphone and eye icon: re-dictate this section, or toggle whether it appears on the printout.
• The counter reads 8 of 8 sections visible in preview, so the relationship between editor and printout is never a guess.
• Actions are Save note and Print. The word "sign" does not appear anywhere in this product.

7

Review-ready

The finished draft, in clinical language, on clinic letterhead, with the prescription block laid out the way the clinic already prints it. What the doctor approves on the left is exactly what comes out of the printer on the right — no second formatting pass, which is where a full minute per patient used to go.

• Allergies reads NKDA — no known drug allergies, written out. Abbreviations that carry safety weight are expanded on the printed sheet the patient takes home.
• Examination keeps numbers as numbers: BP, HR, RR, SpO₂, temperature, BMI. These are the values most likely to be misheard, so they're the values most visible for checking.
• The risk flag follows the patient through all seven screens, in the same position and the same colour.

Decisions

Six choices that would break the product if reversed

Testing

Six doctors, three tasks, one prototype

Moderated sessions on a clickable prototype with scripted consultation audio. Each participant recorded a visit, reviewed the generated note, corrected at least one deliberately wrong section, and printed.

What testing changed

What's next

The parts I'd want to get wrong early