Turning a Disaster into a Big Win
Goal: Create a new teller system for a major bank.
My Roles: Product designer, researcher, team leader.
Impact: System deploying to banks nationwide. Saving millions/year in operational costs.
"Common Transactions" Teller System, USBank
Situation
Task
Actions
This project – replacing a 30-year-old “green screen” teller system at a major bank – took an interesting turn.
I joined USBank as a User Experience Architect on a project to develop a new Teller system. I inherited the project from a UX Architect who’d left abruptly.
I could see why.
Then came the news – the middleware vendor, whose software we’d counted on to support complex, multi-part transactions, informed us they couldn’t actually do what we’d counted on.
And I saw an opportunity.
Take the complete, unplanned scrambling of our technical architecture as an opportunity to build a much better teller system.
Take the complete, unplanned scrambling of our technical architecture as an opportunity to build a much better teller system.
Working the False Start – “Putting Lipstick on the Pig”
For bank tellers? It was a headache.
In particular, business banking transactions could get much more complex than your typical ATM deposit or withdrawal. A business could bring in checks and cash from several stores, intended for deposit into several accounts, make several more transfers, withdrawals of specific denominations for petty cash and the cash drawers, payments to lines of credit and more, which the teller would have to pull off…
…all the while maintaining the friendly chit-chat and customer service the customers expected from their friendly local branch.
.png)
Each of the boxes with a black title bar is a new pageload that the user – a teller – has to step through for each part of the transaction. And with a business transaction, there can be many iterations through the process. All while the teller is supposed to be providing customer service.
It turned out that the original UX Architect (and the rest of the team, and their management) hadn’t understood some basic accounting.
If you’re consumer, your goal is to deposit to and withdraw from accounts.
If you’re a bookkeeper, accountant or teller, you goal is to deposit and withdraw (credit and debit) to and from a transaction. And the withdrawals – debits – include money going into the accounts – which is backward from the way consumers see it.
The original architect had gotten the “concept model” all wrong.
But we were committed to delivering, and we had a design. So we spent a few months trying to put lipstick on the proverbial pig – concocting elaborate ways to show the tellers the state of the transaction (Figure 7) as opposed to the individual deposit.
This is one of the steps above – “Withdrawing” from an account. Every other possible type of credit or debit had its own page type. The “Summary” on the right was an attempt to bring some context to things. It worked – sort of…
In usability tests, it did…OK. Barely.
Between the lines of the comments was the sense that our design didn’t do the job as well as the 30 year old system it was replacing.
Then disaster hit. And it saved the project.
Saved by Disaster
Around this point, our middleware vendor told us that they had no way of maintaining the state and status information that was intended to go into our running summary column.
What they could do, though, opened up possibilities.
One of the goals of the project was to link the teller stations to the new scanners that would automatically scan checks, deposit and withdrawal slips, and other transaction documents (and, eventually, automatic cash “drawers” that’d count, sort, and dispense cash). USBank was 10 years behind the rest of the industry.
And, I thought, if you just scanned all the deposit, withdrawal and transfer slips, checks and other documents simultaneously, without regard to individual deposits or withdrawals (important to consumers, irrelevant to tellers), it created all of the “credits” to the transaction, automatically, in one step.
This is it. One page. The scanner tallies up the checks, deposit and withdrawal slips; the cash counter tallies up the cash, and adds it all to the transaction on the screen. The user merely adjusts anything that needs adjusting (it's not common). Simple as.
Then, the teller could add the individual “debits” accounts, cash back, etc – deposits to and transfers between – in one step, on one screen.
And in one fell swoop, a process that could have involved several iterations through a minimum of four pages became, in most cases, a single transaction page (Figure 9) and a confirmation (and, if applicable, a page for noting the denominations of cash in a withdrawal), with the vast majority of the routine counting and sorting being done by the scanner and system.
The redesign got some head-scratching from ATM- using UX designers – but the business analysts (who’d all come from the branches) practically jumped for joy. And the usability tests were a hit.
The design matched the user’s conceptual model for what a transaction was supposed to be, in addition to using the technology to make the job easier.
My team – a visual designer, a front end developer and a content writer and I – grabbed a big win from a potential disaster.
Results
The system has been rolling out to branches for the past several years. It’s the first of many attempts to do so to succeed.
My team’s efforts salvaged a huge investment and ended up creating a superior user experience for the bank’s tellers.
Click for Patch for Neurons slide show