Design System

Investigation

So I started with an audit, went through screen by screen, captured the most used patterns and controls. Collected an inventory in Figma with screenshots and annotations, compared the current UI kit and old layouts with prod. The frequency of use determined the priority, so the first version went to what slowed down the fronts the most and what I lacked the most for designing new features.

Audit findings

• Up to 3 different variations of the same control in production, with no clear rationale.
• Interactive states (hover, focus, error) were implemented ad-hoc for each section and rarely reused.
• Hardcoded CSS colors blocked any potential dark mode implementation.

Preliminary research

I dedicated time to research and prep work, studying documentation for industry-standard design systems like Material, Polaris, and Carbon, alongside public Figma libraries from leading design teams. I focused on the “why” behind their architecture—reading articles and watching tech talks to understand how large teams approach naming conventions, component hierarchy, variants, and nested instances.

Research goals

1. Adapt proven design system structures from leading teams to our specific workflow.
2. Improve product consistency through systematic reuse of components and UI patterns.
3. Define an incremental roadmap for a stable, scalable library to accelerate delivery.

Core constraint

We had to roll out the design system iteratively without slowing down product releases. At the time, I was the sole product designer, with no plans to expand the team.

Roadmap

1. Define baseline: colors, typography, spacing, and effects.
2. Core components: buttons, checkboxes, inputs, and icons.
3. Key patterns: navigation, tables, modals, sidebars etc.
4. Align with code: establish shared naming conventions and interactive states for every component in Storybook.
5. Documentation: usage guidelines & contribution rules.

How the process was structured

While the textbook approach might have been to halt other work and focus entirely on the design system, that would have frozen product releases for months. As the sole designer, I couldn’t do that. Instead, I built components incrementally inside active tasks. Every new feature became a pilot project, testing components under real-world product conditions.

The result

Using industry best practices, I introduced a 4px baseline grid for layout spacing, defined global layout rules, and set up our color palette and typography styles.

Leveraging these guidelines, I built a library of core controls (molecules), which immediately accelerated the creation of templates for active product tasks.

Developer alignment

I synced with the frontend lead to share the work, collect feedback, and align on naming conventions for interactive states and components.

Key takeaways

Building screens with the new library was noticeably faster for both design and engineering.

More importantly, it proved that a solo designer can stand up a design system without halting active product development.

The pitch

Late 2020. Once the pilot components were tested, I presented the results to stakeholders. A task that typically took ~21 business days was shipped in just ~14 days using the design system.

These numbers made a compelling pitch. The CEO and CTO approved the roadmap and allocated 6 hours of my weekly time to develop and maintain the system.

The presentation

I presented the system at a leadership sync, explaining the logic of a component-driven workflow and its impact on day-to-day delivery.

• The CEO approved the initiative because the metrics were clear: time-to-market cut nearly in half, translating directly to cost savings.
• The CTO backed the architecture (colors, type styles, and Storybook alignment), agreeing that a unified system was vital for scaling the product codebase cleanly.
• We agreed to work toward making Figma and Storybook our single source of truth, eventually phasing out Zeplin and further streamlining handoffs.

Outcomes

• Got the green light for the system by proving −30% in delivery times.
• The frontend lead became the primary champion of the design system within his team.
• Carved out dedicated weekly hours for design system maintenance.

Starting without tokens

To speed up the initial rollout, we deliberately delayed tokenization and kept hardcoded values. Accepting this temporary design debt allowed us to get the system into production faster. The trade-off came later: migrating to semantic tokens eventually took six months and required a partial dashboard redesign.

Over five years, the system evolved through close collaboration with engineering, balancing immediate delivery needs with long-term architectural stability.

Legacy Zeplin handoffs

Early on, I had to manually sync all Figma mockups to Zeplin. This legacy design-to-dev pipeline added friction and slowed down production.

Desktop-first scope

Before we built the mobile app in 2023, the design system was strictly desktop-first, covering the web application down to a minimum width of 960px. The mobile app components came later: I built them in a separate Figma file, on the same shared tokens.

Code as the source of truth

Enforcing the rule “a component isn’t done until it’s shipped in code” initially slowed down design phases but permanently eliminated UI discrepancies in production.

Strategic insights

At the start, I was the sole champion of the design system. I faced daily friction from the outdated UI kit, whereas frontend and QA felt they were doing fine: components were styled on the fly, layouts were verified by eye, and inconsistencies weren’t seen as a blocker.

My first hurdle was demonstrating how a design system would make their lives easier. For developers, it meant using pre-built components rather than writing custom CSS for every view. For QA, it meant eliminating tedious pixel-pushing layout audits. Once they experienced these gains on real features, rather than in slide decks, “consistency as a baseline for UX” became a shared team goal.

Context

When Figma introduced Variables in 2023, I immediately recognized their value and planned our transition to design tokens. To align Figma with our codebase, I rebuilt our components from scratch and mapped out 300+ variables, which formed the foundation of Version 2.0. I ran workshops with the frontend lead to align our design token structures with the project’s updated tech stack.

Implementing a semantic hierarchy

Instead of referencing global primitives like blue-500 directly, we introduced semantic tokens (e.g., button-color/primary/default resolving to a base value like blue-800). This layer of abstraction made global changes—like dark mode implementation or white-labeling—a matter of a few clicks.

Token migration and dashboard refresh

Migrating the legacy setup to tokens took over six months. The scope expanded because we paired the token rollout with a visual refresh of the user dashboard and primary app interfaces.

I redesigned the navigation and layout structures, moving the sidebars outside the main canvas. This created a clean visual separation between application shell navigation and actual workspace content.

Outcomes

• Unblocked dark mode implementation.
• Instant, global style updates via Figma variables.
• Established a shared language and naming structure between design and engineering.
• Self-documenting code through clear semantic names (e.g., button-color/primary/default).

Component inheritance via .base wrappers

I introduced .base master components to manage complex, variant-heavy controls. This inheritance model allowed us to update the underlying structure in one place and cascade changes to all derived variants. It eliminated a common class of bugs where styles were updated in one variant but missed in others.

This wrapper model became our team standard. As the design team grew to four, it kept our libraries organized and saved dozens of hours of manual work during the dashboard redesign.

Interaction specs

Component behaviors were based on standard usability patterns and refined in collaboration with frontend engineers:

• Eight core interactive states: Default, Hover, Focus, Active, Selected, Disabled, Error, and Loading.
• Built-in accessibility (a11y): color contrast validation matrices, keyboard focus outlines, and alt-text guidelines for screen readers.
• Standardized navigation & toolbar selection states, making control behaviors predictable and reducing cognitive friction.

Micro-interactions

Predefined interactive states and transitions became a core requirement for component delivery. Every control included standard transitions (fades, scale presses, micro-feedbacks), enabling high-fidelity prototypes that felt indistinguishable from the live product.

Foundation tokens

• Grid System: 4px baseline for component spacing/padding, 8px for layout blocks.
• Color Palette: 5 semantic groups with 10 flat and semi-transparent shades to ensure design flexibility.
• Typography: Modular type scale built on Onest, a highly legible modern sans-serif.
• Iconography: Unified 20×20px grid boundaries with a 2px stroke weight for visual consistency.

The handoff process

We aligned Figma’s folder structures with Storybook specifications: same logic, same naming. The workflow was streamlined: I designed components against a checklist, handed them off, engineering built them in Storybook, and I performed design QA. We also reviewed edge cases and states before implementation, significantly accelerating releases.

QA and delivery gates

As the team grew, I introduced strict QA checks before publishing new components to the library:

• Spacing and sizes align with the 4px grid.
• Interactive states defined (Default, Hover, Focus, Active, Selected, Disabled, Error, Loading).
• Auto-layout and responsive constraints fully configured.
• Naming matches Storybook spec, with all styles mapped to library tokens.
• Component behaves correctly across responsive screen sizes.
• Standard transitions and micro-interactions implemented.

Scaling file quality

As the library grew past 200 components, manual layout audits became unsustainable. Spending hours bi-weekly hunting for detached styles and override paddings was slow and error-prone.

Automating audits with a custom plugin

To solve this, I built a custom Figma plugin called AxoLinter that scans layouts and flags non-token overrides. Key features:

• Categorizes styling errors (colors, corner radiuses, spacing, contrast).
• Computes layout token coverage percentage.
• Suggests matching tokens and lets users link them in one click or auto-resolve all errors.
• Aligned terminology eliminated design-to-dev miscommunication.
• Replaced static guidelines with Storybook as the source of truth, cross-linked to Figma.
• Devs received production-ready layouts that respected engineering constraints.
• Automated linting reduced library maintenance overhead.

Transitioning from Zeplin to Figma Dev Mode

Previously, we handed off designs via Zeplin: designers exported assets, and developers inspected code snippets. Any layout adjustment meant a new export, causing version mismatches and adding to licensing costs.

We integrated Figma Dev Mode as soon as it launched. I onboarded our developers, showing them how to inspect tokens and copy component properties directly inside Figma. This allowed us to sunset Zeplin, reduce tooling costs, and eliminate styling bugs from outdated mockups.

Knowledge transfer

I set up a structured 1-on-1 mentoring flow for new designers. Instead of reading documentation, new hires went through a hands-on walk-through of file setups, component reuse guidelines, and edge-case management. If a question was asked twice, it was a signal to update our inline Figma specs or Storybook guidelines.

• New designers started publishing layouts confidently after a single onboarding session.
• Slack questions about specs and guidelines were virtually eliminated.
• Sunsetting Zeplin reduced software licensing costs and simplified the handoff workflow.

Key milestones

• 2020 — Foundational release. Built core components directly inside active tasks. Even without a formal rollout, designers saw immediate workflow gains.
• 2021 — Engineering alignment. Conducted cross-functional workshops to map shared terminology and build synchronized components in Storybook.
• 2023 — Version 2.0. Migrated styles to Figma Variables. Restructured token hierarchies to support dark mode and instant global customization.
• 2024–2025 — Scaling. The design team grew from one to four. The system’s architecture allowed new hires to onboard and contribute in a single day.

Business impact

Today, the design system serves 4 frontend developers, 4 designers, and 3 QA engineers, delivering −30% time-to-market:

• ~100 engineering hours saved monthly by developers on UI assembly.
• 6,000+ total developer hours saved over 5 years (excluding design and QA efficiency gains).

Testimonials / Stakeholder feedback

• CEO: Pointed to faster product cycles, quicker design approvals, and more predictable releases.
• CTO: Highlighted fewer UI bugs in QA, less back-and-forth during code reviews, and cleaner code.
• Product Teams: Valued a reliable, self-service UI toolkit that let them focus on UX and product logic rather than layout execution.

The outcome

The processes we built have stood the test of time, and the design system continues to scale and support the product today.