My take on the infamous Hawaiian fake missile alert — it’s never just about the UI — it’s bad service design.
A lot of people in my network have been writing about the terrible interface design that helped that poor guy cause the Hawaiian Fake Missile alert. From other reports, the guy selected “DRILL — PACOM (CDW) — STATE ONLY” then on the following screen accidentally chose “PACOM (CDW) — STATE ONLY”and terrified everyone unfortunate enough to be in the possession of a smartphone. Apparently he’s since been ‘reassigned’. I feel awful for him.
There is no arguing that the UI is terrible and if you take a closer look at some of the photos circulating actually terrifying — check out the other chaos he could have caused by issuing a Tsunami warning! My first thought was that this is another case of severe under investment in UI that helps people do their jobs and that he was doing a stellar job covering for these poor systems to not slip up until now.
But then as I read more coverage it struck me that beyond the UI no one is talking about the bad Service Design that created a situation where his every click is fraught with danger.
How does it come to it that he has to work with such a terrible interface?
Why is the flow so badly thought through that this guy can even move from test back to real life missile alert? How is that even a thing?
At Adaptive Lab we like the definition of Service Design that describes it as a way to make services usable, useful, efficient, effective and desirable. Our multidisciplinary designers have applied our Service Design methodology to improve a whole range of existing services and to design new services from scratch.
In our experience, this isn’t an isolated incident. We’ve seen it with other clients, their employees doing a dance with the devil assimilating data on the fly from three programs and four screens, risking huge manual errors, making their own notes to keep track and deliver the best service possible to customers.
It seems that companies and governments love to pay for beautiful user-facing UI but baulk at investing in improving the employee experience as a way of improving things for the users. We see this all the time in our service design projects, it’s the dark matter we have to deal with — the politics behind why there’s never quite enough money or impetus to invest in the right tools to do the job, so many employees end up working around terrible interfaces such as those above.
Beyond this, the bigger issue was that once the alert was out in the wild, it took way too long for the organisation to notice, to calm the public down and to rectify the situation. This is also a symptom of bad service design. Good services are designed to account for special events that cause variances in the standard way of doing things, as everyday events. Good service design would have already helped this guy and his team to know what to do when mistakes are made.
It seems to me that a few other things were missing that some solid Service Design would have addressed:
How the whole service this team provides works together: the biggest issue to me wasn’t that that one guy made an easy mistake, it was how the service failed to work together to rectify it. Good service design delivers a unified and efficient system, rather than something that is a disjointed sum of its parts.
Technology & Systems: where were the inbuilt decisions and approvals in the systems he was using? How many other people have access to launch these kinds of missile alerts? Surely this should be tied to series of decisions mapped out in a workflow that requires more than one wrong click to execute on?
How the digital works with the rest of the service and wider organisation: how did people on the ground not realise that this had happened and move to fix it right away? Surely if there is a missile alert, many other teams will spring into action. Where were these teams and why weren’t they coordinated?
How teams are designed: where was his backup and support? Where were the approvals and governance? Did he have the right training to be operating (the terrible) system? How is this bad service design his mistake to take responsibility for?
How data is collected, analysed and used to make decisions: this kind of response makes me ask the question — what is the data model that underpins their systems and decision making? How are they using data to inform their actions and the decisions that they take as an organisation? What data do they need before a real missile alert is sent out? How does that data get to them and how is it shared?
The dark matter: finally, why is it that there hasn’t been investment in improving the tools that this guy and his team has to work with? What’s standing in the way?
If it is true that this guy has been reassigned, I hope that his bosses reconsider. This really wasn’t his fault and it wasn’t just the UI either, it was the entire service that sits around it.
jessleitch 