Sachin Barnwal
Back to Home

Tier 5 Enterprise Design System

Establishing the organization's first "Single Source of Truth," reducing design debt and increasing shipping velocity by ~3x.

Context

Early-career milestone

Role

Sole Owner & Lead

Outcome

SSOT Established

Impact

~3x Velocity Increase

01. The Challenge: Scaling Without a Foundation

Joining Tier 5 was my introduction to an Agile environment. While I quickly adapted to the sprint cadence, I identified a systemic issue affecting our velocity: Design Debt.

Because we lacked a central library, every feature was designed from scratch or by copying existing screens. This led to:

Visual Fragmentation

Inconsistencies were rampant; for example, Input borders varied between #556677 and #948234 across different table rows.

Subjective Debates

"Designer vs. Developer" friction was high, centered on which implementation was "correct" rather than following a standard.

Operational Waste

We were spending sprint time reinventing patterns rather than solving user problems.

02. The Initiative: Stepping Up

When I proposed a Design System to standardize our output, the Product Manager initially hesitated due to time constraints ("We don't have time for that").

However, I persisted, advocating that a Single Source of Truth (SSOT) would ultimately save time by eliminating the constant back-and-forth. Leadership agreed to a pilot. During the kickoff meeting with the Product and Engineering leads, when asked who could drive this, I volunteered to take full ownership. Despite having never built a system before, I had researched the methodology extensively and was confident I could execute it. I moved to the whiteboard and mapped out the strategy immediately.

03. Architecture & Token Strategy

We started with a comprehensive audit to establish a baseline. Referencing the Tier 5 Color Structure, I established a "Primitive" layer. I avoided arbitrary hex values in favor of a clear naming convention that separated Brand (Violet, Aqua) from Semantics (Red/Error, Yellow/Warning).

Token Structure

1. Scale Definition

To ensure flexibility for interactions, I defined a scale for every root color using a predictable modifier syntax:

  • violet-lighter
  • violet-light
  • violet-default
  • violet-dark
2. Accessibility Compliance

Crucially, we tested every tint and shade against WCAG 2.1 contrast ratios. This ensured that when we mapped tokens to functional elements, they remained accessible across all SaaS products.

3. The Semantic Layer

To make the system usable for developers, we mapped Root Tokens to semantic aliases (e.g., Background-primaryviolet-default). This abstraction allowed us to manage themes easily.

04. Component Construction & Validation

Once the foundations were set, we moved to the molecular level. Based on our initial audit, we prioritized the high-impact components used across our enterprise SaaS products.

Core Components

We standardized Inputs, Buttons, Cards, Modals, Drawers, and Complex Data Tables.

Stress Testing

We didn't design these components in isolation. I applied the new components to existing, high-density screens to "stress test" the system. We asked: Does the hierarchy hold up? Are the table rows legible?

Refinement: This practical application revealed necessary tweaks in our token values, allowing us to refine the foundations before handing them off to development.

05. Future-Proofing: The Strategic Pivot

Midway through the project, Figma released Native Variables. At the time, we were nearing completion using the Token Studio plugin. I faced a critical decision: finish fast with the plugin or pivot to native features. I chose to pivot.

The Logic

Relying on a third-party plugin created an external dependency for the engineering team. Native variables would ensure better long-term performance and easier maintenance.

The Execution

I utilized a migration script to convert our styles to variables, successfully removing the plugin dependency before the final handoff.

06. Governance & Implementation

A Design System is only effective if it lives in the code, not just the design file.

📚

Storybook Integration

We collaborated closely with Front-End developers to implement the system in Storybook, ensuring code components matched design tokens 1:1.

🔄

Governance

We established a clear Changelog to track version updates, ensuring the system remained a living product rather than a static one-time delivery.

07. Results & Impact

This project transformed how the Tier 5 product team operated:

🚀

3x Velocity

By moving to a "lego block" workflow where we simply called existing components, we reduced design-to-dev handoff time significantly.

🎯

Zero Subjectivity

The "which hex code do I use?" conversations dropped to zero. Developers had a clear reference.

🤝

Culture Shift

It bridged the gap between Design and Engineering, turning a contentious relationship into a collaborative one.

Acknowledgments

While I led the execution of this initiative, this all wouldn't be possible without the support and guidance of my Team Leader, Product Manager, and my fellow designer colleagues who trusted the vision and adopted the system.

Next ProjectAll Works