QUESTRADE design system

Before building new components, we had to understand the "chaos" we were inheriting. I led a comprehensive Component Inventory as the foundational step for Allspark. We didn't just look at Figma; we audited the live products. We mapped out every instance of UI elements to identify inconsistencies.

 

Optimization and Accessibility

 

We focused on building a library that didn't just look good but worked for every Questrade user.

Making All Our Components Accessible: A key priority in developing Allspark was embedding accessibility (a11y) into every design decision from day one. Instead of treating accessibility as a "final check," we built it into the components:

 

• Visual Clarity: We enforced strict color contrast standards (WCAG AA/AAA) and implemented clear, high-visibility focus states.
• Interaction Design: We standardized keyboard interactions and proper ARIA labeling to ensure screen-reader compatibility.
• Cognitive Load: We optimized grid widths and typography scales to improve content legibility and reduce eye strain.

 

CENTRALIZING THE SOURCE OF TRUTH

 

We launched the AllSpark Hub, a unified portal bridging the gap between design and engineering. This ecosystem included:

Live Documentation: Integrated Storybook playgrounds and code snippets.

Theme Builder: A tool to visualize and test systemic changes in real-time.

Strategic Visibility: Public roadmaps and release notes to build trust and transparency.

By transitioning to the Allspark system, we have fundamentally changed how Questrade builds products:

• Unified Brand Identity: For the first time, our digital products share a 100% consistent visual language.
• 30% Faster Deployment: The bridge between design handoff and production has been shortened, allowing teams to focus on feature logic rather than UI styling.
• Engineering Alignment: Developers now reference tokens instead of "guessing" hex codes, leading to cleaner, more maintainable codebases.

Scaling Documentation with Claude and Figma MCP

 

With a token architecture in place, the next challenge was documentation — specifically, keeping it accurate and complete without adding weeks of manual work every time a component changed.

 

I used Claude and Figma MCP together to generate structured documentation directly from the live Figma library. For each component, this covered three areas:

 

Color token mapping: Instead of manually cross-referencing token names with their semantic roles, I used Claude to read component data from Figma and output structured token tables — mapping each property (fill, border, text) to its correct token at every state.

 

Anatomy and structure: For every component, Claude generated anatomy breakdowns describing each layer, its role, and how it connects to the token hierarchy. This gave both designers and developers a shared reference that actually matched what was in Figma.

 

States and interactions: Each component's states — default, hover, focus, disabled, error — were documented with their corresponding token values and interaction notes, ready for handoff without a designer needing to write it by hand.

 

The result was a documentation layer that stayed in sync with the system and reduced the back-and-forth between design and engineering during handoff. What used to take days per component was compressed into a repeatable, consistent process.

 

Component building and iteration: Beyond documentation, I used Claude and Figma MCP to build new components and adjust existing ones directly in Figma. By describing the structure, variants, and token requirements in plain language, I could generate and refine components faster — then review and polish them rather than building from scratch.

 

Token auditing: I ran token audits across the component library using Claude to surface inconsistencies — components using hardcoded values instead of tokens, mismatched semantic roles, or tokens applied to the wrong properties. This turned a tedious manual process into a targeted review, catching gaps that would have slipped through otherwise.

 

Prototyping: I also used AI to build prototypes for new flows and component interactions, shortening the feedback loop between ideation and stakeholder review. Instead of spending time wiring frames, I could focus on validating the right interactions faster.

 

Across all of these, the pattern was the same: AI handled the repetitive and error-prone parts, freeing up time to focus on the decisions that actually required design judgment.