Designing Around the Model
NYU Langone's HiBRID Lab studies how digital tools shape patient and provider experience, across remote patient monitoring, clinical decision support, and AI-enhanced digital assistants. With Medical Center Information Technology, the team runs research, workflow analysis, prototyping, usability testing, and rapid pilot testing.
I worked across four projects there. What connected them wasn't the clinical subject matter. Each one ran into the same three questions about the model underneath, and the answers reshaped the interface more than the model's accuracy ever did: what can it do, what can't it do, and how long does it take?
Clinical AI gets evaluated on whether it's right. In practice, that was rarely the thing that decided whether it worked. A correct recommendation arriving after the patient left, or hedged behind data nobody knew was missing, changed nothing.
How might we design clinical AI around what the model can't do, rather than around what it can?
- Designed a statin decision-support tool with a physician lead and a second UX designer
- Ran usability sessions with prescribers and coded them with a second observer
- Built an interactive patient journey tool used by project coordinators to capture information gaps
- Designed and built an automated content pipeline on the Anthropic API, from intake form to review queue
- Translated research findings into placement and content guidance across four Epic surfaces
The content pipeline I built for the lab drafts captions and graphic fill sheets from a single intake form. It could have been an open text box. Instead it runs on eight fixed formats, each with its own layout and prompt. Constraining the generation is what made the output reliable enough to hand to a reviewer instead of a rewriter.
The same logic ran in reverse on a cardiology chatbot proposal. Before designing anything, the question was whether a chatbot could do something the patient portal already couldn't. I built a journey tool that let coordinators capture where information actually goes missing across eight phases of care, so the capability question got answered with evidence instead of enthusiasm.
In a statin decision-support tool for primary care, the interface automates risk stratification across a risk score, guideline risk enhancers, and imaging signals. The decision that mattered most was showing the negative space: how many qualifying triggers were absent, which biomarkers were never measured, which imaging was never ordered.
A recommendation that looks confident because it's missing data is worse than one that says so. So the tool states its recommendation, attaches the guideline class, expands to show supporting factors, and weights Order and Decline equally. It never places the order.
In usability sessions with prescribers, we found nudges only change behavior when they land at the moment of decision. Providers noticed nudges, agreed with them, and moved on anyway. The gap between agreeing and acting was the design problem, and it was almost entirely timing.
Journey research surfaced a sharper version. A behavioral health score takes about fifteen minutes to finish computing after a visit ends. The patient is already gone. The score arrives in the portal later, alone, with nobody there to explain it. A number that would have been a conversation becomes a PDF.
On the generation side, the same constraint drove architecture. Model calls are slow enough that a synchronous generate button would have felt broken, so the pipeline runs on background functions with an approval queue. Nobody waits.