Building design systems
I was a graphic designer (+ many other hats) for 5 years before making the switch to frontend engineer. I found that building the UI I was designing was much more rewarding than the designing itself. Because of that experience—or in spite of, who knows—I absolutely love planning and building design systems.
At Tracer we were approaching that transition era from being a slap-dash, build fast and break things start up culture to one that was starting to look further into the future. The tradeoff of speed over reliability and confidence was starting to tip. And because of that we needed a consistent design system that could be equally owned by engineering and design.
We made the decision to solidify our design system when we reached a point where the product was stable, we had a known scope of components we intended to continue using, and we had relatively consistent mocks.
Below is an excerpt from my team’s roadmap documentation ↓
Having mixed design patterns can be confusing and disorienting to a user. It can make adoption difficult for new clients because they will learn different
user flows or experiences. It makes our product look less polished, less complete, and therefore less reliable. It means that we have a group of components that we actively do not maintain with the intent to revisit or remove later.
We started the project by doing a complete component audit with the engineering, design, and product teams. This was a multi-part exercise.
- Pair with the design team to define the scope of the new design system. What upcoming work was mature enough to consider? What existing components do we plan on deprecating?
- Gather examples of the components in situ. How are they used? How many variants might they have?
- I led a group meeting with engineering, design, and product, plus any other team members who wanted to join. We split into teams by mixing roles, cut up printed application pages and mocks, grouped components based on similarities and started naming the groups. We then compared each team’s decisions, found where there were commonalities and narrowed down our component categorizations.
After this meeting we set to building the components. We used Storybook to house the design system so we could easily share demo-able components with their variants. Storybook also gave us an easy way to document each component with auto filled prop names, types, and defaults. We could also add more content using object configs in the story code to describe when and how to use a component or more insight into what the prop data should be.
While building I enforced Jest testing of all new components plus added Chromatic to our PR pipeline to catch any unintentional changes. Overall converting our sporadic and inconsistent components to a design system library allowed our team to communicate more clearly while building features faster and with more confidence. It also had the added benefit of allowing engineers who might not be as confident with our frontend tooling to quickly create user facing features and run experiments.
This project was approaching the finish line as I left Tracer so while I don’t know how much it is maintained you may see a live version of the Emerald Forest Design System here.
If you want more specific component-y content I primarily worked on the Tables & Lists category while leading the team dedicated to working on the other segments. You can read more about that here.
