RBC Capital Markets Regulated enterprise · Capital Markets

Eight onboarding systems, one lifecycle surface.

An institutional client onboarding platform that moves a client from first request to ready-to-trade across Sales, Client Service, Compliance, Credit, Legal, and Operations.

Role
Senior Product Designer
Workflow lead
Timeline
2025 to May 2026
Discovery to rollout
Scope
End to end
Cross-functional
Eight systems unified into one lifecycle, with ~40% fewer intake fields (directional)
The onboarding operations dashboard, showing every in-flight request with its status, owner, and current step
Operations dashboard
images/dashboard.png

Some details and screens have been simplified or anonymized to respect confidentiality.

≈30sOpen here. Establish scale in one line, then move. Next: the 45-second overview.
01 · Executive summary

The project on one page.

Role
Senior Product Designer and workflow lead. Accountable end to end.
Timeline
2025 to May 2026. Discovery through incremental rollout.
Team
Product, business analysts, engineering, QA, and the operating teams.
Business context
Institutional client onboarding across eight downstream systems.
Users
Sales, Client Service, Operations, KYC & Compliance, Credit, Legal, Leadership.
Responsibilities
Discovery, workflow and IA, interaction design, decisions, UAT, rollout.
Deliverables
Lifecycle model, IA, dashboard, intake, role-based views, design patterns.
Impact
Eight systems on one surface, ~40% fewer intake fields (directional), spreadsheets retired.
≈60sAnswers: "what was this, and what did you own?" Read four rows, not all eight. Next: why it mattered.
02 · The problem

An operational problem before a UI one.

Fragmentation across eight systems created four distinct kinds of risk.

Customer pain

  • No shared view of a request
  • Sales chasing status by email
  • Re-keying data across systems
  • Blockers surfaced late

Business impact

  • Delays hold up revenue
  • A spreadsheet as point of failure
  • Knowledge in people, not systems
  • Inconsistent status erodes trust

Operational

  • Eight systems, each a fragment
  • Parallel work, hidden dependencies
  • Ownership gaps in hand-offs
  • Different status per system

Compliance risk

  • Decisions must be defensible
  • Audit rebuilt after the fact
  • Approvals hard to evidence
  • Traceability left to memory
0
Downstream systems, each owning a fragment
0+
Status taxonomies for one onboarding event
0+
Ops sub-teams with different definitions of "mine"
0
Load-bearing spreadsheet running the operation
Before
Work spread across everything.
No shared owner
to
After
One lifecycle, in order.
01Sales initiation
02CST & Operations
03Downstream workflows, in parallel
04Ready to Trade, audit in place
Status & ownership visible
≈75sAnswers: "did you understand the business, not just the screen?" The before/after is the hook. Next: the org it lived in.
03 · Enterprise ecosystem

Many teams, one shared record.

Every team owns a different decision on the same record. Their needs conflict, and that is where the work lived.

Upstream
Client
Request
Sales
Initiate
Client Service
Coordinate
One shared onboarding record
Single data model · role-based views · audit trail
Downstream, in parallel
KYC & Compliance
Verify & clear
Credit
Approve exposure
Legal
Agreements
Operations
Account setup
Trading Desk
Enable
Tax
Classify

What the platform had to coordinate

01
Roles & permissions
Access scoped to each team's mandate over a shared record.
02
Workflow states
One lifecycle vocabulary every system's status maps into.
03
Downstream systems
Eight systems coordinated through a translation layer, not replaced.
04
Dependencies & approvals
Parallel workflows with explicit, visible blockers.
05
Audit trail
Every state change captured on the record as a by-product.
≈90sAnswers: "can you hold enterprise systems complexity?" This is the systems-thinking centrepiece. Next: how I learned it.
04 · Discovery

What I saw became what I built.

Three weeks of shadowing and workflow mapping, turned into design through one frame.

Where does a request actually stall?
Shadowing ops leads
Work went quiet in the hand-offs, not inside systems.
The gaps between systems were the real product.
One shared lifecycle, not another dashboard.
Why is intake so heavy for Sales?
Shadowing + workflow mapping
A missing field blocked the whole request.
Most fields were needed later, by other teams.
Progressive disclosure at intake.
Why can't teams agree on status?
Alignment sessions
One event read three ways across systems.
Teams needed one vocabulary, detail on demand.
Plain-language lifecycle stages.
How is onboarding evidenced for audit?
Mapping + compliance alignment
Audit was rebuilt after the fact from email.
Traceability had to be a property of the workflow.
Capture every state change on the record.
≈75sAnswers: "how do you turn research into decisions?" Walk one row fully, gesture at the rest. Next: the model it produced.
05 · Workflow understanding

One lifecycle, four stages, many owners.

The model the whole product sits on. Parallel where the work is parallel, with one clear end state.

Sequential stage Parallel workflow End state
01
Sales Initiation
Sales
Request createdMinimal intake. Enters the lifecycle.
02
CST & Ops
CST · Operations
ValidateGaps returned to Sales.
RouteWorkflows opened.
03
Downstream Workflows
Multiple ops teams
Run in parallel
KYC / AML
Credit
Legal
Accounts
Trading
Tax
04
Ready to Trade
Trading desk
Client cleared✓ Audit record in place
≈60sAnswers: "can you make complexity legible?" Trace one request left to right. Next: the hard calls behind it.
06 · Critical design decisions

The choices I would defend in any review.

Collapsed, each is a headline and result. Open one to see the constraints, options, and trade-off.

01

Minimal intake, deferred detail

~40% fewer intake fields (directional)
Problem
Intake required data Sales did not have and Operations did not need yet. One missing field blocked the request.
Constraints
Regulated intake; downstream teams genuinely depend on complete data.
Options
Collect everything upfront · minimal intake with progressive disclosure · long phased forms.
Trade-off
Downstream teams lose upfront completeness. Built the follow-up tooling they needed instead.
Decision
Minimal intake, every other field deferred to the stage that needs it.
Outcome
Directional: roughly 40% fewer required intake fields; a faster path into the lifecycle.
02

A shared lifecycle vocabulary

One model across eight statuses
Problem
The same onboarding read as "in review," "pending docs," and "blocked" across systems.
Constraints
Eight systems each own a status; compliance needs precision, Sales needs simplicity.
Options
Expose every system status · one plain-language model · a hybrid by role.
Trade-off
Plain status can hide fidelity. The full system trace is one click away, not the default.
Decision
Plain-language lifecycle stages, with system detail on demand.
Outcome
Observed: the lifecycle became the shared language teams used.
03

Role-based views over one model

12+ teams, one lifecycle underneath
Problem
Each operations sub-team had its own definition of "this onboarding is mine."
Constraints
One shared data model, limited build time, no appetite for training.
Options
A dashboard per team · role-aware views on one model · fully custom per user.
Trade-off
Less bespoke than a per-team build, but it adopts without training.
Decision
Role-aware default views and saved queries over a single record.
Outcome
Observed: each team sees its slice while the lifecycle stays universal.
04

Audit trail as a first-class object

Prep cut from weeks to minutes (directional)
Problem
Audit was a quarterly export. By the time something needed defending, the trail was gone.
Constraints
Regulated and auditable, but the operator must not drown in noise.
Options
Quarterly export · reports generated later · capture continuously on the record.
Trade-off
Capturing everything risks noise. The activity feed is collapsible and role-filtered.
Decision
Every state change captured against the record, queryable in place.
Outcome
Directional: compliance reviews the record instead of commissioning a report.
05

Parallel workflows, visible end state

Readiness is shown, not inferred
Problem
KYC, credit, legal, account, trading, and tax setup run at once, with hidden dependencies.
Constraints
Downstream systems owned by other teams; the work is genuinely parallel.
Options
Force a strict sequence · model true parallelism · silo each system.
Trade-off
Parallelism is harder to represent. Solved with per-line progress and one end state.
Decision
Parallel product workflows gated by a deliberate Ready-to-Trade milestone.
Outcome
Observed: operators see exactly which dependency blocks which product.
≈2mAnswers: "can you make senior product decisions?" This is the anchor. Show 01 and 04; open others only when she challenges. Next: how they show up.
07 · Solution

Why the product looks the way it does.

Recreated views, client data removed. Open the reasoning under any screen.

View 01 · Operations dashboard

Every onboarding in flight, on one surface.

Status, ownership, blockers, and pending actions across every team, replacing the email-and-spreadsheet tracking.

Why this screen
Problem
No shared view of in-flight onboardings.
Interaction
Status, owner, and time-in-stage as sortable columns; blockers flagged.
Accessibility
Status shown as label plus icon, not colour alone; keyboard-navigable table.
Developer
Built on the enterprise design-system table and filter components.
Edge cases
Blocked, returned, and duplicate records surface rather than hide.
Business
Replaces spreadsheet tracking and makes delays visible early.
onboarding.rbccm.internal
Dashboard listing onboarding requests with columns for status, owner, current step, and time in stage
Operations dashboard
images/dashboard.png
View 02 · Client intake · Stage 01

Minimal intake, oriented context.

Captures the minimum to route a request, while making downstream ownership and pending items visible from step one.

Why this screen
Problem
Heavy intake blocked requests over fields Sales lacked.
Interaction
Few required fields; a running context panel keeps the operator oriented.
Accessibility
Clear labels, sensible focus order, progress communicated per step.
Developer
Reused form and stepper patterns; validation deferred by stage.
Edge cases
Missing data returns to Sales without losing the request.
Business
Faster path into the lifecycle; ~40% fewer required fields (directional).
Multi-step client intake form with a running summary panel on the right
Intake stepper
images/intake.png
View 03 · Products stage · Stage 03

Where parallel workflows converge.

Per product line (KYC, credit, agreements, account, trading, tax), so operators see which dependency blocks which product.

Why this screen
Problem
Hidden dependencies across parallel product workflows.
Interaction
Per-product trackers show which dependency blocks which line.
Accessibility
State conveyed by label and shape, not colour alone.
Developer
Status pattern variants drawn from the design system.
Edge cases
Partial readiness: one product blocked while others proceed.
Business
Operators act on the specific blocker, not the whole request.
Products stage showing per-product workflow trackers and a request timeline
Products stage
images/products.png
One record SalesOperationsComplianceLeadership

Select a role to see the same record through its lens.

Initiate & track

Initiate without translating.

  • Fast intake, minimal required fields
  • Status in plain language
  • Clear ownership of what sales still owes
  • No downstream system mechanics
≈90sAnswers: "why does the UI look this way?" Open one screen's reasoning if she probes a11y or edge cases. Next: how I think in systems.
08 · Design system thinking

Beyond screens, into patterns.

Built on RBC's enterprise design system, extended only where the workflow needed something new.

Reused

The system's foundation

  • Tables, filters, forms, and navigation components
  • The system's tokens, spacing scale, and typography
  • Its accessible defaults, inherited with the components
Contributed

New patterns it lacked

  • The lifecycle status pattern and its state variants
  • Role-based views over a shared data model
  • The audit activity feed, collapsible and role-filtered
Pattern · lifecycle status

One status pattern, four states, communicated by shape and label as well as colour, so it never depends on colour alone.

≈60sAnswers: "do you think beyond a single screen?" The colour-independent states show craft. Next: how alignment happened.
09 · Collaboration

Alignment was the design work.

In a regulated, multi-team operation, most of the leverage was in agreement, not pixels.

Product
Co-owned scope and the lifecycle model.
Engineering
Feasibility, edge cases, the translation layer.
Compliance & Legal
Regulated flows, audit, defensible decisions.
Operations
The real workflow, validated against daily work.
Credit
Exposure and approval steps in the lifecycle.
Leadership
Portfolio oversight and rollout sponsorship.
QA
Defect triage and prioritization through delivery.
UAT
Planned and run with the teams who would live in it.

Where we disagreed, and how it resolved

Intake: everything upfront, or not?
Tension

Downstream teams wanted Sales to collect every field at intake. Sales could not, and it blocked requests.

Resolution

Progressive disclosure, plus follow-up tooling so downstream teams could request detail at the right stage.

Views: one per team, or one model?
Tension

Each team wanted its own dashboard, which would fragment the data and slip the timeline.

Resolution

Role-based views over one shared model: each team gets its slice, the record stays single.

I owned

Discovery, lifecycle mapping, IA, interaction design, the tradeoffs, design-side UAT and rollout.

I co-created

The model and scope with PM and BAs; feasibility with engineering; regulated flows with compliance and legal.

Others led

PM owned delivery; engineering and QA owned build and testing; compliance, credit, and legal owned the decisions.

≈75sAnswers: "can you align stakeholders and handle disagreement?" Tell the intake tension as a short story. Next: what changed.
10 · Business impact

Outcomes, not outputs.

One lifecycle surface
Shared status · ownership · audit
Ready to Trade
Audit in place
Scope
0
Downstream workflows on one lifecycle view
Directional
~0%
Reduction in mandatory intake fields
Adoption
0+
Operations teams aligned, rollout continuing

Teams retired their spreadsheets. The clearest signal the product was working.

Sales stopped emailing "where is this." Status lives where they work.

Telemetry was instrumented after launch, so quantitative figures are directional estimates or adoption signals, labeled as such.

≈60sAnswers: "outcomes, not outputs, and are you honest about evidence?" Lead with the retired spreadsheets. Next: what I learned, and where AI fits.
11 · Reflection

What I'd change, and where this goes next.

Do differently today

Ship instrumentation with the product.

Some numbers are directional because telemetry came after launch. Measurement should launch with it.

How it changed me

Design the operating model, not the screen.

In enterprise work the model everyone agrees on outlives any single interface.

How AI would improve this workflow · forward-looking, not shipped

Future concept · the RBC platform used no AI
Why it transfers: the workflow already keeps humans in control visible statusexplicit ownershiphuman-owned decisionsaudit by default

Future opportunities

Summarize status & blockers Recommend the next action Detect incomplete information Explain why a case is blocked
Ground rule. Regulated decisions stay human-owned. AI would accelerate the work around them, with grounding, a confidence signal, an override, and a safe fallback to the record.
≈90sAnswers: "are you still growing, and do you understand AI?" Land the human-in-the-loop point: this is why the work is AI-ready. Then stop and invite questions.
12 · Takeaways

If you remember four things.

01

I designed a coordinated operating model, not a screen.

02

Eight systems became one lifecycle with visible status and ownership.

03

Humans stayed in control of every regulated decision.

04

Audit became a property of the workflow, not a later report.

≈20sClose on line 03 for a Thomson Reuters room. Then: "I'd love to take your questions."