Design system with 500+ components
When I joined, Atmosphere had previously attempted to implement a design system. The project was in an in-between status and the style guide wasn’t working well for designers. My approach was to first understand the company culture, background on the project and to look at the problems at hand.
CompanyAtmosphereYear2024Duration6 monthsRolePrimary design, project lead
Goals
Based on conversations with folks connected to the project, my pitch was simple; 1) refactor the Figma style guide to help wrangle complexity 2) show credibility by moving fast and 3) show cultural alignment by not being too precious with the design system.
Goal
Create a consumable guide
The design system needed to be easily consumable by designers and engineers, in order to help decrease inconsistencies across the Atmosphere platform
Goal
Engineering first
Previous efforts ran into resourcing issues trying to make libraries accommodate bespoke design. To be lean, we needed an engineering foundation the design could adapt to.
Goal
Move fast
In order to get momentum (and resourcing) on a stalled project, we needed to move fast to prove a realistic, workable model
Project phases
We began by deciding on the technology to use, prioritizing familiarity and proven scalability over exploring new possibilities. The choice was driven by what the engineers had successfully worked with before.
Context and decisions
I had to quickly understand the history and politics of the project, the desires of product leadership, and what resources were available from engineering
Consolidation
There was a fair amount of past work. We distilled the core of the Atmosphere brand and took some elements from the previous effort.
Connecting design and engineering
At a tooling-level view, you could also call this the connection between Figma and oZone (more on this soon)
Expanding the vision
With an approach validated, we worked on expanding the scale of the design system to encompass all the elements used in the final destination.
Decisions
Consolidation
Design <> Eng
Expansion
I pushed our team to commit to a library
The development team saw the need for a design system - but knew (from experience) that a from-scratch approach would fail given resource constraints.
After a few conversations with the lead engineer on the project and the director of engineering, we agreed on using Tailwind UI, as the engineers felt it would go fast and work within our existing tech stack.
Decisions
Consolidation
Design <> Eng
Expansion
Running an experiment to mitigate project risk
Using Tailwind required us to adapt our existing UI to better align with Tailwind's capabilities, particularly when implementing more complex structures like tables. This adaptation posed a potential risk.
To mitigate this risk, we conducted a small experiment with Tailwind within oZone, Atmosphere's existing design library. We started by formatting existing colors and typography in Figma, then focused on buttons, one of the foundational elements in any design system.
The team organized elements within Figma, laying out type stacks along visual grids, organizing the hierarchy of the nested element structure and creating Figma text styles that would be accessible and scalable.
Decisions
Consolidation
Design <> Eng
Expansion
Connecting design and engineering
We agreed on the button variables that would make it into oZone. Using a development instance of the product, engineers added buttons to test how the system worked in practice. No surprises, everything went smoothly.
Parity between Figma and oZone
A solid design system needs balance - in this case, where elements within Figma have matching options to what was found inside the team's TailwindUI implementation
Above, the Figma implementation of buttons along with variant options
Above, some of the button options in oZone
Figma variants maintained consistency
Each row element is a variant option. We used this type of approach often while building the Figma side of the design system.
Tyler Pugh
Principal Software Engineer
Team Feedback
We teamed up to create a design system in Figma using the Tailwind library at Atmosphere. This wasn't the first time that Atmosphere had attempted to create a design system, but this was the first one to stick thanks to Jon's tenacity and drive. Jon was awesome to work with. He brought a lot of creativity and organization to the project, making sure everything was well-structured and easy to use. His understanding of both design and Tailwind really made the process smooth.
Decisions
Consolidation
Design <> Eng
Expansion
Expansion
Accessibility and refinement
Making sure elements are accessible is an important part of work. Not only is it helpful for those with severely impaired vision, many people benefit from text contrast that makes content easier to read and comprehend
WCAG Normal Text AA - Fail
It's important to verify that the work we're doing passes basic accessibility guidelines - In this case our initial design failed to meet AA, a contrast ratio of 4.5:1 for normal text (smaller than 14px)
WCAG Normal Text AA - Pass
A slight adjustment resulted in a passing contrast ratio - notice the slightly darker red in the body of the message , the 'Your password' ipsum
Accessibility in the daily workflow
I use a Figma plugin called Adee Comprehensive Accessibility Tool that makes it easy to do fast accessibility checking.
We took existing elements and fused them with TailwindUI's design structure
The Figma portion of the design system evolved much faster than the oZone instance. We wanted to have a backlog of work so engineers could have a consistent flow of work as they worked on completing oZone.
500+
Figma components
40+
oZone components
1500
Lines of code
Project outcomes
We completely refactored the Figma style guide. Our new guidance cut out the noise and gave designers guardrails that made it easier to create consistent UIs.
Mixed
Create usable guiderails
We established a foundation and process for the effort. With more resourcing on the design and engineering side we could have completed the oZone library and created pattern rules for designers
Success
Engineering first
We created a viable collaboration to create and expand a proof of concept within oZone and within our existing product
Miss
Move fast
We weren't able to secure initial resourcing (a design technologist) who could have helped accelerate the move from Figma into oZone (and into the product)
We started with a solid foundation in an existing library, ensuring that future work to put style guide elements into oZone would be low cost. This is a great example of a real project – succeeding in areas within our control, and missing in areas outside of our control. Priorities shift, resources get re-allocated, and you just have to keep moving and do work to a consistently high standard.