Lean design system

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 usable guiderails

The size and complexity of the design system needed to reflect the size of our product org

Goal

Engineering first

Everyone recognized that a viable solution would start foremost in code

Goal

Move fast

A bit of a turnaround situation to arrest and reverse tech and design debt

Project phases

Every project is different (which is why I chafe a little at 'double-diamond' process frameworks). In this case we started with a decision on what technology we'd use. This didn't start with an exploration of possibilities. This really came down to what was familiar and what the engineers had seen scale well.

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

We had to decide first on the technical foundation of the future design system

The development team saw the need for a design system - but knew (from experience) that a from-scratch approach would fail given resource constraints.

The engineers were comfortable with Tailwind UI and felt it had a reasonable chance of working within our existing tech stack.

Decisions

Consolidation

Design <> Eng

Expansion

Putting it all together

Using Tailwind would require adapting our existing UI to more easily fit with Tailwind's capabilities - especially when we got into implementing more complex structures like tables. This created risk.

We decided to head off the risk by doing a small experiment with Tailwind inside of oZone, Atmosphere's existing design library. We formatted existing colors and typography in Figma and got to work on buttons, one of the more 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

We worked to get coverage of all elements within the current product

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. One place we missed was on moving fast. We got great momentum at first, but progress slowed significantly as time progressed. We’ll dig into this in the next section.

Why we missed on speed

Most critically — we had no engineer assigned to the design team. Design system work relied on other product teams with their own roadmaps and tight deadlines to meet. The engineers on the design system project were often diverted to other work, and no one was familiar enough with the design system work to take their place.

A good mitigation strategy would be to assign an engineer to the design team - between the design system and fixes to our customer portal, there would have been plenty of work for this person. When I joined the company we discussed hiring a design technologist, but the idea never got traction as the design team was early in its development and didn't seem ready to bring one on - a position I completely understand. A solution could have been to advocate for a technologist as a contractor - the non-recurring expense is often easier to get approved. This is an approach I'll take in the future.