By John Gruber
Stop political robocalls & texts with Nomorobo!
24% off with code DARINGFIREBALL24.
Hillel Wayne:
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