Zaid Hisham

Talking to a cash machine

Bringing one of the most error prone transactions a bank teller handles out of 1990s desktop software and into a modern web application, without breaking the design system it had to live inside.

Transact cash back flow, tablet view with dual-layer tabs
The cash back flow on tablet, where tellers do much of their work.
My roleDesigner on the Transact redesign team at Infosys. Owned the cash back transaction, designed and prototyped it, and presented to product teams and early adopter clients.
ClientFiserv, a software provider for banks and credit unions.
UsersBank and credit union tellers handling in-branch transactions.
ConstraintEverything had to adhere to Transact's new design system.

The problem

Transact is the application tellers use for in-branch transactions, and it was being moved from a 1990s desktop product to a modern web application. Cash back is one of the harder transactions in that set: the teller is doing arithmetic, talking to a customer, and operating a physical cash recycler that collects and dispenses notes, all at once.

My task was to bring that transaction into the new application and connect it to the machine sitting beside the teller.

Approach

  • Worked closely with the business analyst to deep dive the requirements, since the edge cases in a teller transaction are the whole job
  • Adapted the design to carry calculator functionality inside the existing framework rather than bolting on a separate tool
  • Introduced a dual-layer tab system to make the transaction workable on tablet
  • Kept every decision inside the new Transact design system
Calculator functionality inside the transaction frame
Calculator behavior built into the transaction rather than beside it.
Dual-layer tab system across breakpoints
The dual-layer tab system that made tablet use practical.

Outcome

The result was a modern web transaction that streamlined teller operations and fit the rest of the Fiserv ecosystem, with the physical cash recycler integrated into the flow rather than operated alongside it.

To add: anything measurable, such as transaction time, error rate, or training time. Even a qualitative line from an early adopter client session would strengthen this ending.

What I took from it

The interface was never the whole system. A teller's transaction includes a machine, a customer standing there, and a policy about what can be given in cash. Designing only the screen would have produced something that tested well and failed at the counter.

The same is true of a checkout: the page is one part of a situation that includes a phone, a wallet, and whatever doubt the person arrived with.