Practical advice for building a system without a team, James Harrison | Evolve Digital Toronto 2026
Summary
James Harrison, Staff Product Designer at Loblaw Digital, shared practical insights from four years of building and maintaining the Helios design system without a dedicated team. At Loblaw Digital, which operates 20 websites, 9 apps, and serves millions of daily users across brands like PC Optimum, Shoppers Drug Mart, and Loblaws grocery, the challenge was creating a cohesive system for diverse businesses with different branding and requirements. The project began in 2022 following rapid COVID-driven growth that strained their platform infrastructure.
Harrison advocated for a design system alongside the company's platforming initiative, despite having limited design systems experience at the time. Rather than forcing alignment across different business units, Harrison adopted a multi-themed approach using design tokens in a headless architecture. This system stores design information centrally and distributes it to both Figma and code, enabling bidirectional updates and eliminating traditional handoff processes.
The token structure separates theme tokens from component tokens, allowing entire experiences to be reskinned by switching themes. Harrison acknowledged that Loblaw operates under a federated model - the most challenging of the three design system governance approaches (centralized, hybrid, and federated). He strongly advised against this approach, citing Nathan Curtis and Spotify as examples of organizations that have moved away from federated systems.
The federated model creates significant challenges including lack of quality control, process ambiguity, unclear ownership, competing mindsets between feature teams and systems thinking, and the tragedy of the commons where maintenance tasks go unaddressed. To address quality control issues, Harrison adopted a permissive approach, allowing components that weren't ideal to enter the system because 'being in the system was more important than what the system was.' This enabled later systematic improvements, such as aligning border radii across all components.
For process ambiguity, Harrison created 'Figma school' and 'dev school' - extensive training modules covering systems thinking, token application, and documentation. Drawing on his decade of college teaching experience, these programs became organizationally required for anyone wanting to contribute to the system. To solve ownership challenges, Harrison recruited passionate volunteers - 'design system curious' individuals who stepped up to become shadow team members.
Hundreds of people have contributed to the system, with key volunteers becoming question-answerers and reviewers, distributing the bottleneck of central oversight. For competing mindsets, Harrison established a steering committee with representatives across the organization to increase system visibility and prevent duplicate work. Looking toward the future, Harrison sees AI as crucial for addressing the tragedy of the commons - the inevitable entropy and debt that accumulates in design systems.
He's exploring using AI to regenerate component libraries, automate migrations, and produce production code directly from design work. Harrison concluded by emphasizing this is not the ideal way to build design systems, but acknowledged that when organizations lack the luxury of dedicated teams, these federated approaches can work 'mostly right' despite the personal toll and complexity involved.
Key Takeaways
- •Federated design systems are extremely difficult to govern and maintain - avoid this approach if possible, as even industry leaders like Spotify have abandoned it
- •When building for multiple brands, skip alignment discussions that block progress and instead create highly themable components using design tokens
- •A headless design system architecture with bidirectional Figma-code sync eliminates traditional handoff processes and enables real-time design changes
- •Sometimes allowing imperfect components into the system is better than having no system at all - you can improve systematically later
- •Extensive training programs are essential when running distributed design systems - create 'design school' modules covering tools, processes, and systems thinking
- •Recruit passionate volunteers from existing teams to become shadow design system team members and distributed governance resources
- •Feature teams and systems teams have fundamentally different goals - feature teams prioritize speed while systems teams prioritize scalability and stability
- •Create steering committees with cross-organizational representatives to increase system visibility and prevent duplicate component work
- •AI tools will become crucial for managing design system entropy, enabling automatic component regeneration and migration workflows
- •Building design systems without dedicated teams creates significant personal and organizational stress but can work when necessary
- •Design tokens should separate theme-level tokens from component-level tokens to enable easy brand switching across entire experiences
Transcript
uh LBLA digital where he leads the Helios design system. So James has spent over a decade working across design from independent magazines to AI powered conversational interfaces. At Lobla Digital, he's been helping build and evolve a design system that's continuing to grow itself over time. So today he'll share practical lessons from building and scaling this design system at Lavla Digital including how to keep running um running this even without a dedicated team which is a challenge. So pleas...
