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