In this case, the citizens of Hawaii paid for the bad system design with 48 minutes of existential horror.
But these kinds of mistakes happens ALL THE TIME with "enterprise applications." Oracle has similar horrendous UX for their EBS (Enterprise Business Suite), so does SAP, Siemens, etc. People regularly make costly mistakes in shipping and receiving, purchasing and manufacturing because they have to deal with shitty confusing applications that look just like that screenshot.
Totally not surprising that the internal application for public emergencies has the same awfulness as PTO request.
I expect the same employee in Hawaii fumbled the UI on their "time off request" for psychiatric counseling too.
Currently unscrewing one of those as my day job.
"Delete all production orders for period" - no confirmation, no ability to rollback (beyond me restoring from a backup) that kind of thing.
It's not that it isn't user friendly, it's that it is actively user hostile.
Hah! I built one of those once! The (very abbreviated) conversation went something like this:
"I need a way to bulk delete orders."
"Umm... Are you sure? I can't think of a good reason to delete a bunch of orders in production."
"Yes. We absolutely need this."
"Ok..."
A short time later
"Why does it ask me to confirm? Just make it do it."
"Sure..."
A week later, after restoring from backup
"Remove the bulk delete function. I don't know why we even have that!"
Really demanding managers refuse to explain their XY problems... This one never did learn.
The out sourced developers however...very much yes I can.
Half the things do the wrong thing wrong, the other half is the wrong thing sorta working.
There was clearly no attempt to understand what the user wanted or any attempt to ask the simple questions like "Why do you want X, is X related to Y, would it be handy to pull in related Y for display X" beyond the terrible code quality (and database architecture, I wish I was kidding when I say it took 49 to 69s to search for a quote (I timed it on repeated runs), it now takes ~400-600ms and I still think that's too slow (and I search more things) there is just a complete lack of any thought/effort or consistency.
Even the tables aren't consistent across the system - sometimes click a row opens the related entity (with no indication that's what it does), sometimes there is a "view" button in the row on the right, sometimes on the left.
It's just pile after pile of UX disasters/architecture code disasters, no wonder the original lead dev came close to a nervous breakdown, I just don't think he was capable of dealing with a system of this complexity.
Asking those questions is being obstructionist. Most end users don't understand the ramifications of what they are requesting. Explaining it all is an effort to bring them up to a level of education that would allow them to do your job. They pay _you_ to do your job and now you are just wasting everybody's time. Why do you have to make everything so complicated!? Why can't you just do what your told? Just add the button and stop asking questions!
Asking "why X, why Y, why Z" can come off as challenging their knowledge, and questions like "would you also need W?" tend to get answered "yes, sounds good" so now you've just made more work for yourself.
100% this - "Have you considered that our long lead times on inventory means we increase our holding costs?" is a good lead-in to exploring how to reduce that.
> "Have you considered that our long lead times on inventory means we increase our holding costs?"
What's frustrating about this is now we also have to understand the business overall, and that's kind of the problem in the first place: nobody has the patience to explain it.
So in addition to coming up to speed on whatever tech stack they have, we're going to have to find someone who understands and is capable of explaining the (sometimes completely foreign to us) business side of things and come up to speed on that too. That's a lot of ramp up time, especially when nobody wants to hand out raises and you're better off finding a new gig roughly every other year anyway.
I'm currently working somewhere with people that are great at explaining the business, and are willing to discuss at length the intricacies of how anything works at any time. The tech stack is abysmal, but being able to easily understand the business makes it worth dealing with the dumpster fire of a LoB app. I'd take it over the previous job, where we had greenfield project, bleeding edge tech, and money, but nobody could tell me how the hell the business worked...
That gave me enough of a grasp of the principles and more importantly the nomenclature that I could then talk to people in their language not mine.
To me it's a normalised series of tables to them it's WIP inventory.
One of the things DDD got right (if you remove the buzzword bingo/hype) was the idea of a 'common language'.
Unfortunately in my experience (couple of decades) most business people don't want a common language, they want you to understand theirs.
It is surprising how little theoretical knowledge people who work in a field use on a day to day basis.
> Unfortunately in my experience (couple of decades) most business people don't want a common language, they want you to understand theirs.
The “common language” of DDD was the language of the business domain, so that’s in line with DDD.
The practical problem is that the language of many business domains is often highly context dependent, making it unsuitable for direct use where ambiguity must be avoided even without context, and trying to namespace things to map to the specific relevant business contexts is often impractical.
I've found it's easier to understand their domain and map it back to mine than it is to try to build a shared domain.
Also I find business stuff interesting, it's just a nice change of pace from fighting with code.
But there isn't a "delete all" button, presumably because people would use it and complain that they wiped out all their email.
The end result, however, is the iphone email is completely unusable for me.
In the end, the correct process is probably have two people activate the alert, so that two people have to independently not read the dialog boxes or whatever to send a false alarm. But maybe that doesn't work either, I haven't done any research to that effect and don't really know.
On some level, I like the interface. There is a list of possible alerts, and you click the one you want to send to send it. It's just that it doesn't account for the possibility that the user doesn't ACTUALLY want to send the one they clicked. The same problem exists with any powerful tool. Hammers don't check that you're hammering a nail and not your thumb. Cars don't ask "there appears to be a pedestrian, are you sure you meant 'accelerate' and not 'brake'?" With great power comes great responsibility.
> a different interface wouldn't necessarily stop someone who's confused from sending the wrong alert.
Ultimately, however, the individual, his chain-of-command and the system designers have to be held accountable. The scary thing is that many people saw this and said nothing, almost certainly some people heard complaints about this and did nothing, somebody even signed off on this. It demonstrates an organizational problem, I think.
A simple fix would be to use a tried and true method that's been effective for decades. Have different popups that read
Type "REAL WORLD" to send this alert.
and
Type "DRILL" to send this alert.
Trust me, if you get in your users way they will find some way to get rid of you.
So, yes, bring up a huge flashing red warning dialog with a single confirmation step. And make it easy to issue a retraction.
Same thing with your hammer analogy. Everything shouldn’t look like a nail then! A real alert should look like a nail. A real ballistic missile alert should look like a railroad spike (aka really big nail). Test alerts should look like a screw. Etc.
1. Separate items intended to be tests from items intended to be live warnings. Draw a green (or yellow) box around the test items and a red box around the live items.
2. Require a confirmation before sending out a live item, and not just clicking a button. Put up a big red flashing warning that says, "You are about to send out a live warning, are you absolutely sure you want to do this?" and require the operator to type "YES".
> With great power comes great responsibility.
Yes, and designers here have a lot of power and responsibility to design an interface that is difficult to use in the wrong way, and doesn't treat options with wildly different real-world consequences as equivalent.
How many times to I test the SMS delivery system? Not very often, so I am going to be more careful with any popups. Maybe you only use your computer once a month?
The "normal" for enterprise and especially government software is dogshit though.
It's because the people doing the procurement are not the people actually using the thing day to day. They treat UX and design as extravagances in the face of spec-sheets and slick marketing decks.
Consumer software is chosen by people that actually use the software. They can see that it is shit, give it bad reviews etc.
I used to work at a very large company who use Teamcity (think git for CAD), which was the worst POS I have ever used. A 90s Java mess that was so slow you could watch it redrawing GUI controls in slow motion. Everybody that used it hated it. At least some of the higher ups liked it, but they didn't actually have to use it.
The issue with these tools is the company that is too shit to run them. Put the smallest box they could salvage that's already running a hundred apps. Put the storage on a NAS in another datacenter because there was no more local disk space.
I wish we could have a sane conversation about how UI's should be customizeable for the end user
Depends a lot on context and the type of application, but a lot of end users get confused about where the line is between UI/UX and backend functionality.
A lot of things that might seem to be UI issues might actually have implications for things like resource consumption and application stability. It's a tough balance to strike.
Such misteackes in the cockpit of an airliner are deadly, which is why a great deal of effort is expended to prevent such mistakes. Unfortunately,
1. bad UI design is usually only obvious in hindsight
2. doing good UI design is expensive, and not always worth the effort
Of course, I face the same sorts of issues in designing a programming language (D), so this topic is of continuing interest for me.
That's only true if you have little or no experience designing or even using interfaces. As someone who has been bitten by bad UI design in the past, I've noticed and called out a decent amount of bad design well before it actually has caused a problem.
I'm afraid the history of cockpit design in airplanes decisively shows otherwise.
Based on the photos of the screen shown in the article, this one's dead obvious.
That requires a paper form. The payroll system in the state has failed to be upgraded for some 20 years or so of promises. Staff are paid via checks which are sent direct to their banks because they can't even pay over the wire.
Here's a good article about it: http://khon2.com/2015/05/11/costly-consequences-of-outdated-...
These 48 minutes may well have changed a whole bunch of people's lives for the better, in the long term.
I guess you can think of it like waterboarding. Waterboarding doesn't harm anyone, it forces one to contemplate mortality, but it is also something so terrible that one would not wish on anybody.
Or imagine someone who, convinced of an impending death, donates all of their saved wealth to charities online.
I can hear a forward thinking developer saying "hey should we at least have colored buttons or something on this screen so it's easy to see what is a test and what is not?" and the product owner/business owner/PM saying "no man just add a link it's faster."
"Everyone is going to die. Run but it won't help"... Is that want you wanted to send [Yes] [No]
I say this as someone who watches people log in on PCs and click past a useless (for them) Citrix dialog that includes a "stop asking" checkbox. Citrix added that checkbox some time ago, so these folks have been vacuously ignoring the entire thing at least once per business day for at least a year.
Perhaps a captcha style prompt could be added (basic math with random values?) to critical/damaging operations but I'm sure that would get pushback of its own.
"You can't require that our people do basic arithmetic when they need to send an alert! It'll slow them down!" Suggested response: "Are you telling me that you're allowing this kind of operation to be done by people who can't handle single digit arithmetic?"
They could consider a different UI response between a drill and active alert. Since drills are the majority of their workload they'd get dialog blindness to the drill confirmation, and then you'd design the active alert confirmation to be a-typical of the drill (for example a different color dialog, and have an "I agree" checkbox on the active, but none of the drill).
Just adding a checkbox and later a popup with an additional warning wasn't enough.
An undo function is obviously best, but ufortunately while technically possible, it took a while - possibly a day - to restore due to ripple effects in other systems, and it normally wasn't the person clicking the button that had any reason to notice something was wrong.
Unfortunately a lot of organizations don't want to invest the time/resources into creating it. Particularly when it gets into discussing exactly how the underlying data should be handled during the undo window (e.g. does it exist? Is it just flagged deleted? What about relations? Do all of our queries that touch this data check that? Etc).
That would apply to something that's used routinely, I'm not sure this system is actually used that often. Do these emergency systems send out "this is a drill" messages really that regularly? As a non-US person that sounds like a quite scary way to live.
Even if it is something that gets used regularly, adding additional levels of confirmation, depending on the kind of alert that's gonna be sent out, would already go a long way of preventing this kind of mistake.
For the real deal add some bold and flashing text along the lines of "This is the NOT A DRILL message, are you sure about sending this?" which pops up as a second confirmation screen, while drill messages have only one confirmation screen.
Per the explanation provided by the agency, this is a drill that is conducted at every shift change, so presumably multiple times a day. I gather it does not send any actual alert to the public, just simulates it (perhaps sends to a small pool of test devices?) But it's appearing more and more likely that we've been giving a misleading explanation for this incident so who knows.
Nah, real world experience shows that people who supposedly have common sense will happily put their payment info just about anywhere.
The Test Records probably do the same thing just to a smaller list than the real one.
So there is no real way to separate them.
Accessibility becomes an issue for colourblind people then.
For instance, here's some icons from NATO, which used to be MIL-STD-2525. You'll notice that all the icons differentiate in both color and form. The NTDS standards for Naval systems are similar.
https://en.wikipedia.org/wiki/NATO_Joint_Military_Symbology#...
To me, the screenshot looks more like a list of user-defined presets than something that went through the original software development process. Maybe something along the lines of only superuser can define new presets, but lower users can activate them. That way, at least random "I love you honeybunny" pranks would be avoided, but the risk of skipping a real warning because of insufficient permissions would be avoided.
A physical UI would have an openly accessible switch for "drill" and "not a drill" protected behind a seal that needs to be broken, this is difficult to replicate in software.
[0] Which, to be fair to users, is a disease introduced by putting too many switches under covers which shouldn't be.
Good stuff but I think they could probably have gone with something else for "Neutral" - the distinction between a 16:10 rectangle and a square could easily be missed in a hurry, especially at small sizes.
I'm not sure "someone using this system might see everything as the same shade of grey" is a realistic concern at those levels of incidence.
"safety-critical systems with a large user base"
Surely a missile warning system would be operated by a very, very small number of people, on the order of twenty or thirty?
For someone sending alerts, color vision is not — things like keeping cool under pressure, following procedure, interpreting chaotic information, etc. are.
One problem: William's in the toilet. He had a bad taco for lunch and honestly, he's going to be in there for a good 10 minutes. And there's a missile coming. Luckily Frank the IT guy is there and knows what to do but ... he's colourblind!
Oh dear. He's just sent out a dummy warning by mistake and now half of Hawaii is going to die. Well done.
Something I brought up at my IT Support job yesterday regarding the crazy idea I had to actually document some processes and rules we have. Flow charts and tables and such. Having a reference you can use at any time is much more efficient than expecting everyone to remember literally thousands of facts they're told once in two weeks of training.
When I've been given PSDs in the past, either for review or for implementation, there's never been any documentation with any of the reasoning behind any of it. And when I've asked follow-up questions about why something was done the way it was, I've typically been met with either defensiveness or "that's how it is, now go and build it"
There had to have been quite the cavalcade of idiots behind the making of this system.
People blindly click through confirmation screens all the time.
Someone reviewed the spec for this. Someone modified the page of links. Someone reviewed that modification. Someone signed off on the change.
Actually, with government contracts, you are legally obligated to perform only the task assigned. Providing work to the government without the government paying for it is illegal. And you are only being paid for what's in the contract. (This is actually overall a good thing. Otherwise, large companies with better margins could easily provide free value-adds to government customers to win contracts away from small shops with small margins.)
Now, in this case, yes maybe the contractual item could have been interpreted in a way that allowed a proper page redesign. However, I would never state that as a fact without having the requirements and also receiving agreement from the government customer over such changes.
The Anti-Deficiency Act only prohibits "voluntary" services, not "gratuitous" services. Prior to the passage of the law, it was not unusual for cash-strapped gov't agencies to accept "voluntary" services (i.e., no formal obligation to pay for them) but then pay for them later after being allocated more funds. Congress didn't like this so it outlawed the practice. However, if someone wants to donate services to the gov't and executes a written agreement to not accept payment, then it is legal for the government to accept the free services. See, e.g., https://www.gao.gov/assets/450/441639.pdf
This is clearly a case where all the downsides of bureaucracy were in full effect (someone might be afraid to touch something) but not the benefits (lots of security checks and balances such as in air traffic control).
When "trying to do it right" means you have to go through layers and layers of bureaucracy and probably ruffle a few feathers in the process, over and over again, I can see how some people quick learn to "just do their job".
This is human behavior. We can talk as much as we want about what would be the ideal solution here, and how we would never do it, but problems like this don't happen in a vacuum and are rarely one person's fault. It's a whole system that leads to this.
But what I was trying to say was that by either refusing to do it outright, o doing it right (without “asking for permission”). That is - I’d rather be jailed or fired than doing this. And I hope that goes for most devs.
My superior would just have to solve the problem of getting the spec change cleared or find another developer. If that was somehow even seen as a problem by the superior - same thing - they’d have to find another developer.
I've seen lots of organizations try to save a buck by extending a previously existing system with in-house labor after the original contractor asked for more money to do the change. I would bet that the original contractor (if they're still involved with the project) hasn’t seen that screen because it's some homebrew patch put in by whichever administrator babysits the machines for the state government.
The problem with organizations maintaining their own rogue patches is that, if those organizations had people compentent enough to make changes well, they wouldn't have hired a contractor or bought off the shelf in the first place.
But only to a point. People resist perceived change. You can improve the back-end all you want, as long as you don't make unexpected changes to the front-end. This includes something as simple as a clarifying pop-up, or a speed increase of a procedure.
... as long as you do not mind being fired.
Doing things that are immoral/dangerous/stupid because you need to eat is not an excuse.
<H2> Testing </H2>
...
<H2> FOR REAL </H2>
...
Then adding one new link with any reasonable categorization might mean changing the label on a separate link to make it more distinct, and no one wants to go there anymore.
I'd be very surprised if the ultimate cost of this mistake isn't far higher than the added cost of adding an "Are you really sure?" confirmation option.
This is why you don't let accountants make cost decisions in a vacuum. Of course if you're counting beans, the cheapest option is best.
In reality-based accounting, the hidden costs, consequential costs, potential damages, and costs of failure guarantee that cheapest is risky if you're lucky, and suicidally expensive if you're not.
The GAP are not designed to analyse those costs, so stupid decisions are made, avoidable consequences occur, and ultimately money is wasted, not saved.
We're seeing the same thing in the UK now where a huge government services contractor has gone bust.
In the UK it's policy to give government contracts to the lowest bidder. This makes perfect sense, if you're clueless and have no idea what you're doing.
In other countries it's policy to offer contracts to the second or third cheapest bidder, because this encourages bidders to to put in estimates that mean they're more likely to finish the job without cutting corners, more likely to include realistic margins to keep their business afloat, and more likely to estimate unexpected costs realistically.
The UK's policy has completely failed to save money. It's going to cost hundreds of millions of pounds in direct costs, and probably more than a billion in consequential losses around the rest of the economy, to deal with the fallout from a wholly avoidable corporate drama.
It's a catch-22 for developers in this position: you have to be able to justify every single major improvement from a position of cost-benefit to the business, but to do that adequately well enough to convince a client to spend the money requires up-front time and money expenditure that is hard to justify until after it's done.
[1]: https://medium.com/tragic-design/how-bad-ux-killed-jenny-ef9...
I have worked in shops that intentionally deliver bad software, and those that had higher ethical standards, and the only difference on the business side was that the bad software had higher budgets and more permanent employees (both more-permanent employees and more permanent-employees).
The problem is that all the people who can tell the difference between good and bad are employed by the contractors. The direct government employees are still counting SLoC and basing their UI requirements on the Excel spreadsheets that were directly copied from paper forms from the 1970s. I am not making this up.
The contract awards are still mostly based on who you know, rather than the quality of your past work, so given the choice between a slipshod initial implementation with a juicy back end in the form of continual maintenance and doing it right the first time and delivering something that never needs contractor support ever again, it isn't surprising that a lot of companies opt for the former even when most of their employees would prefer the latter.
What some designers don't realize is that, in reality, they are also in sales. If they can't effectively pitch their ideas to non-designer audiences, it doesn't matter how good their design is; it won't be used.
It's not a coincidence that Paul Rand would include a hefty proposal book along with his logos.
Don't know what the equivalent in the graphics design world would be.
"Hygiene" is a great word overall, for both cases.
I’ve written a few versions of this article over the years. I keep hoping I’ll see the day that it’s no longer prescient: “Why the DMV Website Sucks” https://hackernoon.com/why-the-dmv-website-sucks-2f27a367baa...
Facebook has a dozen of fake drill buttons, and one real drill button, but you can't tell which is which.
Apple has a launch button but it doesn't work because the missiles are of a different brand.
Google's drill button turns out to be an ad.
A better idea might be an "Oops, belay that!" next to it so it can be cancelled just as quickly.
I have seen a large number of government web sites, and most of them, especially at the state level (I am talking about US states), have a horrible UX.
The problem is not knowing (or having someone who knows) how to design something better, it's treating good design as a priority. It rarely happens.