01

HP Indigo Design System

01

HP Indigo Design System

01

HP Indigo Design System

As the Design System Lead for HP Indigo, my primary challenge was transforming a fragmented design environment, characterized by inconsistent standards and technological complexity, into a unified, scalable platform.

The Goal: Introduce new systematic thinking to the organization and streamline workflows for all key stakeholders, achieving maximal variable management and maximum connectivity across the entire system.

Key Beneficiaries:

  • Designers – Easier access to the correct tokens and visual verification of component consistency.

  • Developers – Clear documentation and implementation guidance, simplifying integration into technologies like WPF and React.

  • QA & DS Managers – Tools for auditing, identifying inconsistencies, and tracking system health.

Role:

Design System Management, Design Ops

Industry:

Digital Press Machines

Duration:

2024-2026

Overview

When I joined HP Indigo, the design and development ecosystem was scattered across tools, files, and methods. Sketch, Illustrator, and XD were used in parallel; Zeplin served as the main handoff tool, but it was slow, static, and disconnected from live variable management. Developers worked in both React and WPF, designers in multiple design languages, and QA was left to bridge mismatched interfaces.

My mission was to transform the fragmented environment into a unified, systematic, and scalable design system - one that connects design, development, and QA through shared logic, variable hierarchies, and consistent governance.

Challenges

The pre-existing environment revealed how design debt can accumulate when systems evolve without shared principles.

Key issues:

  • Designs were still maintained in Sketch, built ad hoc with no atomic structure.

  • Components were created to look right, not to code right.

  • Each series was designed differently, with no unified color grading or typography.

  • Variables were shallow - defined inconsistently, often semantically without structure.

  • Zeplin was the main bridge, forcing manual screen uploads and no support for token changes.

  • Developers and designers lacked alignment on property naming, spacing, and component logic.

  • Many legacy files contained outdated components - artifacts of a 4-year-old project with “if it works, don’t touch it” inertia.

  • Transitioning to Figma created tension: some feared change, others feared redundancy.

Why move to Figma:

  • Live collaboration and variable synchronization.

  • Immediate visualization of tokens and components.

  • Reduction of manual overhead.

  • Centralized access to global, series, and product-level libraries.

My Approach

The New System: Designing Systematically

To resolve fragmentation, we rebuilt the Design System from zero - both conceptually and structurally.


Establishing Foundations

We started by defining the atomic hierarchy — tokens → components → systems — focusing on:

  • Color unification: Consolidating and defining accessible color frameworks, Gradients, Styles and Effects.

  • Typography and sizing alignment: Creating consistent scales for all UI layers.

  • Component hierarchy: From atomic icons to complex popups, every part followed the same logic. Built in mind both of ease of use for the designers, while fitting a direct conversion to code elements.

Establishing Foundations

We started by defining the atomic hierarchy — tokens → components → systems — focusing on:

  • Color unification: Consolidating and defining accessible color frameworks, Gradients, Styles and Effects.

  • Typography and sizing alignment: Creating consistent scales for all UI layers.

  • Component hierarchy: From atomic icons to complex popups, every part followed the same logic. Built in mind both of ease of use for the designers, while fitting a direct conversion to code elements.

Establishing Foundations

We started by defining the atomic hierarchy — tokens → components → systems — focusing on:

  • Color unification: Consolidating and defining accessible color frameworks, Gradients, Styles and Effects.

  • Typography and sizing alignment: Creating consistent scales for all UI layers.

  • Component hierarchy: From atomic icons to complex popups, every part followed the same logic. Built in mind both of ease of use for the designers, while fitting a direct conversion to code elements.

The Three-Layer Variable Model

We built variables across three layers, ensuring clarity and scalability:

  • Primitive Variables – raw values (e.g., Purple/100).

  • Semantic Variables – contextual values (e.g., Button/Default/Fill).

  • Specified Variables – implementation level (e.g., Filters_Button/Default/Fill).

This model supports mode conversion (Light/Dark, Kedem/Simplified) and future expansions across products and platforms.

The Three-Layer Variable Model

We built variables across three layers, ensuring clarity and scalability:

  • Primitive Variables – raw values (e.g., Purple/100).

  • Semantic Variables – contextual values (e.g., Button/Default/Fill).

  • Specified Variables – implementation level (e.g., Filters_Button/Default/Fill).

This model supports mode conversion (Light/Dark, Kedem/Simplified) and future expansions across products and platforms.

The Three-Layer Variable Model

We built variables across three layers, ensuring clarity and scalability:

  • Primitive Variables – raw values (e.g., Purple/100).

  • Semantic Variables – contextual values (e.g., Button/Default/Fill).

  • Specified Variables – implementation level (e.g., Filters_Button/Default/Fill).

This model supports mode conversion (Light/Dark, Kedem/Simplified) and future expansions across products and platforms.

Supporting All Levels of the Organization

We defined three structural layers:

  • Global DS: shared atoms and molecules across all products.

  • Series DS: design and behavior tailored for product families.

  • Product DS: local overrides when unique features required customization.

Each level was versioned, governed, and connected via changelogs, ensuring transparency between design and code.

Supporting All Levels of the Organization

We defined three structural layers:

  • Global DS: shared atoms and molecules across all products.

  • Series DS: design and behavior tailored for product families.

  • Product DS: local overrides when unique features required customization.

Each level was versioned, governed, and connected via changelogs, ensuring transparency between design and code.

Supporting All Levels of the Organization

We defined three structural layers:

  • Global DS: shared atoms and molecules across all products.

  • Series DS: design and behavior tailored for product families.

  • Product DS: local overrides when unique features required customization.

Each level was versioned, governed, and connected via changelogs, ensuring transparency between design and code.

Building a Protocol: Tools for Connection

Standard Figma tools couldn’t manage Indigo’s complexity, so we built an internal ecosystem of tools and plugins to support our daily work.

Plugin

Function

Description

The Variabler

Generate Semantic Layers

Automatically creates semantic variable relationships based on defined naming and structure.

The Stripper

Clean & Audit

Flattens variable paths to primitive layers, removing inconsistencies.

The Mapper

Visualize Dependencies

Displays variable alias chains for debugging and auditing.

The Organizer

Maintain Consistency

Batch-renames, audits, and enforces naming conventions across files.

The Logger

DS changelog tracker

Tracking and formatting the DS changes to be published in the changelog

This custom suite became the operational framework that allowed our DS in Figma to scale in an enterprise environment.



Building a Protocol: Tools for Connection

Standard Figma tools couldn’t manage Indigo’s complexity, so we built an internal ecosystem of tools and plugins to support our daily work.

Plugin

Function

Description

The Variabler

Generate Semantic Layers

Automatically creates semantic variable relationships based on defined naming and structure.

The Stripper

Clean & Audit

Flattens variable paths to primitive layers, removing inconsistencies.

The Mapper

Visualize Dependencies

Displays variable alias chains for debugging and auditing.

The Organizer

Maintain Consistency

Batch-renames, audits, and enforces naming conventions across files.

The Logger

DS changelog tracker

Tracking and formatting the DS changes to be published in the changelog

This custom suite became the operational framework that allowed our DS in Figma to scale in an enterprise environment.



Building a Protocol: Tools for Connection

Standard Figma tools couldn’t manage Indigo’s complexity, so we built an internal ecosystem of tools and plugins to support our daily work.

Plugin

Function

Description

The Variabler

Generate Semantic Layers

Automatically creates semantic variable relationships based on defined naming and structure.

The Stripper

Clean & Audit

Flattens variable paths to primitive layers, removing inconsistencies.

The Mapper

Visualize Dependencies

Displays variable alias chains for debugging and auditing.

The Organizer

Maintain Consistency

Batch-renames, audits, and enforces naming conventions across files.

The Logger

DS changelog tracker

Tracking and formatting the DS changes to be published in the changelog

This custom suite became the operational framework that allowed our DS in Figma to scale in an enterprise environment.



Governance with TokenFlow

All the logic and variable mapping culminated in TokenFlow, the analytical and governance tool designed to visualize and maintain the entire DS ecosystem.

TokenFlow enables:

  • Dependency mapping: visualize every alias, component, and token relationship.

  • Mode-aware inspection: test behavior across themes and platforms.

  • Quality assurance: detect duplicates, orphans, and circular references.

  • Usage analysis: identify which components depend on which tokens.

TokenFlow became the final layer of the protocol — a QA, documentation, and governance platform in one

Governance with TokenFlow

All the logic and variable mapping culminated in TokenFlow, the analytical and governance tool designed to visualize and maintain the entire DS ecosystem.

TokenFlow enables:

  • Dependency mapping: visualize every alias, component, and token relationship.

  • Mode-aware inspection: test behavior across themes and platforms.

  • Quality assurance: detect duplicates, orphans, and circular references.

  • Usage analysis: identify which components depend on which tokens.

TokenFlow became the final layer of the protocol — a QA, documentation, and governance platform in one

Governance with TokenFlow

All the logic and variable mapping culminated in TokenFlow, the analytical and governance tool designed to visualize and maintain the entire DS ecosystem.

TokenFlow enables:

  • Dependency mapping: visualize every alias, component, and token relationship.

  • Mode-aware inspection: test behavior across themes and platforms.

  • Quality assurance: detect duplicates, orphans, and circular references.

  • Usage analysis: identify which components depend on which tokens.

TokenFlow became the final layer of the protocol — a QA, documentation, and governance platform in one

Adoption and Cultural Shift

Building tools was only half the challenge; implementing them across teams required teaching and advocacy.

  • Led cross-team workshops for designers, developers, and QA to understand the three-layer system.

  • Developed documentation and versioning guides defining major vs. minor changes.

  • Created a governance protocol for updates — defining ownership and review loops for design → dev → QA.

  • Held direct discussions with Figma’s own DS team, sharing our versioning strategy. They validated our structure as highly scalable, though their platform hadn’t yet reached that level of DS complexity.

Through a structured rollout and iterative education, the system became not just a set of components, but a shared mindset across HP Indigo.

Adoption and Cultural Shift

Building tools was only half the challenge; implementing them across teams required teaching and advocacy.

  • Led cross-team workshops for designers, developers, and QA to understand the three-layer system.

  • Developed documentation and versioning guides defining major vs. minor changes.

  • Created a governance protocol for updates — defining ownership and review loops for design → dev → QA.

  • Held direct discussions with Figma’s own DS team, sharing our versioning strategy. They validated our structure as highly scalable, though their platform hadn’t yet reached that level of DS complexity.

Through a structured rollout and iterative education, the system became not just a set of components, but a shared mindset across HP Indigo.

Adoption and Cultural Shift

Building tools was only half the challenge; implementing them across teams required teaching and advocacy.

  • Led cross-team workshops for designers, developers, and QA to understand the three-layer system.

  • Developed documentation and versioning guides defining major vs. minor changes.

  • Created a governance protocol for updates — defining ownership and review loops for design → dev → QA.

  • Held direct discussions with Figma’s own DS team, sharing our versioning strategy. They validated our structure as highly scalable, though their platform hadn’t yet reached that level of DS complexity.

Through a structured rollout and iterative education, the system became not just a set of components, but a shared mindset across HP Indigo.

Conclusion

By introducing systematic thinking, variable hierarchies, and DS-driven workflows:

  • Design-developer alignment improved dramatically.

  • Redundancy in color and component definitions was reduced by over 70%.

  • QA found inconsistencies faster through TokenFlow’s tracking.

  • Designers moved from screen-based design to system-based creation.

The HP Indigo Design System now operates as a living framework — bridging creativity, engineering, and governance — with TokenFlow ensuring that scalability and consistency are no longer competing goals but unified realities.