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.
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.