Role:
design system manager
component architect
engineering liaison
workshop facilitator
Outcomes:
launched v2 of Corvus Design System
refactored all design components to be responsive and follow auto-layout
delivered on design-team initiative to make component documentation accessible across the tech org
I managed the Corvus Design System as one of my core responsibilities at Corvus.
It was as much about managing the system as it was managing collaboration.
When I joined Corvus, CDS (Corvus Design System) was in its first iteration of maturity. As the team grew from three 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.
Change management and planning
I put together a 12-month plan for the entire team to rally around.
The project was broken down into three phases, many parts 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.
I revised this 12-month plan with the head of product design a few times, and then socialized it with the rest of the design team.
Discovery and research
During the 4-week discovery and research phase, I took the design team through weekly workshops to align our vision on what we wanted to do 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.
We took the most effective and logical elements from these established frameworks to reconstruct the foundations of our own, ensuring it would be both informed by best practices and tailored to our unique requirements.
A shortlist of design systems that felt the most relevant for us - ones that aligned with our organization's scale, design system maturity level, and component use cases - would go on to serve as guides and a reference point during our ongoing work on the system.
1.
To establish a clear, logical structure for how we communicate purpose, concepts, and usage of CDS
2.
To assess gaps in the system
3.
To address redundancies in the system
Next I restructured the foundations of CDS from its previous iteration, with a few goals in mind.
I had designers pair up to tackle specific sections of CDS as we moved through documentation.
We created a documentation structure that we felt contained essential guidance for designers.
The litmus test was - "if a new designer joined today, would they be able to look at this doc. and understand how to best use the component within our application?"
I spent time teaching junior designers about design tokens.
I felt that improving their system literacy would help strengthen their mental model of CDS.
It would also serve as an early touchpoint between design and engineering.
Our evaluation revealed that the naming system of our SASS variables was inconsistent - a mixture of semantic and literal naming, as well as the usage of modifier-first naming (value-property) instead of property-first naming (property-value).
I then worked with engineering leads to revise the naming conventions to property-first for scalability, discoverability, and an overall better mental model for SASS variables.
>
Example: naming changed to be more modular, scalable, discoverable
Finally, the revised SASS variables were centralized on zeroheight to establish a single source of truth.
We took a deep-dive into naming conventions for our SASS variables (tokens).
I refactored the architecture for all of the Figma components in the system.
(Because why should anything not following auto-layout?)
I also took on the task of modernizing the component library by implementing auto-layout properties, often having to recreate them from scratch.
I also implemented Figma variables (late 2023) 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, but it also drastically improved the usability of Figma components in day-to-day work.
It also made our architecture more consistent and established a distinct philosophy for how we build components in Figma at the organization.
After several reviews with the engineering team, the above became our go-to model for design component hand-off.
I worked closely with senior engineers to develop a hand-off process between design and engineering.
We aimed to make sure we were "speaking in the same language".
We also took the opportunity to work out our ideal tech-stack.
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
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
