012 min
How a user interface cost Citibank almost $900 million
On 11 August 2020, a payments team at Citibank set out to send about $7.8 million in interest to the lenders on a loan taken out by Revlon, the cosmetics company. Instead, the bank also wired almost $900 million of its own money to the same lenders. Nobody typed a wrong number. The money went out because of how one screen worked.
The bank ran the loan in software called Flexcube. The only way to make this payment in Flexcube was to enter it as if the whole loan were being paid off. The principal, the large sum, then had to be pointed at an internal "wash account" so that it stayed inside the bank. To do that, the person entering the payment had to tick three boxes on one menu, labelled FRONT, FUND and PRINCIPAL, and type the wash account number next to each. That rule was written in a manual. The screen did not show it.
Citibank's process used three roles: a maker who entered the payment, a checker who reviewed it and an approver who gave the final yes. The person entering the payment ticked only the PRINCIPAL box and left FRONT and FUND unticked. The checker and the approver both believed one box was enough. Nothing on the screen told any of them that two settings still sent the principal to the lenders.
Then a warning appeared. It said the funds would leave the bank and asked whether to continue. The warning did not say how much money would leave. The checker expected only the interest to go out, so they clicked yes.
A federal judge later called the payment one of the biggest blunders in banking history. Every step of it happened at the user interface, the place where a person tells a machine what to do and the machine shows what it is about to do.
022 min
What a user interface actually does
The Citibank screen did two jobs, and it failed at the second one. Every user interface carries information in two directions. In one direction, a person turns an intention into an action the machine accepts: a typed command, a tap, a ticked box. In the other direction, the machine shows its state and the result of the action: a message, a changed number, a sound.
Most interfaces are built from the same four kinds of parts:
- Input controls take what the person wants: buttons, text fields, check boxes, sliders, a microphone.
- Navigation moves the person between places: menus, tabs, links, search.
- Information and feedback tell the person what happened: messages, progress bars, notifications.
- Containers group related parts so that they read as one unit: windows, panels, cards.
The parts matter less than how they connect. A control whose effect is invisible causes errors even when the control itself is easy to use. The FRONT and FUND boxes were easy to tick. The problem was that nothing showed what leaving them empty would do.
The gulfs of execution and evaluation
In 1986, Ed Hutchins, Jim Hollan and Don Norman gave names to the two distances a person must cross at any interface. The gulf of execution is the distance between what a person wants and the actions the interface offers to get it. The gulf of evaluation is the distance between what the system has done and what the person can see of it. Citibank's staff crossed the first gulf without trouble, because they knew which boxes to use. They failed at the second, because the screen never showed where the principal would go.
Why response time is part of a user interface
How fast the machine answers also belongs to the interface. Jakob Nielsen set out three limits in his 1993 book Usability Engineering, based on research going back to 1968. An answer within 0.1 seconds feels instant, as if the person were moving the object directly. Up to about 1 second, the person notices the wait but keeps thinking about the task. Past about 10 seconds, attention moves elsewhere, so the interface should show progress and when the work will finish.
031 min
Where user interfaces came from
The Citibank error needed a screen, but user interfaces are older than screens. The first computers that businesses used ran jobs in batches. A programmer punched a program and its data into a deck of cards on a separate machine, handed the deck to an operator and came back later for a printout. The cards and the printer were the whole interface. Nobody worked with the computer while it ran.
The command line replaced that. A person typed a command at a terminal and the computer replied in text. The wait for an answer fell from hours or days to seconds. That change mattered more than it sounds. With a quick reply, a person could try something, read the result and change their next step. Working with a computer became a series of short exchanges instead of one long wait.
A user interface is not only a screen
Many short guides define the user interface as whatever appears on a screen. The batch era shows why that is too narrow. A deck of punched cards, a printer, a car dashboard and a voice assistant all take input and show results. Each one is a user interface, and each one can fail in the same two ways: it can make the right action hard to take, or it can hide what happened.
041 min
How the user interface became graphical
Screens and pointing came next, and they opened computing to people who were not programmers. In December 1968, Douglas Engelbart and his team at the Stanford Research Institute showed their oNLine System to about a thousand people at a computer conference in San Francisco. For ninety minutes, the audience watched collaborative editing, video calls, word processing and a new pointing device called a mouse. The event later became known as the mother of all demos.
Researchers at Xerox PARC, several of them from Engelbart's lab, built on that work. Their Alto computer of 1973 combined a screen that showed whole pages, a mouse, windows and menus. People could point at what they wanted instead of remembering commands. The Computer History Museum credits the Alto and similar systems with opening computing to non-specialists, including children. Apple's Macintosh, launched in January 1984, brought the same ideas to a mass market.
Each step moved work out of the person's memory and onto the screen. A command line asks you to recall the right command. A menu shows you the choices, so you only need to recognise the one you want. Touch screens on phones and voice assistants later added new ways to give input, but the two-way job stayed the same.
052 min
Types of user interface
The type of interface decides what a person must know before they start. These are the main types, sorted by how input happens:
| Type | How people give input | What they get back | Where it is common |
|---|---|---|---|
| Command line (CLI) | Typed text commands | Text replies | Developer tools, servers |
| Graphical (GUI) | Pointing, clicking and typing into fields | Windows, icons, menus | Desktop and web software |
| Menu-driven | Picking one option from a list | The next list, or a result | Cash machines, phone menus, settings |
| Form-based | Filling in labelled fields | A confirmation or an error | Sign-ups, bank transfers |
| Touch and gesture | Tapping, swiping, pinching | The screen changes under the finger | Phones, tablets, kiosks |
| Voice (VUI) | Spoken requests | Speech, or an action | Smart speakers, cars |
| Multimodal and adaptive | Several of the above at once; some change their layout for each person | Mixed | Cars, VR headsets, AI assistants |
The Flexcube screen was a mix of menu and form: a list of fields, each with a box and a slot for an account number. Real products rarely use one type. A phone combines touch, voice and forms. A car often combines physical knobs, a touch screen and voice.
The right type depends on who uses it and where. A command line suits an expert who wants speed and can remember commands. A graphical interface suits a newcomer, because it shows the options. A voice interface suits someone whose hands are busy, but it cannot show a long list of choices at once.
062 min
User interface vs. UX, GUI and HCI
People often use "UI" as if it meant the same as three nearby terms. The one axis that separates them is scope: how much of the person's contact with the product each term covers.
| Term | What it covers | In the Citibank case |
|---|---|---|
| User interface (UI) | The controls and displays a person uses | The Flexcube menu, its boxes and the warning |
| Graphical user interface (GUI) | One type of UI, built from windows, icons and pointing | The same menu, because it was on a screen |
| User experience (UX) | Everything about a person's use of a product, before, during and after the interface | The manual, the training and the three-person review as well |
| Human-computer interaction (HCI) | The research field that studies how people and computers work together | The study of why three trained people misread one screen |
UI is one part of user experience design. A product can have a clear interface and a poor experience, for example when the screen is easy to read but the process around it is broken. The reverse happened at Citibank: a careful review process ran on top of a screen that hid the result.
GUI is one kind of UI. A voice assistant has a user interface but no graphical one. Human-computer interaction is the academic field behind both. It produced many of the ideas in this article, including the two gulfs.
072 min
What makes a user interface good
If scope is what separates UI from UX, quality is what separates one UI from another. Most design guides judge an interface on a short list of qualities. They overlap, and none is worth much alone:
- Clear hierarchy. The most important thing on the screen is the easiest to see, through size, weight, contrast and position.
- Consistency. The same control looks and behaves the same everywhere in a product, and like the controls people already know from other products. Teams often keep this in a design system, a shared library of components and rules.
- Low cognitive load. The screen asks the person to remember and work out as little as possible. Showing options, instead of asking people to recall commands, is the main tool.
- Simplicity. Each element on the screen has a job. Removing a rarely used option helps most people, but it can block the expert who needed it.
- Feedback. Every action gets a visible response, within the time limits above.
- Error prevention. Dangerous actions are hard to trigger by accident and easy to reverse.
- Fit to the device. The layout adapts to the screen size, from a phone to a wide monitor. Many teams design the phone layout first, because the small screen forces them to choose what matters most.
- Visual design. Colour, type and spacing affect whether people trust a product and enjoy using it.
Many guides add that the best interface is one the person hardly notices, because their attention stays on the task. A business reason sits behind all of these: a clear interface needs less training and creates fewer support calls. But visual polish cannot fix a screen that hides the result of an action. That was the gap at Citibank, and it was the gap in a very different office two years earlier.
082 min
How a user interface shaped Hawaii's false missile alert
The second case comes from a government emergency office, not a bank. On 13 January 2018, the Hawaii Emergency Management Agency sent a message to phones, radios and televisions across the state. It said a ballistic missile was on its way and that this was not a drill. It was false. The agency took 38 minutes to send a correction through the same alert systems.
The US Federal Communications Commission (FCC) investigated and published its report in April 2018. The agency's alert software let staff send internal test alerts and live alerts from the same screen, with the same login. A drop-down menu listed an internal test missile alert next to a live missile alert. When the officer chose a message, the software asked the same yes-or-no question for a test and for a real alert. It did not show the text that would go out.
The variable that changes between the two cases is what the error costs: money at Citibank, public safety in Hawaii. The interface pattern is the same. A safe action and a dangerous one sit side by side, and the final check does not show which one is about to happen.
Where a user interface stops being the cause
It would be easy to blame the screen for everything, and the FCC report does not. According to the report, the officer who sent the alert believed the missile threat was real. The officer said they had not heard the words that marked the call as an exercise. So the menu did not make them pick the wrong option. What a better interface could have done is slow down a person acting on a wrong belief, for example by showing the full message, or by keeping live alerts on a separate system. Interface design lowers the cost of a mistake. It cannot fix a wrong belief, a missing procedure or poor training.
091 min
Why safeguards around a user interface fail
Both organisations had safeguards, and both safeguards let the error through. Two common beliefs explain why.
Misreading: more reviewers catch interface errors
Citibank required three people to approve the payment, a rule the bank called six-eye approval. It did not help, because all three read the same screen and shared the same wrong belief about it. A reviewer who looks at the same display as the first person sees the same missing information. Extra review catches a careless slip. It does not catch a gap in what the interface shows.
Misreading: a warning dialog is a safety net
The Citibank warning and the Hawaii prompt both asked a person to confirm, and both got a yes. A warning that looks the same every time teaches people to confirm it without reading. It helps only when it names the consequence that is about to happen: the amount, the recipients, the words that will go out. A question like "Are you sure?" with nothing after it tells the person nothing new.
101 min
How to spot a user interface going wrong
Interfaces like Flexcube's usually show warning signs before a large failure. These are things you can check in a support queue, a session recording or a team's shared notes:
- The rule lives in a manual. If staff need a written guide to set a screen correctly, the screen is not showing the rule. Citibank's three-box rule was in a manual.
- People keep their own notes and workarounds next to the system.
- Different people make the same mistake. That points at the screen, not at one careless person.
- Warnings get clicked through in under a second. If a confirmation appears on every action, people stop reading it.
- People check afterwards what the system did, by running a report or calling support.
- Repeated mis-clicks near one control, or many people dropping out at one step.
111 min
Making a user interface work without a mouse
An interface also has to work for people who cannot use the controls it was designed around. The Web Content Accessibility Guidelines (WCAG) 2.2 from the W3C make this concrete in Success Criterion 2.1.1 Keyboard. Every function must work from a keyboard, without needing exact timing between keystrokes. The only exception is a function that depends on the path of a movement, such as freehand drawing.
This criterion matters to blind people, who cannot see a pointer, and to many people with limited hand movement, who use keyboards or switch devices that act like keyboards. A form whose check boxes respond only to a mouse click fails it. The same form also slows down an expert who moves through fields with the Tab key. Designing for the person who cannot use a mouse usually helps the person who simply prefers not to.
122 min
Designing a user interface that prevents these errors
The two cases and the keyboard rule point to concrete design moves. Teams find most problems by testing: they research what users need, sketch and wireframe layouts, build a prototype and watch real people use it before launch. When you review a screen, check for these:
Show the result before the commit.
The last step states what will happen in the person's own terms: the full amount, the recipients, the message text.
Make one intention one action.
If keeping money inside the bank needs three boxes, offer one control that sets all three, or block the payment until they agree.
Separate the dangerous option from the routine one.
Put live actions in a different place, with a different look or a different login, from tests and drafts.
Follow conventions people already know.
A control that looks and behaves like familiar ones needs no manual. This is the heuristic of consistency and standards.
Make each control show what it does.
A signifier, such as a label, an icon or a shape, tells the person what an action will do before they take it.
Undo is often better than confirm
Gmail shows an Undo link right after a person sends an email. In Gmail's settings, the person can choose how long the message waits before it really goes: 5, 10, 20 or 30 seconds. The design accepts that people press Send by mistake and gives them a short time to take it back. Wire transfers and public alerts cannot always be held back like this. Where they can, a short delay with undo protects people better than a question they will answer without reading.
When these moves backfire
Each safeguard has a cost. A confirmation on every action teaches people to ignore confirmations. A delay with undo slows down an expert who sends hundreds of messages a day. Hiding dangerous options deep in a menu can slow down a real emergency. Choose the safeguard by how costly the mistake is and how often the action happens.
131 min
Frequently asked questions about user interfaces
Is a user interface the same as front-end development?
No. The user interface is what people use. Front-end development is the engineering work of building a web interface in code, usually HTML, CSS and JavaScript. A designer decides how it should work, and a developer makes it run.
Is an API a user interface?
Not in the usual sense. An API connects one program to another, not a person to a machine. Developers still read and use APIs, so clear names and helpful error messages matter there too.
Who designs a user interface?
Usually a UI or product designer, working with researchers and engineers. In a small team one person may do all of it. Physical control panels are often designed by industrial designers and human-factors engineers.
How do you test a user interface?
Watch real people try real tasks with it, and note where they hesitate or make mistakes. Expert reviews against usability heuristics and checks against accessibility criteria find further problems before launch.
?4 questions
Questions people ask
Is a user interface the same as front-end development?
Is an API a user interface?
Who designs a user interface?
How do you test a user interface?
§10 sources
Sources
Jesse M. Furman, In re Citibank August 11, 2020 Wire Transfers, Findings of Fact and Conclusions of Law, US District Court for the Southern District of New York, 16 February 2021. newyorkfed.org
Federal Communications Commission, Public Safety and Homeland Security Bureau, Report and Recommendations: Hawaii Emergency Management Agency January 13, 2018 False Alert, April 2018. docs.fcc.gov
Computer History Museum, Timeline of Computer History, 1968: The Mother of All Demos. computerhistory.org
Computer History Museum, Revolution, Input & Output: Xerox Alto. computerhistory.org
Show all 10 sourcesShow fewer sources
Raluca Budiu, "The Two UX Gulfs: Evaluation and Execution", Nielsen Norman Group, 2018. nngroup.com
Jakob Nielsen, "Response Times: The 3 Important Limits", Nielsen Norman Group, 1993. nngroup.com
Jakob Nielsen, "10 Usability Heuristics for User Interface Design", Nielsen Norman Group, 1994. nngroup.com
W3C, Understanding WCAG 2.2, Success Criterion 2.1.1 Keyboard. w3.org
Google, Gmail Help: Send, unsend or schedule emails (Undo Send). support.google.com
Wikipedia, "User interface" (history of batch and command-line interfaces). en.wikipedia.org
