Work / Corvus / 'Design System Management'
In this case study, I reflect on my work of managing the design system (CDS) at Corvus.
When I joined Corvus, CDS (Corvus Design System) was in its first iteration of maturity. As the team grew from two Product Designers to seven, I took on the role of leading the refinement and management of the system to take it to the next level and scale appropriately.
Planning
I ended up breaking the project down into three phases, some concurrent - development, governance, and change management.
As with any long-term project, timelines got moved over the course of the year but the roadmap kept us on track for the most part.
Discovery and research
In the research phase, once a week I led the design team through workshops to discuss what we wanted our design system to be and how we wanted to get there.
Looking at existing systems out in the world also helped us to have meaningful discussions and identify what made sense for our design team.
Foundation development
I restructured the foundations of CDS from its previous version, with a few goals in mind:
To establish a clear, logical structure for how we communicate purpose, concepts and usage of CDS
To assess and address gaps and redundancies
To provide an easy structure for delegation of work to be completed in smaller groups
Resources were reallocated as necessary, as we moved through sections of CDS
The team worked to create a documentation structure that we felt was essential and useful at a glance.
Example: component documentation
A rough documentation structure was created for each foundational element of CDS.
During the design system workshops, I also spent time educating designers on the concept of Design Tokens and what our organization was using in place (SASS Variables). We audited the existing ones and applied best practices to naming conventions.
A rough documentation structure was created for each foundational element of CDS.
I then worked with the engineering lead to revise the SASS variable naming conventions for flexibility and scalability - previously, the names did not follow a 'generic-to-specific' convention.
>
Ex: naming changed to be more modular, scalable, discoverable
I then worked with engineering to centralize the SASS variables, establishing a 'single source of truth' on zeroheight.
Component modernization
I also took on the task of modernizing our legacy component library by implementing auto-layout properties and implementing Figma variables (where it made sense). This update involved analyzing over 60 existing components and establishing a consistent layout hierarchy, refactoring each component and its variants to respond to auto-layout behaviors.
This resulted in a more maintainable, flexible design system that also improved consistency in our component architecture, while establishing a distinct philosophy for how we build components in Figma.
Hand-off model
I worked closely with senior engineers to develop a hand-off process between Design and Engineering. To put it simply, we aimed to make sure we were "speaking in the same language" when it came to hand-off, and working out what tech-stack we felt would work best.
An integrated documentation system
A dual-platform documentation approach
The result of these efforts was an integrated documentation approach, delivering significant improvements to design system adoption and utilization across the organization. By implementing documentation directly within Figma alongside components, while maintaining a parallel documentation system in zeroheight, we addressed the unique needs of the design team as well as the broader organization.
Figma documentation: designer-centric
Figma documentation was placed adjacent to components, providing designers with immediate access to usage guidelines without leaving their workflow or exploration of the component architecture. This documentation was specifically tailored to designers' needs, including:
Description of design intent
Usage guidelines, do's and don'ts
Usage examples (actual examples in CrowBar)
Variants and properties
Auto-layout considerations
Any Figma-specific implementation notes
Documentation within Figma
zeroheight Documentation: Organization-Wide Resource
I also mirrored this documentation in zeroheight for the entire organization, intended to be more accessible to non-designers. The documentation here provided:
Higher-level component overviews
Implementation principles across platforms
Developer hand-off guidance
Real-world application examples
Usage guidelines, do's and don'ts
Results, reflections
As much as I'd love to be able to rattle off efficiency gains and hard metrics around the adoption of CDS, the truth is that the majority of the design team (including myself) was laid off shortly after the acquisition of Corvus and this project came to an abrupt halt.
With that said, leading and managing the redevelopment of the design system was probably one of my favorite projects during my time at Corvus. Primarily, it gave me a chance to open a dialogue with engineering counterparts about how we can better communicate with each other, a practice that is often under-exercised.
Internally with the design team, it gave us a chance to get on the same page on many aspects - from our shared knowledge about the system, to consideration and application of the newest developments in Figma, as well as our design philosophy as it relates to the system that we continued to build upon.
And if I were still at Corvus managing the design system, I would look to these metrics:
% change in component usage over time (via Figma Library Analytics)
% change in component usage frequency
% reduction in component detachments
user satisfaction ratings (likert scale)