Chronosphere - Design System
History
When I first joined the Chronosphere team, there wasn’t a design system. The company had partnered with a design agency to establish basic colors and font styles however much of the product design was led by the engineers. Chronosphere used Material UI as a base and had modified many of the styles.
At the time, there were only two designers - my manager and I. As we started to create a more user-friendly design, it was easy to quickly collaborate on basic component styles (buttons, selects, icons).
The design team grew from two designers to 14 in less than a year and very quickly we recognized the need for a design system. The product no longer looked cohesive so I worked to establish components, documentation, and patterns.
Research
User Interviews
To create a usable library, I first needed to understand the team. I interviewed the UX designers and front-end engineers to better understand their processes. I needed to know how the current components were being made, what issues the teams were encountering and also asked if there were any previous libraries we could imitate.
Throughout my research, I also identified many problems with our current system, or lack thereof, those problems are highlighted below:
Inconsistency
Inconsistencies within single systems and between other systems lead to longer learning curves for the users.
Version Control
Designers and engineers cannot identify which components/patterns to use.
Code Waste
Engineers are missing/don’t have specs for components and often build things from scratch.
Accessibility
Although the product was mostly accessible, there are no standards or checks to ensure it maintains accessibility.
Process
Building a team
To successfully build a design library, I needed a team of designers and engineers. These people would help build the library but also work as advocates for the new library. The component library was not a dedicated work stream at Chronosphere but rather a “20% project.” I asked for volunteers to dedicate a few hours each week to building a better system.
On the design side, I assigned designers components based on their skillset, interests, bandwith, and the context of the component. If the designer was working on a team that desperately needed a specific component, it made sense for them to work on it.
Audit Components
Once the team was established, we audited all the existing components in the product. We printed our existing flows and identified each component. We then tracked how often the component was used and sorted components from global to specific. As we audited, we made sure to mark any inconsistencies or blatant areas of concern.
Design
Building a component
Step 1: Evaluation
When we build a new component, we not only look at Material UI’s documentation but also evaluate competitors to understand how they have tackled similar challenges. When we test competitors, we look for what they are doing right as well as what we can improve upon.
Step 2: Brainstorm
We led many design workshops to brainstorm ideas for the components. The following topics were usually the foundation of our discussions:
Usages current needed in the product
Future usages based on competitive analysis and best practices
Dependencies
Elements within a component
Modifiers.
Step 3: Design Phase
When designing a new component, I challenged designers to think through as many iterations as possible. We wanted to think through all the variations and edge cases as well as test the component next to other components in a pattern. Design also included thinking about accessibility.
During this phase, it was common for the designers to pair with the engineers to ensure the designs were feasible.
Step 4: Prototype & Test
With most of the criteria in place, we prototyped and tested the components in Figma to ensure the component was usable.
Step 5: Adding component to the UI Kit
The final design was added to the Chronosphere Design Library Figma file so it could be easily accessed and used by the designers. The file not only included the component but also basic documentation and standard use cases.
The design library team communicated updates and changes to this file in a weekly newsletter.
Step 6: Adding component to the living style guide
On the engineering side, the component would be built by the front-end team and added to our Storybook library. We ensured that the naming structure in both Figma and Storybook matched for consistency.