This really is an awesome example of a bad UI. These are exactly the kind of UIs you see in the enterprise all the time, with the article containing the totally crazy description of what was expected plus the screenshots to show that there was absolutely no way to get this, if not being the programmer who wrote it (and even then, no guarantee at all to get it right). To have a somewhat exact approach of detecting and fixing issues like this, that is what usability is all about.
So it's really the design of the software and not just the style of it that was wrong and had to be improved. A usability professional would have caught that immediately - and would have been way cheaper.
I somehow get the feeling that this wasn't so much designed as evolved. There probably was (maybe still is) some kludgy program on a mainframe somewhere, written in Fortran or Cobol, and they just slapped a web interface inbetween.
Slight nitpick anecdata: one of the best utility program I ever had the pleasure to use was an AS400 terminal based program for national tax office. I don't want to oversell but it was the nicest software tool I ever used in a job period.
Those old things were so lean, so fast, so cheap, zero fancy feature, zero presentation, zero confusion. And the software used every cycle to either make you go on, or then check or even prepare fixes (think live typecheck suggestion in your IDE but for accounting input operators).
I was brutally shocked by the contrast between everything I've been fed and seen in college (that said these were the j2ee 4 days .. so peak sadness). Of course by the time I left there was some grand plan to replace it with modern html/css/js evil reincarnation that was slower, and less useful.. basically going back from your old makita impact driver to the shiny new bluetooth connected released yesterday that will fail and require the v2 before being barely useful.
tl;dr: glory to old terminal application made with skills.
That's true in general, but not in this case. The UI shown in the screenshot violates every single usability principle for dialogues as defined in DIN ISO 9241-110 - and that's just one part of the screen! I'm 100% you put that in front on a random usability professional and he will immediately see that the UI is wrong.
Explain on top of that the scheme for the interest payments and he will notice that the UI does not fit to that purpose at all. Why would paying interests involve a wash account and a real money transfer at all? If that's the job to do the UI has to facilitate it directly, not with crazy schemes. That's Aufgabenangemessenheit (to be fit for the purpose, not sure about the official translation) and it's the highest dialogue principle. That got completely ignored here. This was never usability tested, I'm certain - or if it was the results were ignored.
Sorry, I think my post above was confusing. Please let me clarify:
There seems to be a huge number of fields-of-expertise that potentially have bearing on my life or work. E.g., urologists, transmission repair techs, indoor air quality experts, sleep therapists, house painters, early childhood education consultants, therapists/counselors, sports trainers, physical therapists, housecleaners, etc.
In my experience, most of those fields have practitioners who are sure they could help you avoid future problems; you just have to hire them to see the benefit! Or at the very least, invest time in helping them understand your particular situation so they can give more detailed advice.
I could easily believe that most of them are correct, too. But each of us, even in a business setting, has limited funds and time/bandwidth to deal with such specialists.
In my post above, I was trying to say that knowing which of these many specialists one should have engaged with isn't always clear ahead of time. E.g., maybe I didn't need to bring my car to a transmission repair shop, when the only real problem I'd have in the near year is back pain from poor sitting posture.
What you say is true, but a little bit off base I think. A team designed and developed this software. So this isn't shopping around for specialists, this is basic engineering practice to do risk analysis (by whatever name you call it). Two possibilities 1) there was no such process, or 2) the process didn't evaluate UI and workflows well.
In the first case, the teams basic competence is definitely in question. In the second, hopefully this sort of thing causes an improvement in the approach. Point being, this isn't really one of the vast number of possible things that could be looked at, rather it is a fundamental part of the bread-and-butter work of the team that shipped this product.
That being said, a lot of E2E front end stuff is done really poorly because of the way that these systems are sold and serviced. Sometimes they end up in bucket 1 (team unable or not allowed to do a competent job) by design.
I made a different assumption about what happened here. The tool as developed fit requirements very well. Over time, the tool started to be used for things that were progressively further and further away from its intended design; I imagine that sending to a wash account was (for example) some employee’s clever idea of how to make use of what they already had when their overbearing boss told them to “just make it work.” Then, having been shown to “work”, the process became reified.
Fair point, but part of risk analysis is looking at what can happen when a tool is not used as designed. Obviously you can't cover all eventualities, but one thing you should do is focus on the worst possible outcomes and work them backwards.
Ah, indeed I did not get that that's the point you wanted to make :) Reading it again I really jumped to a misinterpretation there. Sorry.
You are right, it's not as obvious that this is a half a billion dollar issue that usability work would have avoided as it is obvious that the UI is flawed. I jumped to "A usability professional would have noted that it's the wrong approach" and from there simplified to "see how flawed it is".
> These are exactly the kind of UIs you see in the enterprise all the time
It really is the norm. I've worked a handful of different jobs over the years and always got an extensive onboarding guide because the section for the software is just so bloated. Software with good UI could've easily reduced the guide size by 3/4.
I think that it is a mistake to call this a UI issue. Its not like a mistake was made because text was difficult to read, or because to check boxes were too close together and the wrong one was checked. Those would be UI issues.
This was an issue of an operations team that just did not know how their system worked. Perhaps the system design could have been better. Most likely it could have been, but if Citi had a team of people using a system responsible for billions of dollars without the competence to use it correctly, that failing goes way beyond the UI.
I have to half agree with you, but in essence disagree. You are absolutely right in that this is not a UI issue where a checkbox was too small. But it was an usability issue that was caused by an inadequate UI. Plus an inadequate process, but that also manifested in the UI. UI issues can cover a lot :)
The user thought that setting the target account in one line would be enough to have the money be sent there instead of where it ended up being sent to. There the UI was misleading, that's a violation of the self describality a dialogue has to fulfill (I'll freely translate the principles, I would have to look up the official english translation); in that the UI has to communicate by itself in which state it is, what every button does, every icon means, what even is clickable etc.
Then the system did not clearly communicate what would happen. That's not only an issue of describing itself, it's also an issue of fault tolerance. The system did not prevent the user from a mistake he was about to make. This could have happened by clearly describing what would happen at the end of the process and offering an undo operation. They tried to implement this outside of the UI by requiring 2 additional set of eyes, clearly that was not a sufficient solution.
But most importantly, the process the UI was offering was the wrong one for the job. This was about sending parts of a debt to creditors. Instead of offering a clear way to do that, they had a convoluted process that involved a wash account plus a real money transfer to that account (how crazy is that!) instead of supporting exactly the work that was to be done. That violates the primary dialogue principle: Be the right tool for the job (Aufgabenangemessenheit). Admittedly, I miss context to know for sure what would be the right tool for the job and why they ended with this solution, maybe it's a bit less crazy than it sounds.
Yes, all of that together goes far above simple UI issues, but it's nonetheless an issue of the UI. It's just also a complete usability fail. It's really the job of usability professionals to analyze software and scenarios like this and to provide better solutions. That was and partly still is my job :)
The headline ideally should have called it an usability issue. That would have covered the UI part and included the other aspects.
I would think that even programmers don't know how this works.
They likely just got document that when you receive message with these fields filled this should happen. And then other team of programmers had implement UI with these fields and then make it send message here.
Scenario from article would be solved by UI if the requirement would be "SEND MONEY [YES/NO]; AMOUNT [XXXX]; APPROVALS [JANE/JACK/JILL]" but that is not what that window is doing and at that level there is no "SIMPLY SEND $7.8M; MAKE IT NOW [YES/NO];". I don't even know what it takes to move $7.8M to different accounts but I expect it is quite involved process that has to trigger multiple different things.
So it's really the design of the software and not just the style of it that was wrong and had to be improved. A usability professional would have caught that immediately - and would have been way cheaper.