Forums
User experience, and its related topic of user interface design, are important. How important? Well the US government’s General Service Administration (GSA) took the time to build a website to explain what it is. What other proof do we need? Well not only did the GSA build a website, but they invested in the SEO necessary to make it top of Google organic search, right below the featured snippet from interaction-design.org.
Which is why the saga and ongoing story of Citibank’s debt repayment blunder all the more amazing. Here’s a quick recap:
- Revlon, which owed nearly $900 million to creditors from a 2016 debt facility, was working with Citibank to refinance their current obligations into a new loan
- Citibank, who managed loan payments, intended to send out $7.8 million of interest payments to creditors using a system called Flexcube
- Citibank intended to roll over the remaining loan principal into an internal “wash account” to avoid sending the entire amount owed to creditors
- Instead, the offshore Citibank contractor responsible for this massive responsibility, misread the Flexcube UI and sent $900 million to all of Revlon’s creditors
- Citibank begged for the cash back, and received $400 million back
- A judge ruled that the remaining creditors can keep the cash. Citibank is miffed.
- If you want more details written in only the way that Matt Levine at Bloomberg can, check out his piece from February.
A screenshot of the UI:
That shudder you feel? It’s the fear you have from seeing a facsimile of this UI in your office.
It’s hard to feel sad for banks because of the whole 2009 recession thing, but it is interesting that a) Citibank utilized such a confusing UI for something as important as loan payment distribution, b) utilized an OFFSHORE CONTRACTOR to handle such an important piece of work, and c) did not have the proper controls in place to manage such a massive screw up. (I think there’s also some lesson about our country’s overreliance on freelance or contractor work, but that’s probably for another time.) Perhaps when preparing for the Federal Reserve stress tests, they could add in internal process stress tests as well.
This story reminds me of the 38 minutes of terror that residents of Hawaii lived in when they received a push notification that ballistic missiles were on their way, but was instead caused by a push of the wrong button on the Emergency Alert System.
Or the software bug that is causing hundreds of inmates at Arizona prisons convicted of nonviolent offenses who should be released early for completing voluntary classes from getting their due release. The nearly $24 million contract spent on developing the software for managing the prison populations had a known bug that no one seemed to have the budget to fix, even with repeated warnings of a possible issue. With nearly 14k bugs logged and $1,137/hour developer time, I hesitate to be in the backlog prioritization meetings.
These software disasters boil down to 4 software development issues:
- Turning every requirement from a user into a feature. Not every pain point a user faces must be dealt with immediately in a release. Think through the problem the user is actually facing and brainstorm creative solutions to it.
- Adding features at the expense of UX: Bloated applications chock full of features can lead to a terrifying UX. Focus on adding features that fit into the overall product vision. This, of course, depends on there being a vision beyond “do everything we need.”
- Not enough (or no?) investment in user research and testing. Testing an application against a diverse set of users (non-judgmentally of course) is a great way to identify potential problems. Issues that may arise could be used to develop future features or to build a process to avoid potential disasters.
- Partnering devs with designers and strategists with UI experience. Every sprint should be a partnership between dev and design/strategy. The battle between those who are eager to build and those who own the vision is key to building a product that is based in reality and works for the end user.
Each of these requires an organization which cares about these issues. Sadly, there’s no shortcut for teaching them that, but as the disasters we discussed show, they should care.
Oh, and I know I said I would discuss freelance or contractor work in a future blog post, but definitely don’t solely rely on workers who are not employees of your company, and may not have your company’s best interests in mind, to handle such sensitive tasks without oversight.
In slightly related UI news, try not to use tools that are inserted into the body to reach for that Snickers bar. Or maybe this is just another case of an end user bypassing obstacles in the UI with the tools at their disposal?