Unhappy Path Driven Development

A relevant ad will be displayed here soon. These ads help pay for my hosting.
Please consider disabling your ad blocker on Pony Foo. These ads help pay for my hosting.
You can support Pony Foo directly through Patreon or via PayPal.

This story — about all the things that could, and do, go wrong in software design and development — is an incredibly important cautionary tale about the work we do in our field, and our role in it.

Read it thoroughly and always from the perspective of how, given the domain, the product failed its us. Customizability breeds problems because it’s the opposite of enforcing constraints, which are fundamental to robust system design. Without constraints, it becomes difficult to scope the impact of changes, to understand how different consumers use our products, and thus, to build.

Repeating information under the format, over and over, dilutes its meaning. Imagine if instead, the application displayed an image of the medicine and maybe even a cute visualization of the pills the hospital would be administering. It’s the same repetition, but easier to digest.

The article talks about the perils of mode switching (think the Caps Lock key and password inputs, or in their case: dosage units). When you’re in a mode, the application should make it obvious that that’s your life now. Otherwise, chaos ensues. (oh hi vim!)

A perhaps even more crucial-to-get-right mode is failure. The product indeed had warnings about the case where an overdose is ordered. Along with just about everything else. In a month, systems for a hospital like the one in the article dump over 381,560 such alerts on the staff.

It’s easy to blame the user. They ignored the warnings, repeatedly. Or the induction process where staff learns early on to ignore every warning the system lobs their way. And for good reason: they wouldn’t be able to do their work otherwise. The user is hardly ever to blame.

The problem here, as is often the case in it industry, is that we want so hard to believe the “happy path” is what’s most important. After all, it’s what we sell. But no. The many, extremely sad garden paths of despair is what we should be must focused on. So what does that mean?

A holistic approach to failure modes. Users trust the system, and in the case of a hospital, they trust process above all. When every single action results in a warning, then warnings mean absolutely nothing. We know that perfectly well, so why do we keep doing this?

Then you get exactly what happened here: users ignore virtually-always meaningless warnings but trust the process and the inputs made by staff before them.

So how do we fix this? Better input modes, visual confirmation of the correctness of those inputs, judicious use of warnings with different severity levels, and for the love of the Matrix, fewer customizability options to prevent an untestable cambrian explosion of use cases.

Liked the article? Subscribe below to get an email when new articles come out! Also, follow @ponyfoo on Twitter and @ponyfoo on Facebook.
One-click unsubscribe, anytime. Learn more.

Comments (3)

Tamal Anwar wrote

It happens all the time, me as a user want to just trust the system with all my data, and accept all the terms and condition. I am in a rush to access the content, and not want to be bothered by the security.

So I think us developers and site owners should take the extra step and fully secure the account and data. I am also thinking if there is a way to fully eliminate the need of a password?

Tamal Anwar wrote

My first comment was dealing about using general websites and security features, I totally overlooked the link you shared, sorry about that.

For me, when it comes to life and death situation, like what happened in the hospital, one should pay extra caution when dealing with the doses. They should double and triple check it.

David Colacilli wrote

I also overlooked that link. Until then, this article was 50% nonsense, haha. “The user is hardly ever to blame”! XD. Thanks, Nicolás, for the article. In the “how to fix this” advice, I’d also mention inline warnings as a much better signal: we don’t just say that something is wrong, but what, where and why, in the same place