This post is the third in a series to document the challenges and joys of organizing and implementing a design system for Customer.io. We started by auditing our design system, which you can read about here.
After the tedious process of auditing our resources, UI, and processes, our next step was to create an organizational foundation for our design system. We needed to find the right tool to house the system and start documenting what we had.
The concept of documenting design systems is just starting to gain serious traction in the design community, which means that the tools are a little behind our needs. We had to be flexible in our requirements because there was no perfect tool. Here’s what we chose to prioritize:
And here’s what got left out:
We evaluated 10 different tools, given these priorities.
Zeroheight and Gitbook were out best options, and unfortunately Zeroheight ended up being very Sketch-focused (since writing this, Zeroheight has added a Figma integration). Even though Gitbook is meant for all types of documentation, not just design systems, it was the right choice for our small team given the criteria.
The next step was deciding how we would organize our design system documentation. There are a lot of ways to do it, and instead of making the choice for the team, I asked 5 members of our product team (designers, developers, and PMs) to do a card sort exercise to group and name the different aspects of our system that we wanted to document.
As it turned out, most of us chose similar categories and terminology. We all agreed that we should separate foundational styles from components. And that components could at least be divided into ‘Atoms’ and ‘Molecules’, ‘Atoms’ serving as the irreducible components and ‘Molecules’ as the more complex. We ended with these high level sections for the documentation.
Once we had the right tool, it was time to document the foundational styles for our product, specifically:
We split up this responsibility between the 3 designers. As it turns out, we were also doing a rebrand during this time, so a lot of the documentation ended up being aspirational — hoping to guide our UI to a similar style as our new brand.
We looked at design systems like Atlassian, Carbon, and Material to help determine what each page should look like. We didn’t create templates because each of these subjects requires very different information.
One of our designers, Richard, took on the color documentation and did an excellent job creating useful guidelines. He divided each of our colors into three sections: Palette, Accessible Combinations, and Examples, which you cans see below.
It was important for use to make documentation that would work for both developers and designers, so we reached out to the development when building these pages, to ensure we included helpful code snippets or SCSS variables.
Documenting our foundational styles gave us enough understanding of the current system to start working on some design principles to guide the rest of our work.