3 designers
2 developers
Design system

Unifying Coda's design system

I helped lead the development of a design system for Coda, a new startup that did not have an existing system in place. This involved establishing standards, reusable components, and coding conventions, as well as organizing Figma files and creating proposals for UI redesigns.

Goals and responsibilities

  • Research best practices.
  • Make an interface inventory.
  • Rebuild and maintain Figma file with new Figma DS frameworks and best practices
  • Design and define layout, styles, and components.
  • Document guidelines.
  • Review documentation.
  • Build and implement components.
  • Iterate and refine.
  • Evangelize your efforts across your organization.”
  • Improving product accessibility

Examine current system

First, I carefully examined the application as a whole. I identified any existing conventions that could be reused and addressed any inconsistencies. To illustrate my findings, I documented everything in a Figma file. This allowed the entire design team to observe and understand the problems we encountered.

I also collaborated with the brand team to grasp the desired voice, tone, and visual style of the company.

Additionally, I engaged in discussions with the design team to explore the guiding principles that have shaped their decision-making process thus far. This allowed us to determine if any refinement or creation of additional principles was necessary to guide our decision-making for the new system.

Here was the rough draft of those principles:

The purpose of Coda is to empower makers with flexible building blocks to create the perfect workflows and systems with the power of an app.

🎨 The product colors should not be too colorful so the user content can shine through

📄 → Be document-like. All of our user-facing surfaces adhere to the fundamental traits of electronic documents in order to provide an accessible, learnable, expressive, and powerful work environment for the most people possible:

🏃 → Help users follow the flow. We can make flow tangible and visible by visualizing its pattern of execution, by letting them explore forward and backward. Relates most to “workflow,” or event-driven programming.

👁   → Have no hidden state. When a formula computes a thing, that thing should be immediately visible. If it computes many things, all of them should be shown together in context.

Survey problems

Next, I worked to define the goals and roadmap by surveying the team and reviewing the analysis of the product.

Uncover problems:

  • What are the main challenges they face?
  • What are the typical UI elements that each designer needs to recreate?
  • In what areas are they currently duplicating their efforts in inefficient ways?
  • Where is the communication between designers and engineers starting to deteriorate?
  • Where do the biggest inconsistencies occur?
Parity with code! There’s a published Storybook site for the code version of the DS, and it’s 1:1 with our (new and improved) Figma library
Dark mode is QA’d and baked in so we never need to think about it (maybe this is already true?)

Everyone on the design team can have a clear understanding of what components to use and what are processes/standards to update the design system
Get a strict 1:1 mapping from Figma components to dev components and rarely deviate / special case anything.
Zach/ Eng
It would be helpful if colors and text styles were easier to translate to the actual var used. I think text is the bigger offender here. Typically I have to look at the font size, go to the text.less file, find the corresponding font size, and then figure out which class applies that style. Ideally the actual font mixin and the text style in figma would match up. Maybe they do, but I don’t trust them to.
Too much dev time is spent building nearly similar situations, but they’re just subtly different (or perhaps the dev doesn’t know about the other component)
Often I find myself pretty sure that there is a component that already exists that I can use, but I don’t know what it is. We have storybook, but you cant search that with an image (or even really with a description of what the end goal is) and it’s not really presented close enough to the Figma, so I often just ask in Slack. Mildly less inconvenient, but I also sometimes am not sure what colors are global colors that I should go look to reuse vs more specific.


After analyzing these survey questions and interview notes, I created a roadmap and began addressing the core needs of the team.


1. Foundational elements, such as color

2. Core components that are most used and needed by the team

3. Rebuild Figma file

4. Resolve inconsistencies

5. Enhance communication

Clean up foundations


There were several outdated colors from a previous brand. The original brand colors for the product design color palette had been in use for three years when the primary color was selected. The primary color chosen was turquoise, which was used for all primary actions and selected states. In addition, an outdated orange color was used for both error states and notifications.

I started by discussing the new brand palette with the brand team. We explored the possibilities for using the colors in the product version. We examined different variations of each color to ensure interactive feedback and the appropriate level of desaturation for the product.

The main change was the primary color, which required an update to a more modern and versatile shade. After careful consideration, we decided on a blue color that not only created a pleasing contrast with the other colors but also suited product design better. Additionally, I experimented with black as a high contrast option for important call-to-action elements.

Updating the primary color was a particularly challenging task due to the numerous edge cases and scenarios that needed to be taken into consideration. This color plays a crucial role in providing interactive details during the editing process. For instance, let's examine how the color appears in tables, which are the core building blocks of the product.

Color variables

To further optimize the color implementation, I devised a system for specific class colors, such as stroke. By configuring the variables in a way that only displays the relevant color options when selecting a stroke color, I facilitated the quick identification of the appropriate color class for stroke application in both design and code.

To achieve this, I utilized Figma's variable mapping feature to associate the color variables with a new variable named according to its intended use. Additionally, I added the corresponding code syntax in the documentation property field, which is readily accessible during development.

By implementing these strategies, I aimed to bridge the gap between design and code, ensuring a seamless and efficient workflow for the entire team.

Finally I added in all of the dark mode variables so the design team had new access to those colors which were only in code at the time. This allowed them to turn in design from light to dark. I also designed all of the dark mode values and you can read more about that here.


Spacing was generally consistent across the design team, but there was an issue with translating designs into code. Many engineers did not closely inspect the designs to determine the appropriate right padding or margins. Additionally, there was no consistency or class system in place for engineers to reuse common space values. As a result, efforts were made to create spacers in Figma variables and establish a class system for engineers to utilize.

Border radius

The product had a mixture of fully rounded and 2, 6, 8, 10, 12, 16, 17, 18, and 19 px corners, which was confusing and lacked cohesion. To address this, we made the decision to standardize the border radius to 4 px. This choice struck a balance between rounded and sharp corners and significantly enhanced the overall appearance and aesthetic of the product.


While the fully rounded style can be seen as "friendly," using a semi style offers more benefits. We believe that it will create a consistent and balanced visual language in the system.

  • More adaptable to all scenarios
  • Aligns with the brand as a “blocky” visual effect
  • Creates balance and uniform when stacked (like in tables)
  • Aligns with boarder-radius on input fields an naked background hovers on naked buttons

Rebuild Figma file and start new documentation

The primary Figma library utilized by the team was hastily assembled, resembling more of a sticker sheet or wireframe with minimal styling. Unfortunately, this library lacks the incorporation of essential Figma best practices, notably auto layout, variants, variables, and properties. Consequently, designers find themselves using components that do not align with the coded version, leading to a disconnection between the design and engineering domains. In response to this limitation, most designers resort to creating their own individual design system files, separate from the main file, to adequately address the needs of themselves or their immediate team.

I began by reconstructing all of the foundational styles using the variables mentioned above. Additionally, I developed several key components and documented them in a Coda doc. This doc served as both documentation and task tracker, allowing engineers and designers to easily access information about available components and their usage

For each  component there was a video attached inside of the documentation to get an idea of all of the different variations and parameters that were accessible both in design and code.


I established principles for the file to help onboard everyone from the old to the new file.

See slide show below


All components were rebuilt with auto-layout, variants for different interactive states, properties and link to storybook in dev mode.

Flyout menu system

Each cell has a top level parameter that changes the type to be either a

  • Menu option
  • Divider
  • Title
  • Search field

The component is presented with all the different variants so designers have a sense at all the different options. There are hidden cells for more menu options available.

The full parameters in the design panel.

In addition to the base component there is also 3 common flyouts that designers need so there are quick templates to jumpstart projects.


Coda has 6 different button styles, and when I joined the company only three of them were documented in one size with zero variance. When I re-factored our Figma library, I introduced the three other styles as well as introduced size and state variance. Designers could manipulate the parameters as such.

I also learned when creating this component, which is arguably the most used component in most design systems that is usability trumped efficiency. I began by creating the component with a base button, which helps to establish the auto layout and overall padding, which differed, depending on whether or not, there was an icon, but it created a ton of usability issues in the design panel considering that a ton of parameters were repeated twice. For example, the icon instance picker showed up twice and sometimes it was really unclear which one you should use if you wanted to change the icon, and if you accidentally change the icon on the base, it could really mess up the entire component. So I simplified it by taking out the base, which makes it a little harder to maintain, but the benefit of ease-of-use definitely was worth it.

I also created interactive prototype interactions so the buttons mirrored the interactive states in prototype mode.


There were several key learnings that I gained from rebuilding the design system.
Firstly, I realized the importance of gathering input and feedback from everyone involved, as it helped to create a sense of ownership and belonging to the system.

Additionally, I came to understand the significance of having a strong collaboration between design and code. To facilitate this, I even started learning to code myself, which greatly aided in better organization and alignment between design and development.

Lastly, I realized that maintaining the design system is an ongoing effort. With numerous product demands, it is crucial to keep everything in sync and cohesive for the entire product team

👀 There are many more details on this effort. Please reach out to request a portfolio presentation and learn more.