What happens when 'simple' migration isn't so simple?
Context
RBC’s $13.5B acquisition required us to design the full migration experience even before the deal was finalized. With Competition Act restrictions limiting access to acquisition clients and their workflows, we were designing under significant ambiguity while preparing for a moment when thousands of business accounts would move at once.
Our goal was to ensure that business clients could set up their permissions, approval rules, and services across the required RBC platforms before their accounts migrated, so their operations continued without disruption on day one.
What initially seemed straightforward quickly surfaced two major challenges that shaped the rest of the project.
1
Align stakeholders on the client journey by creating a shared service design blueprint that unified teams and clarified pain points.
2
Create a cohesive multi-platform onboarding experience through a guided setup flow that connects all required RBC platforms.
Co-facilitated a cross-functional service design workshop to align teams on the end-to-end client journey and define what business clients needed to know before, during, and after migration.
Designed a unified onboarding experience that consolidated setup tasks from three platforms and added contextual guidance to help business admins complete complex steps independently.
Transformed a paper-based setup process into an intuitive digital flow, reducing reliance on relationship managers for configuration.
Iterated on the onboarding experience using usability testing insights, adding clarity to the tasks that caused the most confusion.
My Contribution
Reduced expected support-call volume by introducing a unified flow with clear contextual guidance, enabling support teams to focus on higher-value migration cases.
Decreased reliance on relationship managers to manually configure platforms, allowing them to prioritize onboarding relationships with new clients.
Increased clients confidence in completing high-complexity tasks independently, and reduced confusion by progressively setting expectations so clients could plan their operations without disruption.
Outcomes
Shannon Burke — Design Lead
Ali El Hajj-Hassan — Researcher
Natali Guirguis — Interaction Designer
James Wong — Visual Designer
Jess Burgess — Content Designer
Design Team
To comply with Non-Disclosure Agreements, proprietary product details in this portfolio have been anonymized and metrics have been generalized. This ensures the protection of confidential information.
Mapping Client Journey
Starting with a lot of assumptions
At first, our product, engineering and support partners assumed the migration process would follow a simple, but I discovered that they had different ideas about who these clients actually were and what their journey looks like.
I suggested to our design director to align everyone by holding sessions with all partners to agree on client journey.
Since we didn't have much data on their actual business profiles yet, we (design lead and researcher) drafted the service blueprint based on our best guesses of what would happen at each stage and flagged the gaps where we'd need our stakeholders to fill in the blanks.
We broke the journey down into four stages: pre-onboarding, first-time registration, business verification, and signing into the banking hub.
First draft: mapping the current onboarding process.
Filling in gaps together
We brought business ops, relationship managers, technical leads, and banking directors into working sessions.
I co-facilitated a cross-functional workshop and weekly walkthroughs where we:
Replayed the blueprint step-by-step, validating or replacing assumptions with real workflows.
Identified ownership, handoffs, and failure points; captured dependencies and data needs.
Assigned questions and gaps to each department, so we can align on how they will address the gaps on next walkthrough
Revised Roadmap: Highlighted gaps and unknowns for stakeholders
Outcome
The blueprint gave everyone a shared view of the journey, which aligned teams on roles, dependencies, and timing.
Seeing its impact firsthand, stakeholders began advocating for service design as a way to tackle future cross-platform challenges.
The Reality of the Onboarding Experience
Disconnected Platforms
Clients had to set up two separate platforms, the main banking platform and the payment platform, that did not communicate. This often meant entering user permissions and approval rules manually, and these tasks required two administrators to complete: one to configure and another to approve.
Untouchable Legacy System
Our main banking platform supported millions of existing business clients, which made any code change risky. Engineering avoided touching the system for fear of breaking live environments and there was no time for a full sprint to test new code safely. The platform also lacked self-serve guidance and in-app support, limiting what we could improve before migration.
Manual Data Setup
We also could not confirm how much client information would transfer automatically. Many clients had to recreate payment templates and payee information from scratch across both systems.
First Attempt: One-Pager Onboarding Experience
The idea was to bring together all the setup steps for both the main banking platform and the payment platform in one place, so clients could see their progress at a glance and self-check once they complete the task.
Tasks opened in separate tabs, and admins returned to the page to mark each one as completed.
When Simplicity Wasn’t Enough
As we shared this approach with our GTM and product teams, it became clear that clients would need more support to complete each step. We also knew the scope was still evolving. Several concerns emerged:
Pre-disclosure information needed more space so clients could understand what would change before migration and plan their business operations accordingly.
Clients needed more context about each platform, including why they needed it and what they were expected to do inside it
Account verification couldn’t live inside a single-page flow, as clients had large volumes of business, credit, and foreign currency accounts that required dedicated review and mapping.
Tasks were likely to be complex, especially because the setup experience in the main banking platform was unintuitive and difficult to navigate..
Additional setup tasks were expected to surface as teams learned more about the migration.
A third platform outside the business ecosystem would also need to be included as part of onboarding once the acquisition details became clearer.
To support the growing complexity of onboarding, we redesigned the experience into a guided, step-by-step flow. Clients now get clarity on what they need to do, when to do it, and why each task matters.
Breaking it down into steps
We added introductory pages that explain what to expect before, during, and after setup. Clients learn what each platform is for, and what they need to prepare ahead of migration.
Intro pages: set expectations early
Review accounts separately, then set up each platform with clear tasks
Clients first land on a separate Review Accounts page where they can see hundreds of mapped business, credit, and foreign currency accounts. From there, each platform has its own setup page with required tasks and progressive disclosure so admins know what to prepare and complete for that specific platform.
We digitized the paper-based workflow for setting FX permissions and approval rules so clients could transact in their foreign exchange accounts before migration.
This work required multiple iterations and close collaboration with business, compliance, and engineering. I included a prototype here to illustrate the final direction, and I walk through the full process in interviews.
Streamlined FX setup
Because we couldn’t test with actual clients due to NDA restrictions, we created scenario-based tests with a proxy group. We learned that users needed clearer explanations about why multiple platforms were involved and what to prepare before each step. This helped us strengthen the content so onboarding was easier to understand.
Testing what we built
Outcomes
Fewer support calls during onboarding
Clear context and in-platform help lowered onboarding questions directed to customer support.
Less reliance on relationship managers for FX setup
The new digital FX permissions flow allowed clients to complete setup independently, reducing the need for manual assistance.
I’m honored that you’ve made it this far ❤️
What I Learned
Design as an alignment tool: Service design helped bring teams together, reveal gaps in our understanding of the client journey, and align on what needed to be built.
Prototyping to clarify ambiguity: Early requirements were unclear, so I used prototypes to surface hidden tasks, dependencies, and operational realities that were not documented.
Designing around legacy constraints: I learned how to create clarity and structure even when core platform UIs could not be changed due to technical and timeline limitations.
Working with limited user access: With real client testing restricted, I learned how to collaborate closely with research to interpret proxy feedback and validate assumptions.
Orchestrating multi-platform setup: I learned how to structure tasks in a progressive, step-by-step way and understand how each platform depended on the main banking platform for user data and admin permissions.
Looking Ahead…
This work revealed that platforms outside our ecosystem will need to be brought into the long-term roadmap.
Unifying them within a single business banking platform will significantly improve client experience and operational efficiency.