2024 - Case study

Enzuzo: Building and scaling a design system in Figma

Design systems are heroes of our everyday products. At Enzuzo, we sought to establish the foundational principles and elements to define our user experience and elevate our design process.

TIMELINE

1 month

TEAM

1 Designer
2 Software Engineers

TOOLS

Figma

DISCIPLINES

UX research

Design systems

OVERVIEW

When I joined Enzuzo’s team as a Product Designer last spring, one of my first projects involved the creation of a revamped design system v3. I took on the responsibility of developing a strategic plan to introduce a UI system benefiting multiple stakeholders in our company, including users, designers, and developers.


This new system would go on to strengthen the creation of our digital products through effective collaboration and enhance consistency and efficiency.

CONTEXT

Setting the scene

Building a good design system that scales across teams means cataloging components with meticulous detail.


In the early days of Enzuzo, there was no design system or designated product design team. Most of what was the ‘design system’ had been put in place by the engineering team.

Enzuzo's design system (2.0) at project start.

Fast forward to present day, Enzuzo’s current design system file and its components have been accumulated through many years of trial and error. It’s a collection of elements, both old and new, reflecting the development of the Enzuzo brand over time— while it is classic and serves as a reminder of our roots, it hasn’t held up well over time.

PROCESS

The problem

How might we utilize Figma to create a unified, effective design system?

How might we utilize Figma to create a unified, effective design system?

When I joined the company in 2023, I was faced with a daunting realization: Enzuzo’s design system had gone through the hands of multiple designers, each with their own style, flair and way of thinking. The issue was the previous design team had been disbanded by this point, and there was no one actively pushing this system forward. It became a challenge for new team members to make sense of what was left of the system, and it lacked the proper documentation to do so.


At the same time, Enzuzo was rapidly expanding their feature arsenal, requiring the designers to create brand new components to accommodate each new feature rollout. With the company moving in new directions, I saw a pressing need for organization, structure and consistency.

Design system 2.0 file setup.

After being passed around many different designers, the app had become largely inconsistent. If one designer worked on a new project, the rest of the UI created by a different designer quickly became outdated.


Enzuzo really needed a useful, unified design system. This time, we wanted to design our design system, just like we’d design one of our product experiences. To jumpstart this process, I summarized our challenges into 3 key problems:

🌀

Messy, disorganized files

No clear hierarchy or proper use of Figma design operations. Components were scattered, hard to find, and not well structured, leading to redundancy.

🗓️

Outdated

Our system was a combination of old and new components, leading to inconsistencies in the look and feel. This includes colors, spacing, guidelines and more, making the product feel dated. This negatively impacted the overall experience and brand image.

🐢

Slow project timelines

Long amounts of time were spent recreating elements and patterns, leading to slower project timelines and long development handoff. New users to the system would often struggle to understand how a component started, how it was edited, and what version they were using.

Phase 1 : Reviewing the old design system

I didn't begin this project completely from scratch— it was crucial to build upon what already existed and consolidate it into a unified system driven by a clear, cohesive vision.


I began by reviewing the design system and, using Brad Frost’s interface inventory guideline, conducted a full audit. I identified inconsistencies and discovered multiple variations of buttons, badges, and other components.

I was able to compile all of these screenshots in a document to help build a stronger case for a redesign.

Identifying our users

Before building, research was needed to understand how to develop a system to benefit all. It wasn’t just us, product designers, who needed to use and understand it but, developers, project managers and more.

The handoff problem.

It soon became clear why we were running into these issues: our design system lived in two different places— from a designer’s perspective this meant in a tool like Figma. For a developer, this meant source code built and maintained on a codebase. Designers working on new projects would create and update visuals to fit their needs, while the frontend team would choose to write new components instead of waiting on external library updates.

💡

This difference in mutual dialogue led to broken workflows, and the consolidation between design and code quickly began to crumble— It became hard to determine what the source of truth was

Enzuzo’s design system; a developer’s perspective

To address this problem, I spoke with our developers to determine common pain points when using our design system. I began researching the tools they use and sought out ways to effectively bridge the gap between design and development. I discovered that insufficient documentation in the design system and poor communication during hand-off prevented developers from effective work. From here, I created 4 overarching goals for our project:

🗂️ GOAL #1

Use Figma’s operations to create a clear hierarchy and organization.

💬 GOAL #2

Improve system communication through intense documentation.

😵‍💫 GOAL #3

Reduce redundancy in the design process.

📈 GOAL #4

😁 GOAL #4

Improve product consistency to elevate brand image.

SOLUTION

Design exploration

To kick off the building phase, I focused on developing the foundational elements (atoms— we'll dive into this later 😉) of our design system, including color palettes, fonts, grids, spacing, and buttons, before moving on to the more complex components.


Some of the activities at this stage involved:

  • Consolidating: Joining together various component variations to retain only the essentials.

  • Exploring other design systems and interfaces for common practices and design inspiration.

Google’s Material Design System.

Key principles:

  • Applying auto-layout to ensure responsiveness.

  • Designing for multiple component states such as hover, focus, filled, error, and disabled state.

  • Prioritizing accessibility in the design of each component, striving to meet WCAG AA standards.

Applying atomic design principles

Atomic design is a design methodology that advocates breaking down interfaces into smaller, more simpler component building blocks. These components, or “atoms,” can then be combined back again to create larger, complex structures like templates or entire pages and interfaces.


Much of our old design system didn’t fully embrace atomic design principles—components were often built as-is, without being broken down. This created redundancy, especially during updates or batch changes to components.

Overview of various atoms, molecules and organisms in Enzuzo design system 3.0.

Using atomic design principles, our components became reusable, and maintainable (modular) while allowing new components to be added without disrupting the existing structure (scalable).

Atomic breakdown of an Enzuzo page's components.

Utilizing component properties

A key issue found with the old design system was its dependence on variants instead of component properties to show multiple component states. This was especially noticeable in our button and text field components— instead of using booleans and other operations to adjust the changeable aspects of a component, there was a variant for every single one

Before: 5 variants, 4 states, 5 types.

To put this into perspective, we were sifting through 100 different copies of a button every time we used it. This became especially problematic when using our text field component, which had even more requirements. This was evidently very, very inefficient and created a number of problems throughout our design process:


Cons: 

  • Well… 100 variants. 

  • Sifting through a number of random value names for each property, which can be hard to visualize.

  • Required digging through the individual instance layers to change icons and text.

  • Time-consuming to make batch edits (Ex, change the padding of all primary buttons).

After: 5 variants, 4 states, 2 types.

To fix this, I used a combination of text, boolean and instance swap component properties to reduce the number of variants. This took our button count from 100 down to 40— much more manageable!

Component setup— after.

Understanding variable mode and tokenization

I took the initiative to develop Enzuzo’s first token system for ease of use by both designers and engineers. Implementing variables bridged our gap through a shared language— one that allowed us to create and use preset values or “tokens” within designs, such as corner radii or spacing measurements. These tokens could reference one another and be reused across multiple elements, creating a single source of truth by defining a clear, trackable relationship.

Enzuzo color token system built from Figma variables.

To start the migration process, I created primitive variables for radii and padding, as well as colors using Tailwind CSS's numerical suffixes (50 to 950). From here I constructed a semantic layer referencing these primitive variables that would provide context on how these values are used and establish a meaningful set of design rules.


For example, the icon/disabled token describes the color of any icon in a disabled state. This semantic layer token references the primitive token of color/neutral/300, which has a hex value of #B0B0B0. 

Organizing our system in this way introduced increased organization and consistency, established clear guidelines that prevent misuse and created a trackable hierarchy of values that make future changes to our design system much, much simpler.

Increased organization and categorization

Organizing a Figma file for a design system can be done in many ways depending on company’s needs. But to create a single source of truth, we needed to ensure that it would cover everything from index to extensive documentation.


Enzuzo has one product with one theme (light mode), so we went with one file broken down into 2 broader categories — principles and foundations (typography, color palette, borders, radiuses, etc.) and components (buttons, alerts, toasts, badges, etc.).

Components could be broken down even further, into base components and product components (larger components such as the sidebar that make up the product) and allocated a separate page for each individual item. We also made sure to include supplementary information such as a cover, introduction and index.

New organized Figma file.

By organizing our file this way, it became easier to locate items and digest information. Separating base components into individual pages created space for useful documentation such as characteristics and usage guidelines without clutter.

REFLECTION

Results

Our design system is still evolving and being refined over time. After integrating the new components, we evaluated it's efficiency. My development team provided feedback on what was effective and what needed improvement. We observed a 37% increase in efficiency across our project timelines.


Successes 🙌:

  • Reduced time spent developing new components.

  • Smoother handoffs with clearer element descriptions.

  • Fewer revisions and less back-and-forth during QA.

  • More consistent implementation of the coded design.

An overview of Enzuzo’s final design system.

Takeaways and learnings

🪞

Design systems aren’t perfect

Design systems can feel limiting— it requires time, investment, maintenance and creates rigid ruling guidelines that may make teams resistant to change. However, these systems are put in place to help us. A well-crafted design system does not restrict creativity; rather, it empowers designers to focus on higher-level creative decisions.

💗

Receiving feedback and iterating

As a designer, receiving feedback is a part of the job. It's okay to not do things perfectly the first time, or know how to do them. Communicating with your team and utilizing feedback helps refine your work, reveal blind spots, and better align your designs with stakeholder goals.

2024 © All Rights Reserved

2024 © All Rights Reserved