ATB Financial · 8 min read
An e-Transfer that doesn't need anyone's email address
Email was the only way an ATB customer could send an e-Transfer. Opening the flow to SMS meant auditing four existing journeys as carefully as designing the new one.
At a glance
- Role
- Product Designer, Money Movement — freelance
- Duration
- About 6 months, inside a Dec 2022 — Jun 2024 engagement
- Platforms
- iOS · Android · Responsive web
- Tools
- Figma · UserTesting
- Team
- Product Manager · UX Researcher · Content Designer · 1 solution developer
680k
personal customers the feature reached at launch
3.14%
used SMS the first time they opened e-Transfer after launch
4
existing flows audited and redesigned alongside the new one
Shared with permission. Flows and prototypes were public on the original case study.
Challenge
Email, or nothing
ATB Financial is a bank and a Crown corporation wholly owned by the province of Alberta, with native iOS and Android apps and a responsive website. This work sat in the Money Movement portfolio.
Interac e-Transfer at ATB accepted exactly one transfer method: email. So when a customer had only a phone number for the person they were paying, sending money became an errand across three apps — text the recipient to ask for an email address, wait for the reply, go back into the bank, add the recipient, then send. Every one of those steps is a place to give up.
The market case was not in dispute. Payments Canada reported a 15% rise in e-Transfer volume and a 51% rise in value — the method customers were being denied was the direction the money was already moving.
Two constraints shaped the solution. Interac has requirements about which transfer methods can be active. And the new control had to live inside ATB's existing design language while still improving the patterns around it — a new method could not read as a bolt-on.
Success was defined as five things, not one: send by SMS, request by SMS, register Auto-Deposit against a mobile number, add SMS to a new or existing recipient, and show SMS transfers in history. Only the first two are what people name when they describe the feature.
Research
The demand was documented. The risk was elsewhere
I did not need to establish that customers wanted this. Our researcher had it in user verbatims 3 months running — people asking for exactly this feature, unprompted.
So the research effort went where the risk actually was: the flows that already existed. I audited ATB's production journeys by wiring them out end to end, wired out the same journeys at peer institutions, then built a comparison matrix to reason about the options and propose a new flow — which I took to the design team, the solution developer and the PM to find out what was genuinely buildable.
- 01ATB validated the transfer method twice — once when a recipient is added, and again when money is sent. No peer institution did this. The first check spends the customer's time on information that can change before it is ever used.
- 02The MVP could not stop at sending, requesting and Auto-Deposit. Adding and managing recipients, and transfer history, are part of the same surface — leave them out and the feature is only half present.
- 03Customers still prefer SMS for notifications, despite knowing exactly how much spam arrives that way. The channel's reputation did not change the preference.
Design
One redundant check, and everything that followed
Finding 01 is the one that changed the design. If validating the transfer method at add-recipient is redundant, then that step does not need to police anything — it needs to present both methods honestly and get out of the way. That decision cascaded through all four flows.
The principle I worked to: let the feedback decide. If the data says it, the design should end up feeling obvious rather than clever.
- Add / Manage recipientBoth transfer methods get equal exposure through tap-to-expand inputs, and nothing is pre-selected. Whichever one a customer opens reflects a real choice rather than the path of least resistance.
- Send e-TransferRadio buttons recall the last method used with that particular recipient, so repeat transfers get faster while the switch stays one tap away. Details of the selected method sit directly below the option, along with its validation result — no second screen to confirm what you picked.
- Request e-TransferRequest mirrors Send exactly. Two flows that do the same job should not have to be learned twice.
- One control, two form factorsA dropdown on desktop, a bottom sheet on mobile — chosen for consistency with the rest of the app and for accessibility, and because a list-based control stays extensible when the next transfer method arrives.
- The long-email problemWhen an email address is too long to sit beside a phone number, the two methods stack rather than truncate mid-string, and truncation happens before the domain. Small — and the kind of detail that decides whether someone trusts the address in front of them enough to press send.
- What I rejectedPre-screening the transfer method at the add-recipient step. It was on the table, and Finding 01 is the argument against it: a check that early is spent before it is useful. It went to future enhancements rather than into the MVP.
Before
Add / Manage recipient
- Email address only
- Nothing to do here if all you have is a phone number
After
Both methods, no default
- Email and mobile, both tap to expand
- Nothing pre-selected, so whichever one you open is a real choice
Before
Send e-Transfer
- One method per recipient, and it is email
After
Method recalled per recipient
- The method is remembered, so repeat transfers get faster
- Switching stays one tap away, details directly below
Before
Request e-Transfer
- A second flow doing the same job, learned separately
After
Mirrors Send exactly
- Same shape as Send — one thing to learn, not two
Before
Auto-Deposit
- Registration accepts an email address only
After
Register with a mobile number
- The same method the sender now has for you
Validation
Two studies, one clear winner and one honest tie
The competing options went to unmoderated usability testing in December 2023, run by our UX researcher. 14 participants across 2 studies, aged 25 to 59, spread across life stages from family-building to retirement. None of them were ATB customers — most banked with TD or RBC — which was deliberate: it takes brand familiarity out of the result and tests whether the pattern reads on its own.
Half of them had sent an e-Transfer by mobile number before, but only once or twice. 5 of those 7 still preferred email, and their reasons were worth hearing: channel familiarity, a sense that email is more secure, and simply that most recipients hand over an email address. The 2 who favoured mobile said it was for family and friends, whose numbers they already had. That is the real shape of the opportunity — SMS is not a replacement for email, it is the method for the people you already know by phone.
- Remove — decidedTwo placements for removing a transfer method: alongside the method title, or at the bottom behind a trash icon. 7 of 8 understood both, but 6 of 8 said the inline placement made it unambiguous what was being removed — “it’s more clear what it’s going to remove.” The one dissenter read the bottom placement as clearing the entered information rather than the method itself, which is exactly the ambiguity the inline version closes. Option 1 shipped.
- Add recipient — no winnerOption A needed a tap to open the second method’s field; Option B had both open with an “OR” between them. B tested slightly better on communicating that both are optional — but only because those users had skipped the line at the top of the page saying so. On convenience the two were a tie: the difference is one click, and a click does not stop anyone sending money. I chose A, because it reads cleaner and it is the one that still works when a third transfer method arrives.
- The finding under both resultsPeople do not read the page unless the feature is unfamiliar or something has already gone wrong. That is not a copy problem to be solved with more copy — it is the argument for putting the meaning in the structure, which is what choosing Option 1 and Option A both did.
- What testing left openTwo things I logged rather than solved. There is no path shown for adding a transfer method back after removing it. And since most customers will only ever add the one method they or their recipient prefers, the page should say plainly that one is enough — the prototype only said that both were optional, which is a different sentence.
Impact
What shipped, and what I can prove
SMS e-Transfers shipped in October 2024, to roughly 680,000 personal customers.
3.14% of customers used SMS the first time they opened e-Transfer after launch — first-session adoption of a method that had not existed the day before, with no onboarding to explain it.
I will be straight about the limit of that: the engagement ended before a second quarter of data came in, so I do not have a longer series. What the number does establish is that the control was legible enough to be chosen without being taught — which was the design bet.
Reflection
What I took from it
Mapping the whole journey up front is what resolved problems early — you cannot argue about a flow nobody has drawn.
Hold the MVP and the future at once
It let us cut the redundant check without pretending the idea behind it was worthless.
That is what set a vision rather than just a scope.
Handoff is a conversation
Notes with the reasoning behind each decision, a walk-through during refinement, and a second one with the developer before he started.
Both walk-throughs bought back more review time than they cost.