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.

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.

Roadmap

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

Outline

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

Color

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.

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

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.

Why?

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.

Principles

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

^{See slide show below}

Components

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.

Buttons

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.