Designing for three in the morning

The demo is not the condition

Software is demonstrated in a quiet room, on a large screen, by someone who knows where everything is, to an audience who is paying attention. Not one of those conditions holds in use.

In use it is a shared workstation with a resolution nobody chose, in a corridor, with two people waiting, from a person who last used this screen eleven days ago. Design that assumes the demo conditions will be beautiful and useless.

Fatigue changes what an interface has to do

A tired person does not read. They pattern-match. They look for the shape they remember and act on it, and if two shapes are similar they will occasionally act on the wrong one.

So distinctness beats elegance. Two actions with different consequences should not look like siblings, however tidy that would be. The destructive action should not be adjacent to the routine one. The confirmation should state what will happen in the same words the person was thinking in, not in the system's vocabulary.

And the screen should be honest about state. 'Saved' should mean saved. A spinner that resolves optimistically before the server has agreed is a small lie that becomes a large one at the point somebody walks away.

Error messages are clinical documentation

The worst error message tells the user that something went wrong. The second worst tells them a code. Both push the problem to someone who cannot act on it.

A useful message says what failed, what it means for what they were doing, and what to do next in that order, because that is the order the person needs it. If the answer to 'what to do next' is genuinely 'call somebody', say who.

This costs writing time and saves phone calls at two in the morning, which is a trade any team should take.

Defaults carry more weight than you think

Under time pressure, the default is the decision. Whatever the form is pre-filled with is what will be submitted a meaningful share of the time, and no amount of training changes that.

So defaults get treated as clinical content, not convenience. A default that is right ninety per cent of the time and dangerous the other ten is worse than no default at all, because it converts an active choice into a passive one.

Where there is no safe default, we leave it empty and make the emptiness visible. An unfilled required field is a small friction. A quietly wrong pre-filled one is not.

Density is not the enemy; undifferentiated density is

There is a reflex to declutter clinical screens, and it is often wrong. Clinicians want a lot of information at once what they cannot use is a lot of information with no hierarchy.

The work is not removing data. It is making the three things that matter now visibly different from the forty things that might matter later, and keeping that ranking stable so the eye learns where to go.

Assume the interruption

Nothing in a hospital is completed in one sitting. Someone will be interrupted mid-task, and the software should treat that as the normal case rather than an edge case.

That means partial work survives. It means coming back to a task shows you where you were and what has changed since you left. And it means never punishing someone for the interruption by making them start again.