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.
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.
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:
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.
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:
I also collected historical feedback from Github and Basecamp. I organized the feedback around themes in a giant card-sorting exercise.
Through these three audits, I learned:
We are ready to start documenting our current system. Read my next post to find out how we started our design system documentation.