Strategic Architecture: A Scalable Framework for RBC

A Proof of Concept for managing enterprise legacy data through modern token architecture.

The Observation

While working within RBC’s massive digital ecosystem, I observed a common friction point typical of large enterprises: the disconnect between Design Intent and Developer Implementation.

RBC’s digital ecosystem had subtle inconsistencies: buttons styled differently across teams, inputs with varied error handling, and multiple shades of “RBC Blue.” These weren’t cosmetic quirks, they slowed collaboration and eroded trust.

While working within RBC’s massive digital ecosystem, I observed a common friction point typical of large enterprises: the disconnect between Design Intent and Developer Implementation.

Asking the Hard Questions

Why are teams diverging from the brand?
How do we reduce “enterprise drag” caused by legacy libraries?
How can accessibility be enforced at the system level, not left to chance?

This reframing turned the project into a story about alignment and trust, not just pixels. I developed this architectural framework to demonstrate how a 3-Tier Token System could solve this "operational drag," focusing on automation, accessibility, and multi-brand scalability.

My Role

Strategic Architect (Concept & Implementation). To prove how modern tokenization can reduce technical debt in legacy environments.

Decoupling Context from Value

To move beyond anecdotes and prove the problem was universal, I led a cross Canada discovery phase, synthesizing feedback from 15 advisors across five regions through in-depth interviews and contextual observation.

The Approach

If it were up to me to re-platform our system, I would move away from flat styles. I built this prototype using a 3-Tier Token Architecture to demonstrate the value of abstraction.

Tier 1: Primitives (The Raw Materials)

Defined the core RBC palette (e.g., rbc-blue-900: #0051A5)
Why: This creates a single source of truth for the brand.

Tier 2: Semantic (The Intent)

Mapped primitives to intent (e.g., action.primary.background references rbc-blue-900).
Insight: This layer is where the "magic" happens. It allows us to support sub-brands (like Dominion Securities) by simply re-pointing the aliases, without breaking the component code.

Tier 3: Component (The Object)

Assign tokens to objects. (e.g., button.primary.fill)

This 3‑tier architecture abstracts brand values into scalable frameworks.

Components That Solve Real Problems

I focused on a handful of components to illustrate the approach:

Buttons: Clear hierarchy reduces ambiguity.
Inputs: Input states and helper text improve clarity.
Checkboxes & Radios: Keyboard navigation ensures inclusivity.
Tab Bar: Allows users to switch context of the page easily.
Progress bar: Reassures users during long tasks.

Compliance by Default

In banking, accessibility is a legal requirement, not a "nice to have". Even “small” uses of color like accents or tertiary states must pass WCAG AA

The Gap: Designers naturally reached for white text on RBC’s brand yellow (#FFBA00) — whether for badges, tags, status indicators, or tertiary buttons. While visually intuitive, this pairing fails WCAG AA contrast (3.8:1), creating compliance risk and user confusion.
My Solution: I treated this as a systemic constraint, not a visual preference. I identified #252525 (black) as the only text color that passed WCAG AA on #FFBA00. I then defined semantic tokens in Figma:
color-accent = #FFBA00
text-on-accent = #252525
The Guardrail: While Figma can’t auto-swap colors, I enforced compliance through design system governance: component variants only expose the compliant pairing, documentation explicitly prohibits white text, and onboarding materials frame this as a non-negotiable rule. The system doesn’t suggest it requires.

Engineering for Flexibility

The Build: To demonstrate efficiency and scalability, I architected the core input and card components using Nested Instances and an Atomic Design framework, leveraging Figma’s Instance Swap properties to create flexible, maintainable systems.

Old Way: Building monolithic components from scratch for every variation — e.g., “Card with Image,” “Input with Icon,” “Button with Badge.” No reuse, high maintenance, brittle at scale.
My Way: A modular system built on Atoms → Molecules → Organisms:
- Atoms: Reusable base elements (Label, Field, Icon, Hint Text).
- Molecules: Composed components (Input = Label + Field; Card Header = Title + Icon).
- Organisms: Complex containers (Card = Header + Body + Action) with nested instances that inherit and expose parent properties.
- Flexibility: Need an icon? Swap it in. Need hint text? Toggle it via instance property. All without breaking the component.
Why it matters: For an enterprise with thousands of files, this reduces library bloat and maintenance burden. It proves we can give product teams granular control without sacrificing consistency or scalability.

Governance: The Publishing Workflow

The Operational Model: A system is only as good as its maintenance. I structured this PoC to follow a strict Semantic Versioning model (v1.0.0).

Strategy: "Breaking changes" (like removing a token) are batched into major updates, while "Non-breaking" (like tweaking a hex value) are minor patches.
Value: This gives product teams the confidence to update their libraries without fear of their layouts breaking a critical factor for internal adoption.

What This Says About Me

This case study isn’t about me building a system alone. It’s about how I would:

Spot cracks in consistency.
Frame problems in human and organizational terms.
Lead with scalable frameworks (tokens, slot architecture, governance).
Design with empathy and foresight.

About Me

Strategic Architecture: A Scalable Framework for RBC