From one person, one account — to many people, many accounts

I joined RBC as a contractor and ramped independently across three teams in 18 months — Personal Banking, Business Banking, and Credit Cards & Deposit Accounts — with no formal onboarding support. This case study covers the account-ownership work: bringing joint account opening online for the first time. Before this, opening a joint account meant going into a branch — it had no digital path at all.

Digitizing it wasn't a matter of translating an existing branch process into a web form. The online acquisition flow had only ever been built around one assumption: one person, opening one account. Joint ownership didn't fit into that shape — it needed a mental model the flow had never had to support before.

This project landed at a specific, harder moment: the bank was simultaneously introducing multi-product account opening — letting one applicant open several accounts in a single session. So the acquisition flow needed to absorb two new dimensions at once, not sequentially. Ownership type (who's on the account) and account multiplicity (how many accounts) both had to be designed into the same flow, and each affected how the other should work. The flow had to go from one person opening one account to multiple people opening multiple accounts — without the experience feeling like two separate features bolted together.

Once I mapped it out this way, the underlying question became clearer: what's the smallest, most honest model of ownership that still scales cleanly across any number of accounts? Looking at what actually happens when someone opens a joint account, it isn't really a distinct product from a sole account — it's someone opening an account and optionally inviting another person onto it. If that person never accepts, the account just stays sole. There's no other fundamental difference between the two — so a model that treated "joint" as an optional layer, rather than a separate pathway, was the one piece that could scale across both new dimensions at once.

This wasn't a new idea for the bank — online banking already used this exact model for adding a co-applicant to an existing account, no sole/joint decision required. I proposed applying the same pattern here: sole by default, joint as an optional invite, validated against that existing, proven precedent rather than introduced as something novel and unproven.

I led exploration of three competing UX architectures for account-ownership configuration and presented the trade-offs directly to leadership, advocating for the direction I believed scaled best for multi-account applications.

• Radio button, asked once: simplest to build, but anchors the product to the old sole/joint framing and doesn't extend cleanly to future multi-account scenarios.
• Two bespoke pathways (status quo): the existing direction — duplicative to build and maintain, and reinforces the wrong mental model for both users and the team.
• Invite model (my proposal): sole stays the silent default; a dedicated, optional step handles the invite. Scales cleanly to householding and multi-account bundles the product team was already anticipating.

Leadership ultimately selected a variant of the radio-button approach for the initial release — not because the invite model was wrong, but because research showed joint accounts benefit from an explicit, visible entry point, and leadership wanted a pattern that could extend to the public site in future, before a user even enters the application flow. I disagreed with the technical framing, but the reasoning was legitimate: reasonable people weighing the same trade-offs differently. I made the case, understood why the room landed where it did, and moved the work forward.

The account-ownership question didn't live in isolation — it sat inside a larger "single sales rail" unification effort spanning prospect, existing-client, and advisor-assisted flows. I sustained cross-functional alignment across product, engineering, legal, and platform teams through two major pivots in that broader initiative, making sure the account-ownership model stayed coherent even as the surrounding flows changed underneath it.

Beyond this project, I advocated for shared patterns and delivery norms with the broader design org, influencing how 20+ designers approached similar ambiguous, rules-heavy problems across the bank's other teams.

The hardest part of this project wasn't the mental-model reframe itself — that came from just looking closely at what the flow actually did. It was building a case precise enough to survive a room full of stakeholders who each had a legitimate, different set of priorities, and then being able to let go of my own preferred answer once I understood theirs.

I'd still argue the invite model is the more scalable long-term direction, and I said so. But the version that shipped reflects real constraints I hadn't fully weighed going in — and the process of getting there taught me more about negotiating trade-offs at this scale than shipping my own idea unchallenged would have.