WritingEssay
Demand nothing of the doctor
Why the first design law for software in a forty-eight-second clinic is that it asks the doctor to learn nothing.
No. 24 · June 2026 · 4 min read
There is a design law for clinical software in Bangladesh that sounds like a constraint and is really the whole strategy: demand nothing of the doctor. A doctor seeing ninety patients in a day has no spare minutes, no patience for a tutorial, no appetite for a workflow that adds a step. Any product that asks him to learn it, change for it, or work around it has lost before it starts, no matter how good it is underneath.
This rules out most of what clinical software usually does. No new system to log into in the middle of a visit. No fields to fill that the paper pad did not already have. No training day the clinic cannot spare. The bar is brutal and clarifying: if using Glyph costs the doctor attention during the forty-eight seconds, Glyph has taken the one thing it was supposed to give back.
If using it costs the doctor attention during the forty-eight seconds, it has taken the one thing it was meant to give back.
So Glyph reduces the doctor's new behaviors to two: read a card, tap approve. The intake happened before he walked in. The briefing is already on the screen, red flags first. The note is already drafted in his format. His judgment is the only thing asked of him, and the act of recording it is a single tap. Everything else, the history, the reading, the writing, the signing machinery, runs around him.
This is why Glyph can enter a chamber without a rollout. There is nothing to roll out. The doctor does on day one what he did before, sees patients and decides, and the software arranges itself around that instead of asking him to arrange himself around it. Demanding nothing is not a limitation the product apologizes for. It is the only way software ever survives contact with a ninety-patient day.