Building Cobalt: Talkdesk’s Design System
Cobalt, the design system we use at Talkdesk, is a unified system to define, design and develop our product keeping consistency and reusability at the heart of the process, in order to deliver seamless, meaningful and delightful experiences to our customers. It also helps our designers think more about the flows and UX rather than the pixels and UI.
The need
Talkdesk started in 2011 in a hackathon. Our co-founders Tiago Paiva and Cristina Fonseca entered a contest hosted by Twilio and built the first version of Talkdesk right there. After nine years, we went from two people in a hackathon to 1000+, becoming the first CCaaS (Contact Center as a Service) unicorn.
I joined the Product Design team in 2017. We were four designers. Today we are 24 and we plan to reach 30+ by the end of 2020 — at least that was the plan before COVID-19! We’ll probably have to revisit that number, but the team keeps growing, even during the most critical stages of the pandemic.
Our product has also evolved into multiple different projects inside the CCaaS area and expanded into other areas around it, like Workforce Management, Artificial Intelligence, Unified Communications… We’re basically trying to cover all the needs of a contact center, not just call handling.
From 2011 to 2016, like any start-up, things had to be built fast — and without any style guide and only a few designers, each team started implementing their code, sometimes rebuilding things other teams had already built. That’s how we ended up, for example, with four different types of dropdowns.”
It was clear that we needed to organize ourselves and optimize the way we work. There was an urgent need for a Design System.
The beginning
It all started just by trying to have a consistent color palette. So we created the primary color gradient and the first basic components. We also named it Cobalt. Why? Well, because it’s blue.
Within a few weeks, the first two products were launched with a new and consistent style, but we didn’t have a design system yet.
We were building the components as each product needed them, so the process was still slow, and we were not following the design systems’ best practices of building atomic components. We were basically building whole molecules for each use case.
We all agreed that even though we now had a consistent style guide, we needed to have a real design system with atomic components. The first step was to build a team.
The team
Initially, the team was composed of a designer (me) and three front-end engineers. We wanted to build our design system in three layers:
- Sketch: for designers.
- Vanilla HTML/CSS: we didn’t want the base code to be dependent on any technology, so we built it in simple HTML/CSS, and called it Cobalt Design.
- React: since engineering teams were using React, we imported the Cobalt Design components into Cobalt React components.
We encountered a few challenges on the way. How could we keep the three versions in sync? It’s easy for the React version to just import the CSS code from Cobalt Design, but what about the Sketch version?
We tried a lot of things, including the amazing AirBnB ReactSketch.app, we looked at other tools (like Framer X) but we didn’t find a solution that worked for us. So instead we focused on creating better communication channels between Product Design and Cobalt teams in order to keep Sketch and React versions in sync.
After six months, we had about 90% of the necessary components for any engineering team to start working on any project. The final 10% were things that we knew we would eventually need, but none of the projects’ roadmaps needed them for now.
Today, the Cobalt team has tripled its size, a team of engineers totally dedicated to evolve and maintain our design system. On the Product Design side, we now have one designer fully dedicated to the design system and three others (me included) that give support to our designers and are in constant communication with the Cobalt team.
The process
Even though it’s constantly evolving, the process to create a new component is usually the following:
Step 1
A designer needs a new component and creates a preliminary version (can be a wireframe or a more advanced UI) in Sketch. We do regular design critique and sharing sessions, so we usually use these meetings to get feedback, including design system component proposals.
If the proposal is accepted, the designer needs to work together with the other designers responsible for maintaining the design system. This includes creating all the variations of the component in Sketch and writing the documentation (variations, sizes, spacings, accessibility, etc).
Cobalt engineers also participate in the early stages helping to decide if the designer’s request should be a new component or a combination of an already existing one (we call them patterns).
Step 2
After the Sketch version is complete, the work on the HTML/CSS and React versions starts. At this stage, designers should already be able to use the new component on their Sketch files. This enables us to design features early, making them ready for engineering teams to use as soon as they are ready in React. This way designers are always at least one sprint ahead.
When the React component is finished, we validate it one last time to check if the end result matches the initial request. After this, it gets published and becomes available to all the engineering teams to use on their projects.
The components
As of today, we have about 30 atomic components with hundreds of variations. We also have about 30+ patterns that combine multiple atomic components into more complex molecules (e.g., the dropdown or the pagination).
Documentation
Each component has had since the beginning a documentation page in two flavors: code and design. This way we can tailor it for engineers or designers with specific instructions on how to use the component and how it should behave.
In Sketch, we also have instructions for designers on how to build complex molecules that require assembling multiple atomic components together to reach the final result.
Growth pains
As the company kept growing fast, we noticed that the new designers and engineers had some difficulty starting their projects. They just didn’t know where to start when they had to build a page from scratch.
The documentation we had was specific for each component so we didn’t have any guidelines on how to build an actual page and how components lived and interacted with each other inside it.
So we decided to create templates. They were created in both Sketch and React. This way, both designers and engineers can pick a “page type”, and get an example template with all the main elements already placed inside, with the correct grid alignments.
The future
As the design system matures, we are now focusing on the details. Each component is being reviewed and we are adding accessibility and usability improvements (keyboard navigation, ARIA labels/roles, better documentation).
We are also constantly updating our Sketch symbols to take advantage of more powerful features (like smart layout), even though we spent about ten months struggling with a Sketch bug that prevented us from properly updating our Design System to the latest version (more on that in a future post). Because of that, we also regularly evaluate new tools like Figma.
We will also start adding UI text guidelines to improve our documentation. As the team grows, it becomes harder and harder to keep track of the tone of voice that we also need to make consistent throughout all our projects.
White label and theming
As our product keeps growing into the enterprise market, we need to have a white label solution that our resellers can sell to their customers. This also means that we need to support themes. This is a big challenge because it impacts most components that use our blue color palette.
What if the customer wants it in yellow? That means that all secondary colors (e.g. the white text on the button) need to adapt to a darker version in order to keep things readable.
So, we’ll still have some exciting times ahead.
Final thoughts
As mentioned earlier, Talkdesk is growing at a tremendous scale. This has resulted in too much work for both designers and developers. Having a design system has significantly improved the speed and efficiency of our workflow and completely transformed the way we design and develop our product.
For designers, it has helped to:
- Wireframe and design with components and patterns for new concepts/features in existing or entirely new parts of our product.
- Have a source of truth for our style guidelines freeing designers from having to think about UI, focusing more on the UX, and working closely with product managers to help shape the product.
- Have a consistent style that can be used by a growing team of designers while they build new features in multiple different parts of our product, making it feel like one single unified experience.
For developers, it has helped to:
- Use and reuse the base components (atomic and molecular level) to quickly build pages or test new concepts.
- To keep the projects updated with the latest behaviors or styles, since new features are added to the base components with new updates.
If you are building your own design system, know this: design systems are never finished. Make peace with the idea that it will never be perfect. It’s better to have something than nothing, so don’t wait for all your elements to be ready before using it. A design system will always evolve.
Designers and developers need to work closely together when building a design system.
You should develop principles and document when and how to use various components — simply having a UI kit and code is not good enough because as the team grows, new members will have a hard time figuring out how things work together.
You’re never too small, and it’s never too late to start building a design system. They can be complex or simple and everyone’s needs will be different, this all depends on whom the design system serves.
