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

I also collaborated with the brand team to understand the company's desired voice, tone, and visual style.

Additionally, I held discussions with the design team to understand the guiding principles that had shaped decision-making up to that point. This helped us determine whether we needed to refine existing principles or create new ones to guide decisions 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 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 as many people as possible:

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

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

Survey problems

Next, I defined goals and a roadmap by surveying the team and reviewing the product analysis.

Uncover problems:

• What are the main challenges people face?
• What are the typical UI elements that each designer needs to recreate?
• In what areas is the team duplicating effort inefficiently?
• Where is communication between designers and engineers starting to deteriorate?
• Where do the biggest inconsistencies occur?

Orr/Design

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?)

‍

Elva/Design

Everyone on the design team can have a clear understanding of what components to use and what processes and standards to follow to update the design system.

Get a strict 1:1 mapping from Figma components to dev components and rarely deviate or 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)

Phil/Eng

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 the survey questions and interview notes, I created a roadmap and began addressing the team's core needs.

Outline

1. Foundational elements, such as color.
2. Core components that are most used and most needed by the team.
3. Rebuild the Figma file.
4. Resolve inconsistencies.
5. Enhance communication.

Clean up foundations

Color

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

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

The main change was the primary color, which needed to be updated to a more modern, versatile shade. After careful consideration, we chose a blue that created pleasing contrast with the rest of the palette and better suited product design. I also explored black as a high-contrast option for important calls to action.

Updating the primary color was especially challenging because of the many edge cases and scenarios that needed to be considered. This color plays a crucial role in providing interactive cues during editing. For instance, here is how the color appears in tables, which are core building blocks of the product.

Color variables

To optimize color implementation, I devised a system for specific class colors, such as strokes. By configuring variables to show only relevant options when selecting a stroke color, I made it easier to identify the correct color class for stroke application in both design and code.

To do this, I used Figma's variable mapping feature to associate color variables with a new variable named for its intended use. I also 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 and support a smoother workflow for the team.

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

‍

Spacing

Spacing was generally consistent across the design team, but translating designs into code was a challenge. Many engineers did not closely inspect designs to determine the appropriate right padding or margins. In addition, there was no consistent class system for reusing common spacing values. To address this, we created spacers using Figma variables and established a class system engineers could reuse.

Border radius

The product had a mix of fully rounded corners and 2, 6, 8, 10, 12, 16, 17, 18, and 19 px corners, which was confusing and lacked cohesion. To address this, we standardized the border radius to 4 px. This struck a balance between rounded and sharp corners and improved the overall look and feel of the product.

Why?

While fully rounded corners can read as “friendly,” a semi-rounded style offers more benefits. We believed it would create a consistent, balanced visual language across the system.

• More adaptable across scenarios.
• Better aligned with the brand’s “blocky” visual effect.
• More balanced when stacked (for example, in tables).
• Better aligned with border radius on input fields and “naked” background hovers on naked buttons.

The primary Figma library was assembled quickly and functioned more like a sticker sheet or wireframe, with minimal styling. It did not incorporate essential Figma best practices such as auto layout, variants, variables, and properties. As a result, designers used components that did not match the coded version, creating a disconnect between design and engineering. In response, many designers created their own design system files, separate from the main file, to better serve their needs or their team’s needs.

I started by rebuilding foundational styles using the variables mentioned above. I also developed several key components and documented them in a Coda doc. This doc served as both documentation and a task tracker, allowing engineers and designers to easily access information about available components and how to use them.

‍

For each component, I attached a video inside the documentation so people could understand the different variations and parameters available in both design and code.

Principles

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

See slide show below.

All components were rebuilt with auto layout, variants for different interactive states, properties, and a 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 different variants so designers can see all available options. There are hidden cells for additional menu options.

The full parameters in the design panel.

In addition to the base component, there are also three common flyouts designers frequently need, with quick templates to jump-start projects.

Buttons

Coda has six button styles. When I joined, only three were documented, in one size, with no variance. When I refactored the Figma library, I added the other three styles and introduced size and state variants so designers could adjust parameters as needed.

While building this component, I learned that usability can matter more than efficiency. I initially created a base button to establish auto layout and padding, which varied depending on whether an icon was present. However, it created usability issues in the design panel because many parameters were duplicated. For example, the icon instance picker appeared twice, and it was not always clear which one to use. If someone changed the icon on the base, it could disrupt the entire component. I simplified the component by removing the base. This made it a bit harder to maintain, but the ease of use was worth the tradeoff.

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

I gained several key learnings from rebuilding the design system.

First, I saw the importance of gathering input and feedback from everyone involved, which helped create a sense of ownership in the system.

Second, I came to understand the value of strong collaboration between design and code. To support that collaboration, I started learning to code, which helped me better organize and align design and development.

Finally, I learned that maintaining a design system is ongoing work. With constant product demands, it is crucial to keep everything in sync and cohesive across the product team.

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