A scalable onboarding ecosystem for enterprise banking operations.

Consolidating eight downstream systems into a single client lifecycle surface for RBC Capital Markets' sales and operations teams.

At a glance
Client
RBC Capital Markets New York
Role
Senior Product Designer Workflow lead
Timeline
2025 — May 2026 Shipped
Team
1 PM, 2 BAs, Eng, Compliance Cross-functional
TL;DR
Institutional client onboarding at RBC Capital Markets touched eight downstream systems and stalled at every handoff. I led the design of a unified lifecycle surface that gave sales, CST, and operations shared visibility across those workflows — reducing intake friction, consolidating ownership, and replacing the load-bearing spreadsheet that had been quietly running the back office.
i. Context

Eight systems, one workflow, no clear owner.

The "system" was a chain of email threads, shared inboxes, and one spreadsheet that one operations lead had been maintaining for years.

Onboarding an institutional client at RBC Capital Markets touches eight downstream systems. Sales captures intent, KYC validates entity structure, credit reviews exposure, legal negotiates documentation, operations sets up the accounts, and downstream processing wires it to the trading systems.

On paper, this is a workflow. In practice, ownership gaps between the systems created blind spots and delays at every handoff. Sales couldn't see where their request was stuck. Operations couldn't see what was coming. Leadership couldn't tell auditors, with confidence, who touched what or when.

8
Downstream systems, each owning a fragment of the lifecycle
3+
Status taxonomies for the same onboarding event
12+
Operations sub-teams with different definitions of "mine"
1
Load-bearing spreadsheet quietly running the operation
"Nobody owns the middle. Things fall through the handoffs."
— Operations lead, week one discovery
System diagram

Unified Client Onboarding Lifecycle.

01
Sales Initiation
Sales
Onboarding request created
Minimal required information at intake. Request enters the lifecycle and acquires a record ID.
02
CST & Client Onboarding Ops
CST · Operations
Request validation
Entity data verified, gaps surfaced back to sales.
Product enrichment
Products attached with branch and capacity attributes.
Downstream routing
Parallel workflows initiated against owning teams.
03
Parallel Downstream Workflows
Multiple ops teams
KYC / AML
Compliance review and classification.
Credit Review
Exposure and counterparty assessment.
Trade Agreements
Legal documentation and negotiation.
Account Setup
Account structures and wire instructions.
Electronic Trading
Trading platform entitlements.
Tax Setup
Tax classification and documentation.
04
Ready to Trade
Trading desk
Client cleared for trading activity
Workflow stages completed, operational visibility consolidated, audit record in place.
ii. Business goal

Three things the bank needed to be true at the same time.

I reframed the brief from "design a new onboarding screen" to "what does each team need this product to remove from their day."

For sales

Initiate without translating

  • No knowledge of downstream taxonomy required
  • See request status in plain language
  • Get notified on blockers they own
For operations

One surface, every request

  • Real-time view of in-flight onboardings
  • Filter by team, risk, and time-in-stage
  • Auto-captured audit trail
For leadership

Defensible by default

  • Every state change logged automatically
  • Compliance-ready without quarterly exports
  • Queryable from the surface itself
iii. My role

Design lead across workflow, alignment, and rollout.

Embedded design lead with end-to-end ownership — from discovery and stakeholder alignment through UAT and post-launch adoption.

i

Workflow architecture

Mapped the existing eight-system chain, identified where work queued versus where we assumed it queued, and proposed the consolidated lifecycle model the rest of the product was built on.

ii

Stakeholder alignment

Led alignment sessions across sales, operations, KYC, credit, legal, and compliance — five teams with five different definitions of "done." Brought structured tradeoff options into each session, not open-ended workshops.

iii

Interaction & system design

Designed dashboards, intake, metadata panels, and role-based filtering inside the bank's design system — contributing new patterns back where the system didn't yet have an answer.

iv

UAT & adoption

Partnered with BAs on UAT planning, joined operations training, and stayed in the room post-launch. Treated shipping as the middle of the project, not the end.

Cross-functional alignment

Five teams. Five different definitions of "done."

Sales
Wanted: fewer mandatory fields at intake.
Compliance
Wanted: stronger data validation, captured upfront.
Operations
Wanted: predictable inflow they could plan against.
Engineering
Wanted: a model that didn't require rewriting 8 backend systems.
Legal
Wanted: defensible audit trail without manual reporting.

The resolution: progressive disclosure across the lifecycle. Sales captures the minimum required to route; compliance data is collected at the stage that triggers it; operations gets predictability through the lifecycle model; engineering keeps the systems of record intact under a translation layer; legal gets an audit trail captured as a side effect of the work itself.

iv. Key product decisions

The four choices that shaped the system.

Most of design at this level is choosing what not to do. These are the four I'd defend in any review.

01
Cognitive load · Front-of-funnel

Minimal sales input at intake

Problem
Intake required data sales didn't have, ops didn't need yet, and that blocked the request from being created at all if anything was missing.
Decision
Strip intake to the genuinely required minimum. Defer everything else to the lifecycle stage that actually needs it.
Result
~40% reduction in mandatory fields at sales intake.
Tradeoff
Downstream teams pushed back — their existing workaround was "make sales collect it upfront." We committed instead to building the follow-up tooling those teams actually needed. A separate scope conversation we chose to take on rather than avoid.
02
Translation · 8 systems, 8 vocabularies

Real-time lifecycle visibility, in plain English

Problem
The same onboarding could be "in review" in one system, "pending docs" in another, "blocked" in a third. Sales had no way to translate.
Decision
One lifecycle model — 6 stages, plain language. Translation layer hidden; full system trace one click away for ops and compliance.
Result
Sales sees status they can act on. Ops sees underlying system state when they need it. Audit trail is not optional.
Tradeoff
Plain-language status risks losing technical fidelity. We accepted that and added a "view full trace" affordance — precise vocabulary is one click away, but it isn't the default.
03
Personalization · Same data, different jobs

Role-based prioritization for the operations dashboard

Problem
"Operations" is 12+ sub-teams with different mandates. Each had a different definition of "this onboarding is mine."
Decision
Role-aware default views, configurable filters, saved queries — but a single shared data model underneath.
Result
Each team sees their slice. The underlying lifecycle is universal.
Tradeoff
Truly customizable dashboards would have shipped six months later and required governance. Constrained customization — small set of configurable dimensions — ships faster and adopts without training.
04
Compliance · Regulated environment

Audit trail as a first-class object

Problem
Existing audit was a quarterly export. By the time something needed defending, people had moved, emails were deleted, spreadsheets overwritten.
Decision
Every state change, reassignment, and edit captured against the onboarding object itself. Queryable from the surface where the work happens.
Result
Compliance doesn't ask for a report. They look at the record.
Tradeoff
Capturing everything means designing a UI that doesn't drown the operator. The activity feed is collapsible, role-filtered, and time-bracketed by default — full record one expand away.
v. Constraints & realities

The conditions the design had to live inside.

A capital-markets onboarding platform doesn't ship into a vacuum. These are the constraints that shaped what was possible — and where the design earned its leverage.

i.

Downstream systems could not be replaced.

KYC, credit, account setup, and trading platforms were each owned by separate org units with their own roadmaps. The lifecycle surface had to coordinate them — not replace them.

ii.

Onboarding ownership was distributed across teams.

Sales, CST, compliance, credit, legal, and multiple operations teams each owned a slice of the lifecycle. No single team could mandate a workflow change unilaterally.

iii.

Audit traceability was non-negotiable.

Every state change had to be defensible to internal and external auditors. Convenience features that bypassed the audit trail were not on the table.

iv.

Compliance dependencies gated every release.

Workflow changes that touched regulatory data required parallel review by compliance and legal. Design decisions had to anticipate that review, not surprise it.

v.

Rollout had to be incremental.

The platform replaced live operational workflows. Big-bang launches were not acceptable — each team's onboarding had to be possible while others were still on legacy paths.

vi.

Operational continuity took precedence.

Day-one trading depended on the existing onboarding rails. The product had to coexist with the systems it was eventually consolidating visibility for — not interrupt them.

vi. Role-based experience design

One lifecycle, four operating contexts.

The same record looks different to each team that touches it — because each team is doing fundamentally different work against it.

Sales
Initiate & track
  • Fast intake with minimal required fields
  • Visibility into request status
  • Clear ownership of what's still owed from sales
  • No exposure to downstream system mechanics
CST & Operations
Coordinate & route
  • Workflow coordination across downstream teams
  • Product onboarding state at line-item granularity
  • Status tracking and lifecycle continuity
  • Deliberate hand-off controls (Ready to Trade)
Compliance & Credit
Validate & clear
  • Regulatory and risk validation workflows
  • Structured access to entity data and disclosures
  • Audit-ready record of every state change
  • Surface for follow-up requests back to sales
Downstream Ops
Execute
  • Queue management for owned workflows
  • Visibility into upstream readiness
  • Lifecycle continuity across systems they don't own
  • Read access to the full request record
vii. A look at the surface

How the decisions show up in the product.

Three recreated views — the operations dashboard, the intake stepper, and the products stage — annotated to show how each decision lands in the interface.

A note on what's shown. The production system is under NDA. The screens below are structural recreations — same information architecture, same patterns, same decisions — with client identities, real data, and proprietary branding removed. The goal is to show how I think, not to leak what I shipped.
View 01 · Operations dashboard

A single surface for every onboarding in flight.

Where the eight downstream systems used to live, there's now one view. Status in plain English, ownership made explicit, time-in-stage as a first-class signal.

Operations dashboard — recreated structure
A
Quick Summary tuned to operational state, not vanity metrics
Total Requests, Draft, In Progress, Ready to Trade, Completed, Not Required — the slices that matter for a sales manager triaging their book. Each tile is the entry point into a pre-filtered queue.
B
Selected Request Overview surfaces context without leaving the queue
Selecting a row opens the right-side overview — entity type, requester, risk, current step, team ownership, last updated. Operators can scan a row's full context without losing their place in the list.
View 02 · Client intake

An 8-step stepper with a persistent context panel.

The intake replaces what had been a single-page form with too many fields. Each stage collects only what's needed to move forward; the right panel keeps the operator oriented across what otherwise felt like eight separate forms.

Client intake stepper — recreated structure
C
"Required from Sales to Get Started" makes the contract explicit
The right-side checklist names exactly what sales must capture for the request to enter the lifecycle — eliminating the "what do you need from me" loop between sales and operations, and giving sales a clear definition of done.
D
Persistent Request Summary & Client Snapshot
The summary panels follow the operator across every stage — the request matures in real time, and what previously felt like eight disconnected forms becomes a single orchestrated intake with the audit trail half-written.
E
Upcoming Tasks anchored to the request, not the inbox
The right-rail task list shows compliance and classification work this specific request is waiting on — surfacing downstream readiness without making sales chase it.
View 03 · Products stage

Where multiple workflows converge on a single record.

The Products stage is the moment the request stops being a form and starts being an orchestration. Each product line carries its own KYC, classification, and trade-readiness — visible in context, actionable from one surface.

Products stage — recreated structure
F
Per-product workflow trackers reveal orchestration complexity
Each product line carries its own KYC → Credit → Agreements → Account → Trading → Tax → Complete progression. Operators see exactly which dimension is blocking which product — not a rolled-up status across the whole request.
G
Request Timeline as the audit trail, made visible
The right-side timeline captures every meaningful state change with timestamp and ownership — Request Submitted, In Progress with CST, Products Added, Ready to Trade. The audit record is the by-product of the work, not a separate report.
All three screens have been recreated outside the production environment for portfolio use. The underlying decisions, IA, and patterns are the work shipped at RBC Capital Markets; the visual identity, data, and entity references shown are fictional.
viii. Impact

What changed.

Shipped and in active rollout across operations teams. Some metrics are directional, called out honestly — appropriate for an enterprise platform at this stage of life.

Operational visibility
8
Downstream onboarding workflows surfaced on a single lifecycle view
Intake friction
~40%
Reduction in mandatory fields at sales intake
Adoption
3+
Operations teams aligned on the shared lifecycle, with further rollout in progress
— And the parts you can't put on a dashboard

Every operations team on the new surface for a month has stopped maintaining their parallel spreadsheet. The single most important signal that the product is doing its job.

Compliance now reviews the record, not a report. Audit prep dropped from a multi-week effort to opening the activity trail.

Sales stopped emailing operations to ask "where is this." Status is visible on the surface they already use.

The lifecycle model has become the shared vocabulary across teams. Meetings stopped relitigating what "in review" means.

ix. In hindsight

What I'd do again, and what I wouldn't.

↻ Would do again

Spend the first three weeks not designing anything.

The lifecycle model is the foundation the whole product sits on. It couldn't have been arrived at by sketching — it came from workflow mapping, alignment sessions, and hours watching operations leads do the old work.

→ Would push harder on

Treat instrumentation as a launch blocker.

Some impact numbers are directional because telemetry came after launch. Next time, measurement ships with the product — at the Lead level, the ability to evidence outcomes matters as much as designing them.

Next case · 02

Cutting a 90-minute account opening down to twenty — Scotiabank.