← All work
2026
Healthcare
AI
Dashboard
Prio EHR
AI-native emergency department dashboard for physicians
Role
Sole designer, research led
Timeline
2026
Services
Product Design · Accessibility · AI
Tools
Figma, Claude, Perplexity
Industry
Healthcare
Status
Concept
Visit live site ↗
Overview
An emergency department dashboard built around one question: what does a physician need to see in the three seconds between patients?
Eight connected screens covering the full ED workflow from shift start to disposition, grounded in interviews with practising emergency physicians, with AI integrated only where pattern recognition genuinely helps and a component library verified to WCAG 2.1 AA.
Challenge
Physicians spend 5.9 hours of an 11.4-hour workday¹ inside their EHR, and emergency physicians average roughly 4,000 mouse clicks in a single 10-hour shift². Emergency medicine carries the highest burnout rate of any specialty at 65%³.
These systems weren’t badly designed by accident. They were designed for billing, and bedside care inherited the interface.
I took six documented failure points and treated each as a design brief: alert fatigue, documentation overload, excessive clicks, poor patient visibility, in-basket overload, and navigation that forces context switching mid-decision.
Constraints
My clinicians could only speak anonymously. Emergency physicians can’t go on record about the systems their hospitals run. I interviewed two, informally and under anonymity — no names, no institutions, no attributable quotes. That shaped how I had to build the argument. Two people is a starting point, not a sample, so every finding had to be corroborated against material I could cite before I designed against it: peer-reviewed research on EHR usability and alert fatigue, and real Epic ASAP training documentation from two academic medical centers.
The training docs turned out to be the sharpest source. They show exactly where a system is confusing enough to need explaining.
No deployment. Prio is a design concept — researched, prototyped and tested in principle, but never shipped. There is no production outcome data and I claim none.
Process
Interviews first. Two practising emergency physicians, informally and under anonymity, on where the current system costs them time and attention. Small enough that I treated what they said as hypotheses to check rather than findings to build on.
Corroborated, then designed. Every interview theme was checked against published research and Epic ASAP training documentation before it became a design brief. Six documented failure points resulted: alert fatigue, documentation overload, excessive clicks, poor patient visibility, in-basket overload, and navigation that forces context switching mid-decision.
The interaction design problem was the same on every screen: how much the system does before a human confirms.
Three principles governed every decision. Severity is the only language colour speaks — red, amber and green are never decorative. AI assists, clinicians decide; every suggestion carries a confidence score and plain-language reasoning. Every unnecessary click is a clinical risk.
Eight screens, one system. Track Board, Patient Summary, AI Anomaly Alert, Lab Results Timeline, Order Entry, Medication Panel, Shift Handoff and Disposition — connected in a working prototype, built from a component library and verified in Stark.
Decisions & Tradeoffs
My second and third principles contradict each other. Fewer clicks means automating more. Keeping the clinician as decision-maker means adding friction back. Every AI surface in Prio sits somewhere on that line.
On disposition I went furthest toward automation: the system recommends admission, states 91% confidence, and offers a single Apply button. Disposition happens at the end of a long shift when fatigue is highest and the supporting evidence is already on screen. The risk I accepted is automation bias — a tired physician clicking Apply without reading. I mitigated it by putting the reasoning inline rather than behind a disclosure, so the justification is unavoidable even when the shortcut is taken. I’m still not certain that’s enough.
Showing a number at all was a decision. A percentage invites false precision — 91% implies a calibration the model may not have. I kept it because clinicians already work in probabilistic language, and pairing it with plain-language reasoning means the number sets expectation while the sentence carries the argument. A confidence bar with no figure was the alternative I rejected as too vague to act on.
Two interviews, treated as two interviews. I could have run a survey and reported a percentage. With access to two clinicians and no institutional route to more, I chose depth over the appearance of breadth, and leaned the evidence base on published research instead. It means I can defend every claim on this page — and it means the design is only as good as its next round of testing.
Result
Eight connected screens, a working prototype, and a design system with a full component library — from problem framing to accessible final UI. Inclusive design verified in Stark: colour never carries meaning alone, every severity state is reinforced by label, position or icon, and every value on the lab timeline is shown with its reference range.
What I’d Do Next
I’d go back to the same physicians with the disposition screen, and design the session to fail. Show them a case where the AI recommendation is subtly wrong and measure whether they click Apply anyway. If the inline reasoning doesn’t stop them, it isn’t sufficient and the interaction needs real friction.
Second, the three-second claim. Timed first-glance tests on the track board with one question: which patient is sickest? Anything above three seconds means the severity encoding is decoration, not information.
Third, more clinicians. Two gave me direction; they can’t give me confidence.
Next project →
