Creating Winterview's Design System
Winterview is a dynamic SaaS startup offering B2B services to universities and higher education institutions, while also serving B2C users, notably students aiming for their dream careers. The Winterview platform provides AI-driven resume enhancements, networking assistance, and interview preparation, equipping students for success in the job market. Winterview is currently in a closed alpha.
As a Product Designer, I quickly identified and addressed significant inconsistencies in our Figma file. Over two months, I developed a robust design system, introducing clear components, a unified design language, and auto layout, along with detailed annotated mockups for developer handoff. This initiative reduced development times by 25% and greatly reduced time-consuming design-developer discussions by 70%, enhancing team efficiency and collaboration.
The information in this case study is my own and does not necessarily reflect the views of Winterview.
Problem & Insights
Lack of standardization leads to lengthy design and development times
The previous Figma file had numerous inconsistencies, increasing my workload by approximately 25% during feature reiterations or improvements. Unnoticed discrepancies often resulted in extra design-developer meetings, consuming valuable sprint time. On average, it took about 3.73 sprints to complete a larger feature release.
For example, discrepancies included issues such as:
For example, discrepancies included issues such as:
1. Similar components were created entirely different from their frames, padding, and spacing
Notice the differences in padding (24px vs 12px horizontal padding) on the same type of component and the difference in spacing (24px vs 8px) between search bars and filters.
2. Components were detached for no apparent reason or built poorly which required them to be detached rather than using interchangeable nested components.
The table and rows are components, but individual table cells are not, which means changing a single cell requires detaching the table and row components. This leads to inconsistencies, as detached components don't update with their parent components.
Internal Research
Avoidable meetings that disrupt workflow
Issues with our current Figma file were not only limited to the design team. After conducting some brief, informal research with our developer team, this is what I found:
Our Goal
Design Principle: From Second Guessing to Standardized Rules and Flexible Components
As a design system, we want clear, universally applied rules across all product features, maintaining flexibility for component modifications without detaching them from the parent component. This balances consistency and adaptability, reducing developer confusion. When needed, standardization takes precedence over flexibility, and we will add new components as required.
Major Change #1
Standardized CSS Rules with Documentation
Rather than inconsistent spacing in multiples of 8, I implemented spacing rules for different circumstances. For example, between subheadings and titles, spacing was always 8px. I also established font usage guidelines, complete with examples in the documentation, and applied similar rules for colors, grids, and containers, including padding and corners.
.png)
Spacing rule demonstration (left) with annotations to clarify and font usage demonstration (right)
Major Change #2
Component Documentation and Use Cases
Previously, components were categorized by type without any documentation. I introduced documentation detailing use cases, CSS, and variants (states) for each component, focusing on those most frequently used to eliminate any ambiguity about their application.
Component documentation (left) and use case documentation (right)
Major Change #3
Nested components for consistency and flexibility
I changed the structure of tables, making individual cells the primary "building block" component instead of rows. This allows for easy swapping of cells, like replacing a "Text" cell with a "Text + Icon" or a "Pill Tag" cell, without detaching any components.
Additionally, I implemented nested components within table cells. For instance, in a "Text + Icon" cell, I can seamlessly switch the icon from a dropdown to a search bar icon, maintaining consistency without detaching components.
Additionally, I implemented nested components within table cells. For instance, in a "Text + Icon" cell, I can seamlessly switch the icon from a dropdown to a search bar icon, maintaining consistency without detaching components.
Demonstration for how tables are now constructed (left) and variant swap demonstration (right)
Results
25% Reduction in Development Times & 70% Reduction in Design-Development Meetings
After an initial adjustment period, which included a few workshops, both developers and the design team adapted quite swiftly to the new system. Within three months of implementing these changes, Winterview experienced a 25% reduction in development times and a 70% decrease in design-development meetings.
Things to Try Next Time & Reflections
While the project was a huge success, here are some things that I learned and would like to try next time:
1. Don't hesitate to request resources for a project: Initially, I delayed seeking approval for this project, unsure of it being accepted due to the required two-month design effort and subsequent adjustment period for developers. Implementing it earlier would have offset the effort with time savings. By waiting several months after joining to raise this issue, I spent unnecessary time correcting inconsistent mockups and clarifying avoidable issues with developers.
2. A design system is more than just a component library: While it's common to equate design systems with component libraries, this project taught me that they also include documentation, spacing rules, and guidelines for appropriate component usage. Proper documentation is crucial, especially for onboarding new product designers and developer handoff.