Auditing our design system

This post is the second in a series to document the challenges and joys of organizing and implementing a design system for Customer.io. If you want to find out why we are building a design system, read the first post here.

I joined Customer.io at a time of expansion — over the past year our product team has grown from 2 to 6 and our design system hasn’t changed. With 3 designers at a 40-person company, we knew it was time to improve our app’s experience through a more systematic approach to product design. We wanted to start building a great design system.

I believe every product has some design system, even if it’s not acknowledged, documented, or truly systematic. But did we have a great design system?

A great design system is a set of principles, components, guidelines, and practices that help a product team actualize the vision of the company through product design.

Before digging my teeth into improvements, I needed to know what we were working with. I did three design system audits: resources, UI, and process.

The Resources Audit

My first step was to figure how we were organizing and implementing our current design system. I talked to the current designer and developers to find out what they were using in day-to-day design work. We have:

1. An ember library with reusable coded components. We use classes to deal with variations within components. Not all of the components are documented and a lot of the documentation is out of date. We have a lot of one-off versions of components.

2. A SCSS guide with reusable variables, used to style the components.

3. The collective knowledge of a UI/UX Designer and several Developers about patterns.

4. Some disparate component documentation, like a google doc about when to use different kinds of warnings.

The UI Audit

Even though we had these components and knowledge of guidelines, it wasn’t clear how they were reflected in the UI.

We decided to try a new design tool that is built for design systems called Figma. It’s web-based, which makes file management and collaboration easier than Sketch. I used Figma to collect screenshots of all the components used in the actual interface. I purposely didn’t just render our library of coded components, because I knew that in actuality we were using a lot of customized one-time versions of those components.

I organized the screenshots into three categories:

1. Styles: colors, typography, and iconography
2. Atoms: the irreducible, simplest components, like buttons or tags
3. Molecules: more complex components that often contain atoms

I used the screenshots to build reusable Figma components and published them as a shared library in our team Figma account, which took over a week (there are at least a couple hundred). During the process, I kept notes about inconsistencies or opportunities within the system, including everything from unnecessary one-off buttons to outdated colors.

Not only did this help me establish a library to build wireframes faster for my feature work — it also allowed me to analyze components in the context of their use in the UI.

The Process Audit

Along with the resource and UI audit, I wanted to find out what was working and not working about our design process. I did 6 empathy interviews with PMs, Designers, Developers, and Marketers. I asked questions like:

1. What tools are you using?
2. How do you know which components to use for each use case? How often are you unsure which components to use?
3. How do you know when to create a new component?
4. (For designers) How are you making iterations, both on entire frames and components?
5. (For developers) What is the biggest challenge while building wireframes into screens?

I also collected historical feedback from Github and Basecamp. I organized the feedback around themes in a giant card-sorting exercise.

What did I learn?

Through these three audits, I learned:

1. We need a defined design direction, including design principles, so designers know how to make hard decisions.
2. We need unified documentation that can be shared across teams, with more thought toward guidelines for components. This will help us make improvements to the reusability/connectedness of our components.
3. We need someone to be accountable for design system process and documentation.
4. We need to have a plan to make visual updates before we fall behind competitors (which rests on having a direction and better documentation).
5. We need improved process for initial design discovery, feedback, and modifying/adding components.

What’s next

We are ready to start documenting our current system. Read my next post to find out how we started our design system documentation.