There are limits to this.

A ten pound sledge hammer can be used to drive finishing nails in fine furniture but it would be absurd to claim that all the dented furniture coming out of your shop is a result of poorly trained workers rather than inadequate tooling.

A generic hammer, like this UI (at least, as much as is apparent from the screenshots in the article) can drive basically any nail. But specialized hammers exist for good reasons. This is equally applicable in software tools.

A good tool should enable you to do things you couldn't do without it but the best tools make it easier to do what you want and harder to do what you don't want.

I would ordinarily agree, but to be honest the UI in the screenshot doesn't really look all that terrible. Not saying it couldn't improve to clarify effects, incorporate documentation and nudge the user away from making mistakes - but overall I agree with the grandparent post. Clearly the operator is supposed to have business knowledge of what those GL fields mean. I'd bet there are more experienced operators who would be frustrated and less productive if they were forced to use a dumbed-down UI where you couldn't just put the amounts you want in the fields they should go.

My decade-old Quickbooks software similarly lets me create GL entries and assign amounts to the accounts involved. If I let my $12/hr intern who doesn't know what they're doing use that feature and they post to the wrong accounts, then of course bad things will happen. Instead, he uses other more specialized interfaces (like you suggested) to enter things like invoices, bills, etc. We give children safety scissors, and expect adults to be able to handle the real thing.

I really do have sympathy for the employees involved, and strongly agree with your sentiments that software should be engineered for safety. But I encourage anyone else reading this and forming an opinion to click into the article and have a glance at the screenshot.

That's an excellent point.

The form looks like it can accomplish all sorts of things and business logic, just like a SQL query can accomplish all sorts of things and business logic in a database.

There's nothing inherently wrong with that. But like you say, the issue is with training.

The fact that 3 people who were presumably trained in how to use this tool, used it wrong, means it's absolutely a failure of training.

Business logic very often isn't "intuitive", because tools are used in all sorts of ways. When it comes to business logic, what's often most important is documented procedures and checklists.

The real question is, since this was a procedure that had been performed regularly and correctly in the past, why did it fail this particular time? Why were these 3 employees left to assume they were using the tool correctly, rather than referring to a definitive documented procedure that would give them the answer for sure?

Oftentimes it's an employee turnover/transfer/vacation issue that exposes the lack of documentation, and the real issue is too much knowledge in employee's heads that isn't committed to paper in the right places -- pure sloppiness of business procedures.

There were documented procedures:

> The Fund Sighting Manual explains that, in order to suppress payment of a principal amount, “ALL of the below field[s] must be set to the wash account: FRONT[;] FUND[; and] PRINCIPAL”

and checklists:

> Raj then emailed Fratta, seeking final approval under the six-eye review process, explaining “NOTE: Principal set to Wash and Interest Notice released to Investors.”

and confirmations:

> which prompted a warning on his computer screen — referred to as a “stop sign” — stating: “Account used is Wire Account and Funds will be sent out of the bank. Do you want to continue?” But “The ‘stop sign’ did not indicate the amount that would be ‘sent out of the bank,’

To answer your question "Why were these 3 employees left to assume they were using the tool correctly, rather than referring to a definitive documented procedure that would give them the answer for sure?" My guess is that the manual is a million pages long and incredibly confusing.

My takeaway from this is that you can't train and document your way out of a core human factors issue. Your point about SQL queries is apt; that's why you don't just give humans access to prod.

That's a good point, besides not following the documentation (or they weren't aware they were supposed to "suppress payment of principal amount). They UI "stop sign" prompt should show the # of on the confirmation machine. It should accurately summarize everything they are doing, not just a simple "yes/no" they've seen a bunch of times.

Just like in Hawaii when they sent the wrong cell phone warning of an incoming NK missile attack, it could easily have been prevented if there was a dialog which said "You're sending this 'prompt' as a live alert to millions of cellphones (yes/no)".

Software always assumes people are paying attention but for serious usecases like this (which can't be undone for example, or sending hundreds of millions) there should be a sanity check dialog with real information.

Hierarchy of controls! Training is supposed to reinforce technical measures not replace. Have you never screwed up something you've done hundreds of times perfectly before?

I think that your comment mostly proves the opposite point. I wouldn’t say that it’s only a ui/ux issue. However, I’d say that ui/ux is the best solution in this case (and most other cases)

The fact that three people independently verified the UI (all highly experienced with this exact GUI) before issuing the transaction betrays the notion this was a lack of training.

Training cannot substitute for Engineering controls aka physical safety features that make it impossible to explode the entire lab or send 1 billion dollars by mistake.

This is no more user error than Boeing’s recent sensor disaster. Sure if the pilots had the proper training none of that would have happened, and Boeing didn’t make sure they had it. But it wasn’t a training failure that was the issue with with the Max 8. Training was only a second order cause.

What does training here mean -- because if it means a lad sitting down and explaining what the checkbox does then it's certainly the UI to blame.

Looking at the evidence, I would say this is a pure UX/UI issue at root: three people got confused about what they needed to do, and they all thought they completed their task successfully when they didn't.

The first UI issue is the obvious lack of intuitiveness. There is ancient software that is resonably intuitive to use, because the people who led development took responsibility to do the right thing: invest in UX/UI so that their software is a success. Others however cut corners to get more short-term profits, or dismiss design as if it was decoration (it's not, good design is form + function and most serious designers pay more attention to the latter than the former).

The second UI issue is (an assumed) lack of feedback in the output of the transaction. After doing the transaction, if there was a feedback screen confirming to the user what they've done, the error could be caught much more easily. For example, before actually sending any transaction there could be a screen saying: - Summary of transaction - X$ will be sent to account XYZ - X$ will be sent to account ABC

This looks like obvious stuff, but is often obvious stuff and small details what turn a problematic user experience into a succesful one.

I am the original poster you're responding to. On the high level I agree with what good looks like - I'd strive to have all of these things in a system if I were the designer.

I am also recognizing that both you and I may not understand the complexity. Saying "X is being sent to ABC" may be a gross-oversimplification of the transaction and could obscure lots of badness. It's possible that the level of complexity of the screen IS what's needed to express it.

Analogy:

Would you expect to walk into the cockpit of an airliner and see a big dumb screen that tells the pilot "you are landing the plane?" or would you accept that it's a complicated serious of operations which the pilot understands by putting together the various bits of info on various instruments. Hope the parallel is clear.

Again, by no means am I insisting this is a great application (I don't know anything about it) but that you can only simplify the display of very complex state so much.

> The first UI issue is the obvious lack of intuitiveness.

You can't judge intuitiveness without knowledge of the intended userbase and usage pattern. A sovereign app for specialists in a process can be intuitive with a design which would be radically unintuitive for an occasional-use app for people only tangentially aware of the same process.

> Looking at the evidence, I would say this is a pure UX/UI issue at root: three people got confused about what they needed to do, and they all thought they completed their task successfully when they didn't.

It's definitely a UI/UX alignment issue, where the understanding/knowledge of t(at least some of) the current users is not aligned with the assumptions of the UI.

But without knowing a lot more, it's hard to tell if the real problem is UI/UX design or processes and procedures for maintaining, assessing, and addressing (whether through system changes or otherwise) the current understanding and evolving needs of the current staff.

We aren't at the point where it is legitimate to expect software adapt automatically to changes in the userbase.

> three people got confused about what they needed to do, and they all thought they completed their task successfully when they didn't.

> For example, before actually sending any transaction there could be a screen saying: - Summary of transaction - X$ will be sent to account XYZ - X$ will be sent to account ABC

These sums up what I think too. I get that internal software is more complex, and bank transaction are also complex, but when three people checked it, though it was good to go and didn't realize a mistake until the next day, that's a problem.

Showing a summary of how much is being sent to where, and how much is going to stay in the account is the minimum I would expect for a finance software that's used to transfer millions of dollars in a single action.

Did 3 people really check it though? I've worked with many groups where the one guy takes the lead and the other 2 are like "sure, whatever."

Yeah, I'm familiar with that. My old boss used to say that a dog that has 2 owners die of hunger. When we started having 2 reviewers for PRs, he was adamant that there will be ONE that would be the person actually responsible for it. So the main reviewer always had the same responsibility as if they were the sole reviewer.

To be sure, this is an ugly UI but this is not necessarily a pure UI issue at root.

of course it is...

> Honestly with names like "front" and "wash" the whole thing should be checked by tax officials. The words probably mean something else, but ... wow

It's funny how worked up and self righteous one could get even while recognizing that they don't actually understand the concept. It's particularly amusing that you were alarmed by "front" (what, like a mafia front?) when there's also a "back".

I have never worked at Citi but I can make reasonable guesses as to what these accounts are.

Wash is a term that means "funds did not leave the firm" (you may have heard the expression "it's a wash" to mean "things net out to 0."

Front and back may have to do with direction of funds flow, or perhaps a hierarchy of accounts (like "we are pulling from account X on the back-end and into account Y on the front-end")

Not saying these are exactly right, point is that as someone who's been in finance for a long time these are totally innocent.

It's something about the way your original was worded. I think if you had written only the first sentence, the joke would have been clearer.

A wash account is a normal financial term. Just like front- and backoffice. Also, nostro, loro, vostro, clearing accounts.