Designing for someone who doesn't have time to learn your product
April 2026
I was mid-usability session when the phone rang. Not a soft ring. A beep-beep-beep that cut through the quiet of the conference room. The clinician I was talking to looked at me, then at the phone, then back at me. “I have to go,” they said. “The room is calling me.”
That was the moment I realized we weren’t just designing for a user. We were designing for someone who couldn’t be interrupted. Not because they were busy, but because their job was to be available. And that’s when I started to understand how different the design process had to be.
Onboarding doesn't happen on the onboarding screen
The first time I saw this constraint in full force was in the onboarding phase of Fold Health. We had a beautiful onboarding flow. It was clean, it was helpful, it was well-designed. But it was also not what clinicians needed.
They didn’t have time to go through a tutorial. They didn’t have time to read empty-state copy. They didn’t have time to watch a video. They had time to do work, and that work was urgent.
So the real onboarding — the moment someone gets their first bit of useful work done — became the most important screen of all. Not the one that introduces the product, but the one that makes the product useful.
This means that the first chart review can’t be the user’s first encounter with the schema. The first screen they see when they open the app has to be useful, not explanatory. The empty state has to do something — not just tell the user what to do.
The Figma file lies more here than anywhere else
In most design processes, we can trust our Figma files. We can trust that a prototype will give us a good sense of how a user will interact. In healthcare, that trust is fragile.
Clinicians are not just distracted — they are fragmented. Their attention is split between a patient, a screen, a task, a phone call, a pager. They don’t have the luxury of focusing on a single interface for more than a few seconds.
A static prototype can’t capture that. A Figma file can’t simulate the real-world context of a clinician’s attention. It’s not just about the interface — it’s about how the interface sits in the flow of their work.
We had to design with real-time feedback. We had to test with real clinicians in real moments. And that meant iterating in the field, not in a design review.
The instinct to add a help text is almost always wrong
There’s a strong urge to add tooltips, help text, and explanations. It’s the designer’s version of “just in case.” But in healthcare, just in case is a luxury we can’t afford.
The instinct to add a help text is almost always wrong. It’s a distraction. It’s a signal that something is unclear. And in a field where clarity is life-or-death, that’s not a signal you want to send.
Better defaults beat better tooltips. A button that says “Save” is better than one that says “Save (click to save your changes)”. A form that auto-saves is better than one that asks the user to confirm. A screen that works without explanation is better than one that requires explanation.
What clinicians actually appreciate
I’ve learned that clinicians notice things that designers often overlook. It’s not the flashy animations or the polished micro-interactions. It’s the quiet things.
- Keyboard shortcuts
- Screen density
- Calm color palettes
- The absence of celebratory micro-animations
They don’t need to be told how to use the product. They need to be allowed to use it — without friction, without distraction, without explanation.
They appreciate a screen that doesn’t make them think. They appreciate a screen that just works.
And that’s what I learned from designing for clinicians — that the best design is the one that doesn’t need to be explained.