The strategy: An open source design system as a product
Canonical
Design systems
Leading the transformation of Canonical's design system into an open-source product that empowers technical audiences to create high-quality, cohesive experiences.
The previous design system, Vanilla, had been built primarily as a CSS library and pre-dated the rise of design systems as collaborative tools between designers and developers. By the time this project began, the system remained largely engineering-led and was primarily documented for an engineering audience — with little to no design documentation.
These documentation gaps were significant. The system relied heavily on the tacit knowledge of the team, which led to inconsistencies as individuals made ad hoc changes or diverged from the system entirely. This exposed both a lack of flexibility in the system and an absence of documented best practices to guide contributions.
From a design perspective, the project had been under-resourced from the outset. The lack of a clear governance structure and participation mechanisms further discouraged meaningful contributions. Ideas that were proposed often stalled, simply due to the lack of capacity to develop them.
To lay solid foundations for the future of the design system, we first needed to address these fundamental issues and create a shared strategy that the whole team could align behind.
Open source projects building polished, corporate-grade technical systems
What do we offer? Our operational pillars
To demonstrate how we began putting our strategy into action, here are some examples of tools we identified as having the highest impact for our teams. These tools were key to proving the value of a design system to our stakeholders, with the ultimate goal of securing better resourcing in the future.
- Component Status: One of the first tools we developed was a component map. This map linked to the existing sources of truth for design, documentation, and code, helping us understand the current state of our system. We also evaluated the completeness of each component and included a backlog of ideas for future improvements or additions in upcoming roadmaps.
- Figma Libraries: To drive consistency and make our designers' work more efficient, we focused on creating new Figma libraries that followed industry best practices. These libraries were trackable, allowing us to monitor usage and measure adoption across teams. We first developed a plan for structuring and implementing these libraries, then worked on our core library, which included the majority of components used by all teams.
- Minimal Documentation: Addressing the initial documentation deficit, we created a template for providing minimal documentation for our design building blocks and key decisions. This template also served as a decision log, recording the rationale behind choices made by the team and ensuring consistency in the future.
- Design Tokens: One of the most significant advancements in managing our design system has been the adoption of design tokens. These allow us to systematise our brand values in a way that supports scalability and provides insight into the impact of changing brand values in the future. We began by defining a general approach to tokens, then moved on to implementing a system of primitive and semantic tokens for our colour palette.
Other design systems work
Daniel Mutis
All Rights Reserved
The strategy: An open source design system as a product
Canonical
Design systems
Leading the transformation of Canonical's design system into an open-source product that empowers technical audiences to create high-quality, cohesive experiences.
By April 2023, the design team at Canonical had been operating for over a year without a management structure. When a new leadership team was appointed, they began to define a clearer direction and vision for the team. Around the same time, one of my colleagues highlighted a critical issue: our web applications were using inconsistent design patterns and different components for similar functions — a direct consequence of the prolonged leadership gap.
Recognising an opportunity to address this fragmentation, Me and two colleagues initiated an effort to bring greater cohesion across Canonical’s portfolio. To test our idea, we dedicated one day a week to explore new components that were better aligned with the needs of our products. We started with a side navigation component, focusing on creating solutions that would lay the groundwork for broader consistency.
Six months later, our progress caught the attention of leadership. I was asked to lead a formal working group of designers, dedicating 20% of our time to rethink our design system strategy. Our mission was to transform our design system into a product in its own right, with a clear vision and purpose.
This case study shares how I led this initiative to shape the vision of our design system and establish the foundational principles that would guide its evolution.
The previous design system, Vanilla, had been built primarily as a CSS library and pre-dated the rise of design systems as collaborative tools between designers and developers. By the time this project began, the system remained largely engineering-led and was primarily documented for an engineering audience — with little to no design documentation.
These documentation gaps were significant. The system relied heavily on the tacit knowledge of the team, which led to inconsistencies as individuals made ad hoc changes or diverged from the system entirely. This exposed both a lack of flexibility in the system and an absence of documented best practices to guide contributions.
From a design perspective, the project had been under-resourced from the outset. The lack of a clear governance structure and participation mechanisms further discouraged meaningful contributions. Ideas that were proposed often stalled, simply due to the lack of capacity to develop them.
To lay solid foundations for the future of the design system, we first needed to address these fundamental issues and create a shared strategy that the whole team could align behind.
Open source projects building polished, corporate-grade technical systems
What do we offer? Our operational pillars
To demonstrate how we began putting our strategy into action, here are some examples of tools we identified as having the highest impact for our teams. These tools were key to proving the value of a design system to our stakeholders, with the ultimate goal of securing better resourcing in the future.
- Component Status: One of the first tools we developed was a component map. This map linked to the existing sources of truth for design, documentation, and code, helping us understand the current state of our system. We also evaluated the completeness of each component and included a backlog of ideas for future improvements or additions in upcoming roadmaps.
- Figma Libraries: To drive consistency and make our designers' work more efficient, we focused on creating new Figma libraries that followed industry best practices. These libraries were trackable, allowing us to monitor usage and measure adoption across teams. We first developed a plan for structuring and implementing these libraries, then worked on our core library, which included the majority of components used by all teams.
- Minimal Documentation: Addressing the initial documentation deficit, we created a template for providing minimal documentation for our design building blocks and key decisions. This template also served as a decision log, recording the rationale behind choices made by the team and ensuring consistency in the future.
- Design Tokens: One of the most significant advancements in managing our design system has been the adoption of design tokens. These allow us to systematise our brand values in a way that supports scalability and provides insight into the impact of changing brand values in the future. We began by defining a general approach to tokens, then moved on to implementing a system of primitive and semantic tokens for our colour palette.
Other design systems work
The strategy: An open source design system as a product
Canonical
Design systems
Leading the transformation of Canonical's design system into an open-source product that empowers technical audiences to create high-quality, cohesive experiences.
By April 2023, the design team at Canonical had been operating for over a year without a management structure. When a new leadership team was appointed, they began to define a clearer direction and vision for the team. Around the same time, one of my colleagues highlighted a critical issue: our web applications were using inconsistent design patterns and different components for similar functions — a direct consequence of the prolonged leadership gap.
Recognising an opportunity to address this fragmentation, Me and two colleagues initiated an effort to bring greater cohesion across Canonical’s portfolio. To test our idea, we dedicated one day a week to explore new components that were better aligned with the needs of our products. We started with a side navigation component, focusing on creating solutions that would lay the groundwork for broader consistency.
Six months later, our progress caught the attention of leadership. I was asked to lead a formal working group of designers, dedicating 20% of our time to rethink our design system strategy. Our mission was to transform our design system into a product in its own right, with a clear vision and purpose.
This case study shares how I led this initiative to shape the vision of our design system and establish the foundational principles that would guide its evolution.
The previous design system, Vanilla, had been built primarily as a CSS library and pre-dated the rise of design systems as collaborative tools between designers and developers. By the time this project began, the system remained largely engineering-led and was primarily documented for an engineering audience — with little to no design documentation.
These documentation gaps were significant. The system relied heavily on the tacit knowledge of the team, which led to inconsistencies as individuals made ad hoc changes or diverged from the system entirely. This exposed both a lack of flexibility in the system and an absence of documented best practices to guide contributions.
From a design perspective, the project had been under-resourced from the outset. The lack of a clear governance structure and participation mechanisms further discouraged meaningful contributions. Ideas that were proposed often stalled, simply due to the lack of capacity to develop them.
To lay solid foundations for the future of the design system, we first needed to address these fundamental issues and create a shared strategy that the whole team could align behind.
Open source projects building polished, corporate-grade technical systems
What do we offer? Our operational pillars
To demonstrate how we began putting our strategy into action, here are some examples of tools we identified as having the highest impact for our teams. These tools were key to proving the value of a design system to our stakeholders, with the ultimate goal of securing better resourcing in the future.
- Component Status: One of the first tools we developed was a component map. This map linked to the existing sources of truth for design, documentation, and code, helping us understand the current state of our system. We also evaluated the completeness of each component and included a backlog of ideas for future improvements or additions in upcoming roadmaps.
- Figma Libraries: To drive consistency and make our designers' work more efficient, we focused on creating new Figma libraries that followed industry best practices. These libraries were trackable, allowing us to monitor usage and measure adoption across teams. We first developed a plan for structuring and implementing these libraries, then worked on our core library, which included the majority of components used by all teams.
- Minimal Documentation: Addressing the initial documentation deficit, we created a template for providing minimal documentation for our design building blocks and key decisions. This template also served as a decision log, recording the rationale behind choices made by the team and ensuring consistency in the future
- Design Tokens: One of the most significant advancements in managing our design system has been the adoption of design tokens. These allow us to systematise our brand values in a way that supports scalability and provides insight into the impact of changing brand values in the future. We began by defining a general approach to tokens, then moved on to implementing a system of primitive and semantic tokens for our colour palette.
Other design systems work