Questrade Design System
At Questrade, I was responsible for driving the evolution of AllSpark — the company’s unified design system — by leading multiple key fronts.
While I was responsible for defining the vision and execution strategy, this was far from a solo effort. AllSpark was the result of deep collaboration with an incredible group of designers, engineers, and product people — a team that truly believed in building tools to make everyone’s work better, faster, and more aligned.
Our goal was to build more than a component library — we wanted to deliver a reliable ecosystem where designers and developers could trust what they were using, iterate quickly, and focus on solving user problems instead of reinventing UI patterns.
The Challenge
As Questrade’s product teams grew, so did the complexity of maintaining consistent experiences. We had solid designers and engineers doing great work — but in silos, without a shared source of truth.
There were repeated questions like:
“Do we have a dropdown already, or should I build one?”
“Which text style is correct for this?”
“Can I detach this component and make a small change?”
These friction points were small in isolation but added up — leading to inconsistent UI, slower handoffs, duplicated design effort, and even misalignment in shipped experiences.
The challenge wasn’t just to organize what we already had — it was to build a system that people would want to use. One that was flexible but structured. Precise, but never rigid. And above all, approachable and reliable across different teams, contexts, and timelines.
My Role
As the Design System Lead, I was responsible for defining, organizing, and driving AllSpark forward. But it wouldn’t have been possible without the support and input of the talented team I worked alongside — who helped shape the system through feedback, code contributions, and ongoing collaboration.
Here’s how I contributed:
• Strategic Direction — Defined the vision, priorities, and evolution roadmap of the system in alignment with design and product leadership.
• Component Architecture — Led the design of reusable, flexible, and accessible components in Figma, balancing consistency with team-specific needs.
• Cross-functional Collaboration — Worked closely with developers to ensure design matched implementation, closed behavior gaps, and avoided duplicated logic.
• Documentation & Onboarding — Created clear, scalable onboarding paths and documentation to empower squads to work autonomously and confidently.
• Governance & Quality — Reviewed contributions, organized audits, and helped resolve ambiguity between teams by clarifying usage rules and design intent.
• System Analytics — Designed a dashboard to monitor usage, identify underused components, and support data-informed improvements.
This role required a mix of craft, systems thinking, and people skills — advocating for clarity and structure while listening and adapting to evolving needs.
Design-Development Workflow
One of our core strengths was the tight alignment between design and development. To ensure smooth collaboration and avoid inconsistencies, we adopted a branching workflow in Figma.
For every new feature, we created a dedicated branch within the design file. This allowed us to work in isolation, without affecting the main design system or ongoing initiatives. Once developers finished implementing the feature, and after syncing with their progress, we merged the branch into the main file—ensuring that what designers saw was always aligned with what was live or in development.
This approach helped us:
Maintain a clean and up-to-date main design file
Avoid redundant or conflicting updates across the team
Stay in sync with the development cycle without slowing down the design process
It was a simple but effective process that brought clarity, reduced rework, and strengthened collaboration between designers and developers.
Component Architecture
Throughout the system, we designed and documented dozens of reusable components, ranging from basic elements (buttons, inputs, checkboxes) to more complex interactions (accordions, banners, steppers, toasts, and chips). Every piece was tested across responsive breakpoints, themes, and accessibility guidelines.
We didn’t just design states — we designed for real-world flexibility. That meant creating options for edge cases, embedded content, layout constraints, and multiple UI densities.
Detailed Documentation
Each component in AllSpark came with comprehensive, multi-layered documentation: from anatomy diagrams and usage rules to interaction behavior and accessibility considerations. Our goal was to eliminate guesswork and foster shared understanding between design and development.
This documentation page for the Accordion component shows our typical structure: what it looks like, how it behaves, when to use it, and common misuse examples. This level of clarity helped reduce inconsistencies across products.
Onboarding designers
A system is only as good as its ability to be understood and adopted. We built a structured documentation site and onboarding experience that made AllSpark easy to explore, search, and apply — especially for new designers joining the team.
This guide walked users through connecting the design library, understanding tokens and theming, and finding the right components for their workflow. It played a key role in reducing friction and support overhead.
I also created async resources like explainer pages, pattern examples, and contribution guides — enabling designers to learn on their own schedule.
Measuring Impact
To understand how the system was performing and where to focus improvements, I built a custom dashboard that tracked key metrics like component usage, detachment rates, and team-by-team engagement.
In just one month, the dashboard recorded 13,000+ component insertions across squads — with very low detachment rates. This confirmed that teams were using the system effectively, trusting the components, and benefiting from the structure we had built.
This data not only demonstrated success — it informed which areas needed refinement, and helped prioritize updates.
Results
By the time AllSpark was fully in use, the system had become a core part of Questrade’s product development process. Some key outcomes:
• A unified, coherent design language adopted across 10+ teams
• Faster handoffs and prototyping, with reduced design–dev friction
• Fewer detaches and duplications in Figma files
• Better accessibility and behavior predictability across platforms
• Clear documentation that reduced dependency on synchronous support
• A strong sense of shared ownership from both design and engineering teams
Wrapping Up
AllSpark has become a trusted part of Questrade’s product development process — and while the system will keep evolving, its core is strong, scalable, and already delivering value every day.