Hacker News Reader

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.