ATM Physical-Context Research
Scotiabank · 2017–2019 · Lead UX Researcher
Methods: Competitive analysis · Ethnographic interviews · Feature prioritization · Usability testing · Physical prototyping · Live pilot ·
Timeline: 9 months to MVP
The Problem
Scotiabank needed to redesign its ATM interface. The new features — envelope-free deposits, selectable denominations, multiple currencies — were being implemented in an off-the-shelf hardware product, which meant the team couldn’t change the physical form factor. They could only change what happened on the screen.
The research challenge was one that standard usability methods weren’t designed for: how do you evaluate a physical, transactional experience in a testing environment? An ATM isn’t a desktop app. It isn’t even a mobile device. It’s a machine you stand in front of, usually briefly, often in public, frequently with some combination of urgency and security awareness that doesn’t exist in any other interaction context. The context isn’t incidental to the behavior — it is the behavior.
Getting research that was actually valid meant finding a way to reproduce not just the interface, but the experience of using it.
Research Approach
I began with desk research and a competitive analysis of 11 ATM features across the major Canadian banks — not to benchmark what to build, but to understand the design space and identify where Scotiabank was behind, at parity, or ahead. This established a feature inventory and a starting point for prioritization conversations.
Next, I ran ethnographic interviews (N=8) with a participant mix that covered different relationships to cash — people who used ATMs frequently, people who almost never did, people who’d had anxiety-producing experiences at machines, people who treated ATMs as entirely routine. The goal was to understand the mental models, behaviors, and concerns people brought to the interaction before any specific interface existed. What came out was a clear hierarchy: speed, safety, and transaction confidence were the things that actually mattered. The advanced features the product team was most excited about were secondary to users’ need to feel secure, feel fast, and feel certain the transaction had completed correctly.
The feature prioritization activity made this visible in a structured way: when asked to rank what they cared about, participants’ rankings diverged substantially from the business’s assumptions about what users wanted.
The prototype problem — and the fix
Initial usability testing used an InVision prototype running on a touch-enabled tablet. It failed immediately.
Participants interacted with it as a tablet. They swiped exploratorily, tapped around, took their time. None of the behavioral patterns that characterize real ATM use — the transactional urgency, the physical awareness of standing in a semi-public space, the micro-decisions about how long to linger — were present. The scenario lacked the physical realism that produced the behavior we needed to observe.
The fix was low-tech. We built a cardboard replica of an ATM machine: a full housing with a card slot, a screen opening sized to hold the tablet, a cash dispenser area, and Scotiabank branding. It took about a day to build and cost almost nothing.
Once participants were standing in front of something that looked and felt like a real machine, their behavior shifted immediately. The tablet disappeared into the context of a banking transaction. We started getting data we could actually use.
From there, testing progressed through iterative low-fidelity and high-fidelity rounds, and ultimately a live pilot at internal Scotiabank locations in Toronto.
What We Found
Research directly shaped the feature set. Four features were built based on observed behavior patterns rather than business assumptions:
Express Cash — a fast-path withdrawal flow built around the most common observed transaction pattern. Users who came to the ATM knowing exactly what they wanted experienced the standard flow as unnecessary friction. Express Cash eliminated that friction for the majority use case.
Choose Your Cash — selectable denomination options. Emerged from observed needs around specific cash amounts that standard $20 increments didn’t serve.
Hide Balance — the interface originally used the label “Privacy Mode,” which created unexpected anxiety in testing. Participants weren’t sure what it meant — did it hide something from the bank? Was it a security risk? Renaming it to “Hide Balance” with a clear explanation of what it did resolved the confusion entirely.
Quick Exit — an immediate session-end button that addressed something that came up consistently in the ethnographic interviews: the physical safety concern of lingering at an ATM. Participants wanted to be able to end a transaction and remove themselves from the machine’s proximity as quickly as possible.
Impact
All four features that shipped were grounded in observed user behavior. The feature prioritization activity had shown that the business’s assumptions about what users wanted didn’t match what users actually needed — that finding shaped which features got built first and which were deprioritized.
The project also produced a custom usability rating scale designed for ATM-specific evaluation, which became a reusable research instrument for subsequent ATM and kiosk research at the bank.
Reflection
The cardboard ATM is probably the most-told story from my time at Scotiabank, and what it’s really a story about is what “prototype fidelity” actually means. It doesn’t mean polish. It doesn’t mean high resolution or realistic data or finished visual design. It means faithfully recreating the context that produces the behavior you need to observe. We built a piece of cardboard furniture that cost almost nothing and immediately made our testing valid in a way that an expensive digital prototype hadn’t been.
The feature prioritization finding was a different kind of lesson. The business came into the project with a clear view of what was important — the novel features, the differentiated capabilities, the things no competitor had done yet. Users came in with a different view: give me speed, give me safety, let me finish and leave. Those aren’t irreconcilable — the novel features still shipped — but the research changed the order in which things happened and why. That’s what it looks like when research actually influences a roadmap rather than just documenting what was built.