Senior UX Designer, AccèsD Mobile

The Usable Bank

062011–2013

Mobile banking redesign for Desjardins’ AccèsD app, used by millions of Canadians for everyday banking, transfers, and payments — including the first mobile implementation of Interac e-Transfer for Desjardins. It shipped on Android first, where it earned 4.5 out of 5 on Google Play; that reception led Desjardins to commission the iPhone redesign, which carried the same patterns over. Both platforms ran a shared, mobile-optimized web view inside a thin native shell. Security and trust were a constant baseline, as they are for any banking app; the design problem was making a high-stakes product genuinely usable.

AccèsD is Desjardins’ consumer banking application, used by millions of Canadians for everyday transactions — balances, transfers, bill payments. It had been in market for years before I came in to redesign the mobile experience; Interac e-Transfer itself had existed as a service since the early 2000s, but this was the first time Desjardins offered it inside a mobile app.

The job had two halves. One was to bring something genuinely new and more usable — including Desjardins’ first mobile implementation of Interac e-Transfer. The other was to do it inside the constraints every banking app carries. A mobile banking app is a high-stakes product: people log in for thirty seconds to confirm a deposit cleared, or to send rent to a landlord, and every interaction has to earn its place against the alternative — opening a browser and using the desktop site they already trust. Security and trust were never the headline; they were the floor under everything.

The first AccèsD I designed and shipped ran a comprehensive scope: account summaries and detail, transfers, and bill payments reaching real biller brands. The information architecture was documented as a hierarchy tree before a single screen was specified.

Phase III then redesigned the app down. The feature set narrowed toward core banking. Usability, not feature breadth, became the point. The work covered the full mobile surface — home with account summaries, account detail with progressive disclosure, transactions grouped by date with pending operations, transfers, and bill-pay integrating real biller brands across four distinct biller-type variants. The product shipped on Android first, built as a thin native shell hosting a shared, mobile-optimized web view — a UIWebView on iOS, a WebView on Android — itself a mobile variant of the broader AccèsD desktop platform; the interface was HTML, not native widgets. It reached 4.5 out of 5 on Google Play, and that reception led Desjardins to commission the iPhone redesign on the same foundation.

The Phase III scope ran across several sub-projects — the AccèsD redesign, prepaid cards, and Interac e-Transfer — each with its own spec discipline. The methodology was a documentation convention I authored: a DCI (Document de Conception d’Interaction) paired with a working HTML prototype. Interac e-Transfer — Desjardins’ first mobile implementation of the service — alone ran through nearly a year of mobile iteration — send-to-person, the security challenge, confirmation, and accept-transfer flows across iOS, Android, and web — before consolidating into a 242-page bilingual specification co-authored with Émilie Valcourt.

The work shown spans the whole arc — dated sketches and flow diagrams, the working HTML prototypes I delivered, and the bilingual specifications. Production screenshots from this era did not survive; for the shipped screens, the prototype is the medium of evidence, not the work itself. AccèsD shipped and ran in production for years.

What I took from the work was a clearer sense of how regulated industries actually operate. Compliance, accessibility, security, and brand sit at the same table as user experience. A bank’s app cannot ship the way a startup’s can. The design that survives is the one that passes every review without being compromised by any of them. That constraint is the design.

I — Research & Method

In a regulated bank, the method is the deliverable. Before a single screen was drawn, the work lived on paper — the architecture mapped, the documentation convention set, the process agreed, the bilingual behaviour settled as logic. The design that ships is the one that has already passed every review; this is how it earned that.

A hand-drawn navigation schema for AccèsD — dozens of phone frames (Particuliers, Mes comptes, account detail, transfers) linked by arrows into a single map. — fig. 1 — 2011, the architecture on paper — a navigation schema mapping every AccèsD screen and the paths between them, drawn before any screen was specified.

A formal flowchart titled “Gestion de la langue” with numbered steps and decision diamonds, resolving the app’s language from system, platform, and user settings. — fig. 2 — 2011, bilingual as logic, not translation — a language-management state machine reconciling system, platform, and user, and the first-run choice it had to serve. Bilingual rigour was native to the work, not bolted on.

A storyboard weighing two first-run options — speak to the user in French, or in the language of their choice — three steps each. — fig. 2 — 2011, bilingual as logic, not translation — a language-management state machine reconciling system, platform, and user, and the first-run choice it had to serve. Bilingual rigour was native to the work, not bolted on.

The same discipline ran through testing. Usability sessions were scripted to real tasks — a first-time transfer to a “Pierre Tremblay,” confirming a cheque had cleared — and what they surfaced fed straight back into the redesign.

II — AccèsD Mobile

The redesign earned its simplicity. The architecture was mapped before a screen was drawn, a comprehensive first release shipped, and then — unusually — the app was redesigned down, trading feature breadth for the clarity and everyday usability a banking app lives or dies on.

An information-architecture hierarchy tree for the AccèsD app, from the Desjardins root down to account-detail and bill-pay nodes. — fig. 3 — 2011, the information architecture, documented as a hierarchy tree before a single screen was specified.

A hand-coloured storyboard of six iPhone frames — home, loading, the account list, and two sign-in dialogs — rendered in marker and watercolour. — fig. 4 — 2013, colour before code — the iPhone redesign storyboarded and rendered by hand, from home to sign-in, to judge the product as a whole before a line of it was built.

Then Phase III pared it back. The scope narrowed to core banking, and progressive disclosure kept each screen quiet until the account holder asked for more.

The redesigned account list — account types as plain rows under a Mes comptes header. — fig. 5 — 2012, redesigned down — the account list and an account detail that discloses held funds and available credit only on demand.

An account-detail screen showing balance, held funds, and available credit, with a drill-in for the held-funds breakdown. — fig. 5 — 2012, redesigned down — the account list and an account detail that discloses held funds and available credit only on demand.

An operations screen — the account card and balance, a row flagging three pending operations, and transactions grouped under dated headers (26 May, 25 May). — fig. 6 — 2012, the everyday surface — operations grouped by date with pending items surfaced first, and the single fork that splits a transfer between your own accounts and another person.

A “transfer funds to” action sheet over the home screen, forking between one of my own accounts and a person. — fig. 6 — 2012, the everyday surface — operations grouped by date with pending items surfaced first, and the single fork that splits a transfer between your own accounts and another person.

A funds-transfer form — recipient, source account, amount, frequency, and date, with an optional reason field. — fig. 7 — 2012, the everyday jobs — a transfer to a payee, and a bill payment carrying the biller’s real brand.

A composite of four “Ajouter une facture” variants — Stable, Variable, Préfixe, and Remise gouvernementale — each fitting a different biller data shape. — fig. 8 — 2012, bill-pay’s four biller-type variants — each form shaped to the data a biller class actually carries, from a fixed reference number to a taxpayer’s SIN.

III — Interac e-Transfer

Moving money to another person is the moment a banking app is trusted most, and watched most. Interac e-Transfer — which I designed as Desjardins’ first mobile implementation of the service — covered the full lifecycle: register, send, receive, accept, refuse, cancel, remind. One detail set the rest: the recipient’s first encounter with the transfer happens in their inbox, not in the bank’s app.

A numbered ten-frame storyboard of an Interac transfer to a new person — home, menu, transfer-or-pay options, method, Interac registration, activation, recipient picker, new recipient, the transfer, and the account detail. — fig. 9 — 2012, the whole lifecycle on one page — a transfer to a new person walked frame by frame, from the home screen through registration to the completed transfer, before any of it was specified.

A hand-coloured ecosystem diagram of Interac e-Transfer — Desjardins, the Interac service, and the recipient’s financial institution as three columns, with money and email notifications flowing between member, account, and the standard rail. — fig. 10 — 2012, the system behind the screen — the Interac e-Transfer ecosystem mapped across the sender, the Interac service, and any other institution, so the mobile flow could account for every party in the exchange.

A recipients list split into two groups — Desjardins members by account number, and contacts at other institutions by email or phone. — fig. 11 — 2013, Interac e-Transfer — recipients split between Desjardins members and contacts at other institutions, and a pending transfer with its status history and a weighted destructive action.

A pending Interac transfer detail — recipient, amount, reference number, a status history, and a red delete action set against a secondary reminder. — fig. 11 — 2013, Interac e-Transfer — recipients split between Desjardins members and contacts at other institutions, and a pending transfer with its status history and a weighted destructive action.

A notification email shown inside an email client — “you’ve received a transfer” with a link to deposit the funds by choosing a financial institution. — fig. 12 — 2012, the recipient’s first encounter happens outside the bank’s app — so the notifying email was designed inside an email client, where the recipient actually reads it.

A specification page placing the iPhone column — a list of pending Interac deposits, annotated state by state — beside Android and Web columns marked “Contenu identique.” — fig. 13 — 2013, one specification, three platforms — the iPhone column drawn in full, Android and Web inheriting it (“Contenu identique”). The wireframe is annotated state by state, the pending-deposit status read straight off the list.

The “Tableau des éléments d’interface” for the pending Interac deposits screen — columns No., FR, EN, Spécifications, Directives, decoding each numbered and lettered callout (1–7, A1–F1) marked on the wireframe above. — fig. 14 — 2013, the spec behind the callouts — the interaction-element table that pairs with the wireframe above, decoding each numbered marker into its behaviour, business rule, and bilingual (FR/EN) label.