Many ambulances now have electronic PCRs, which fix a lot of these
problems. The report is automatically filed with the hospital. The
software can enter timestamps and fill in necessary boilerplate.
By spellchecking known medications it saves time at the hospital.
Nobody has to guess whether you scrawled “100mg” or “160mg”.
The ambulance I shadowed had an ePCR. Nobody used it. I talked to
the EMTs about this, and they said nobody they knew used it
either. Lack of training? «No, we all got trained.» Crippling
bugs? No, it worked fine. Paper was good enough? No, the ePCR was
much better than paper PCRs in almost every way. It just had one
problem: it was too slow.
It wasn’t even that slow. Something like a quarter-second lag
when you opened a dropdown or clicked a button. But it made things
so unpleasant that nobody wanted to touch it. Paper was slow and
annoying and easy to screw up, but at least it wasn’t that.
I think about that a lot.
I think the difference between UI design and UX design often gets lost in a lot of highfalutin jargon. But at a basic level there is a clear difference: the interface might be well designed and clear, but if it is slow and laggy, the experience of using it will be unpleasant, and people will go out of their way to avoid using whatever it is.
I repeat this point often, but it’s a moral obligation for designers to keep in mind what users will do, not what they “should” do. These EMTs perhaps should use the ePCRs because doing so might reduce errors; but in practice they stick with paper and pen because the ePCR machines are slow.
See also: Craig Mod’s “Fast Software, the Best Software” essay, which I linked to a few weeks ago.
★ Friday, 16 August 2019