Most of you probably heard about what went wrong with the Hawaii missile scare not too long ago. Just in case you’re not familiar, below is an article that’ll show you what I’m referring to.

Image text which shows the complex menu used during the Hawaiian missile scare.

There’s an aspect of the scare and particularly the design failure of the navigation that is somehow thematic for me. Not only because I do work as a UX designer in Interaction Design (IxD) and Information Architecture, but also because I see how projects roll out as I work with clients who sometimes have 0% digital understanding on one side, and increasingly entrenched technical teams on the other.

The event simply prompted the return of a number of ideas I’ve had mulling around for the past 4-5 years. Here’s a few:

1. Success is not any easier when failure is abstracted 

Abstracted problems exist in a foreign context. This might happen for instance, when people feel pressured into time constraints and there’s an upstream failure to account for technical debt or mythical man month traps. Avoiding these is not always intuitive.

These are what I call knowledge traps: the effects of limited knowledge on decision making. Things like censoring outcomes or increased confidence based on limited knowledge. It is probably correct to refer these things as forms of bias.

2. Knowledge is a 2 way street.

You can’t order a SaaS the same way you order meat at a deli, even though it would be much easier. Imagine, your business process automation platform as simple as a pound of smoked turkey. All you have to do is consider what you need and then pay for it.

I don’t need to know why or how it happened, please don’t guide me through the process, onboard or educate me right now, just hand me the ground chuck please.

This productized approach is at odds with a complex service – that is, new information downstream changes the questions upstream.

3. When things break we accrue the compounding costs of making the mistake, dealing with the consequences, and doubling back to solve it again.

In a trading context it’s often said that one needs to make a 100% gain to recover from a 50% loss. In an organization, a 50% loss can also mean a lot of other things, very few of them generous conditions in which to make extraordinary gains.