The ward round is the spec

The documented process is a sincere approximation

Nobody is lying in a requirements document. They are describing the process as it is supposed to work, which is genuinely how it works on a good day with full staffing and no surprises.

The rest of the time it is adapted, and the adaptations are invisible to everyone except the people making them, because they are not deviations in anybody's mind. They are just how you get the work done.

What you notice by watching

The paper. There is almost always paper, and it is the highest-value artefact in the room, because a piece of paper somebody made themselves is a precise specification of what the software failed to give them.

The order of things. A documented workflow tends to describe steps in a logical sequence; a real one runs in the order that the corridor allows. Software that enforces the logical sequence adds friction at every step.

The re-entry. Watch for anybody reading from one screen and typing into another. Each instance is a missing integration, and unlike a feature request it is one nobody will ever raise, because it has stopped registering as a problem.

The conversations. A great deal of clinical coordination happens verbally and is never recorded anywhere. Some of that should stay verbal. Some of it is a handover that goes missing when the person does.

Ask what they do when it goes wrong

The happy path is usually well covered by whatever system exists. The exceptions are where the work actually is, and they are where you will find the workarounds.

What happens when a patient arrives without identification. What happens when a result is needed before it is verified. What happens when the system is down. Those answers describe the real operating envelope, and software that only handles the happy path pushes all of that back onto people.

Do not design in the room

The temptation while observing is to start solving, and it is worth resisting for an hour. Early solutions anchor on the first problem you noticed, which is rarely the most important one.

It also changes what people show you. Once you start proposing, you get feedback on your proposal rather than a view of the work.

The people doing the work are not the people specifying it

This is not a criticism of anyone; it is structural. The person with the authority to commission software is usually several steps removed from the ward, and the person who will use it every day frequently has no channel into the decision.

Watching is how that gets corrected. It is also why the engineers go, rather than only the designers a constraint explained second-hand becomes a requirement, while a constraint you have seen becomes a design.

Then go back after it ships

The second visit is the one that teaches you whether you understood. It is a different and more uncomfortable experience, and it is the only reliable way to find out which of your assumptions were wrong.

Go when the software has been in use long enough to have been adapted. The workarounds people have already built around your product are the most direct feedback you will ever receive, and nobody will think to tell you about them, because by then they are just how the job is done.