RESEARCH

Restructuring the HPE Tokens Library

Optimizing Variable Access and Streamlining Design System Adoption

PROJECT OVERVIEW

ABOUT

This case study outlines the approach taken to restructure HPE’s token libraries, focusing on optimizing the way Figma variables are managed and accessed by different designer teams. The goal was to create an organized structure that caters to the needs of both HPE Design System designers and UX Product designers while ensuring scalability, accessibility, and efficiency.

TEAM

Taylor Seamans - Developer, Researcher

Joelle Gregory - UX/UI Designer, Researcher

Oliver Plunklett - UX/UI Designer Researcher

Matt Glissmann - Developer

PROBLEM & SUCCESS CRITERIA

PROJECT SCOPE

HPE’s design system is a vital asset for ensuring consistency across the company’s suite of products. The token libraries, which define visual properties like color, typography, and spacing, were becoming cumbersome to manage due to the lack of clarity in the structure. Designers were encountering challenges with access control, flexibility, and integration between variables and components. The restructuring effort aimed to solve these challenges by creating a more modular, scalable, and easy-to-manage token system.

CHALLENGES

Access Control and Flexibility: Different designer teams needed varying levels of access to the token libraries. HPE Design System designers required access to all token types (primitive, semantic, and component variables), while UX Product designers only needed access to semantic variables.
Scalability of the System: The existing token library lacked a clear structure that could easily scale with HPE's growing product ecosystem.
Managing Complexity: With the need to consolidate variables and components, managing the design system with the single library structure in Figma was becoming increasingly complex.

GOAL

Determine how we should structure our Figma variables / publish them such that the following success criteria can be met:

For Design System designers, they have access to primitive, semantic, and component variables
For UX Product designers, they only have access to the "semantic" variables

Approaches

The restructuring initiative was guided by a set of goals focused on creating clarity and flexibility, while ensuring alignment with HPE's design principles.

SOLUTION 1:

Consolidating Variables and Components into a Single File

Back up styles and consolidate all variables and components into a single file. Designers should exclusively utilize styles, while we discard layout variables that are not contained within components for right now.

In short, designers continue to consume the design system through styles and components and we back up all components/styles with variables and add more slot style components for more flexibility.

Pros:

Facilitated a smoother transition for designers to adapt to variables with minimal effort.
Consolidated all design system assets in a single location.
Enhanced the design system by providing clearer guidelines on variable placement and enforcing more consistent usage.

Cons:

Navigating a large Figma file could become challenging as the complexity of the system grows.
Designers would be restricted from using variables outside of the styles or components.

SOLUTION 2:

Separate Collections into Distinct Files ✅

Separate collections into two or more distinct files within the design system: an internal file housing the Primitive and Component collections, and an external file dedicated to Semantic collections.

Pros:

Teams could enable specific libraries tailored to their unique needs (e.g., design system vs. product designers).
Centralized management of tokens, reducing the number of files while still maintaining flexibility.
Enabled publishing from primitives to semantic variables and from semantic to component variables.
Improved usability for both design system and product teams by optimizing scoped values for each group.

Cons:

Further exploration is needed to determine how modes could be effectively utilized at both the product designer and design system levels.
Increased number of files to manage, which could introduce complexity.
Any changes to primitive variables would require a new publication and updates to all dependent files (semantic, component, designer files).

SOLUTION 3:

Developing a Custom Figma Plugin

Create a plugin

Many design systems leverage custom-built Figma plugins to aid designers in utilizing variables effectively. Many design systems, such as Booking.com, leverage custom-built plugins to help automate updates and streamline the design process. This solution would centralize variable mode changes into a single interface for easier access.

Pros:

If developed correctly, a plugin could significantly reduce the effort needed to implement updates from the design system.
The plugin could streamline the management of variable modes in one interface, reducing friction for designers.
It could address current limitations in Figma’s native functionality, enhancing the overall design system experience.

Cons:

Developing such a plugin requires substantial resources and time, which might not be feasible for the alpha release.
This approach would require a dedicated design system team, which might not be available given the current resource allocation.

Things to Consider

The restructuring initiative was guided by a set of goals focused on creating clarity and flexibility, while ensuring alignment with HPE's design principles.

MODES/THEME MANAGEMENT

Careful planning would be needed to ensure modes (e.g., dark/light themes) are handled effectively across the system, especially at different user levels.

MANAGING MULTIPLE FILES

The challenge of maintaining multiple Figma files while ensuring updates propagate seamlessly across dependent libraries would need thorough testing and management.

UPDATES ACROSS FILES

A workflow to manage and test the propagation of updates, especially from primitive to semantic and component tokens, needs to be established to prevent outdated variables from being used.

Testing & Iteration

ARCHITECTURE TESTING FOLDER

Testing was crucial for validating the various solutions. A Theme Testing Folder was used to assess the viability of each solution, ensuring that changes could be tested in a controlled environment before full implementation. The feedback from design system and product teams was gathered to refine the approach, focusing on ease of use, flexibility, and accessibility.

Theme & Modes

VIEWPORT & COLOR

Based on the results of our testing, I discovered that variables can inherit modes from the collections they reference. For instance,if the semantic level includes modes for large and small viewports as well as light and dark themes, and component-level variables are mapped to tokens from the semantic collection, the component-level variables will automatically inherit these modes, even if no modes are explicitly defined at the component level.

DENSITY

Introducing density modes brought its own set of challenges, as it required variables to respond to two sets of modes simultaneously. With viewport and color modes, the application was straightforward: viewport modes only affected numerical values such as spacing, sizing, and radius, while color modes exclusively applied to visual properties like background fills and strokes. However, density modes combined these dimensions, creating the potential for tokens to respond to both density and viewport—for instance, accommodating a compact view on a small screen size. This added complexity to the structure and required careful consideration of how modes interact and cascade.

Density

WHAT IS DENSITY?

Density refers to the amount of content visible on a page at any given time. It can be adjusted to provide a user-tailored experience by influencing the spacing between and within components, without altering component sizes (which are defined by viewport).

High-density pages display more content with tighter spacing.
Low-density pages use more spacing, presenting less content for a more open design.

KEY PRINCIPLES

User Preference: Density should align with user-defined preferences, offering a "default" and adjustable modes.
Consistency: Density should be applied cohesively across regions—e.g., a "compact" table should pair with "compact" buttons.
Responsiveness: Density differs from viewport responsiveness, which adjusts designs for screen size and form factor.

4 MAIN TOKEN CATEGORIES

Based on all of the information above, all of our elements fall into one of these four categories:

SOLUTION

With these four categories in mind, we need a token mapping strategy that supports each individual requirement. Here's the approach I developed:

Viewport Only
Since our semantic token collection already defines modes for medium and small viewports, we don’t need to create a new collection. Tokens that respond only to viewport changes can directly reference the semantic dimension spacing collection.

Density Only
Most tokens that respond to density are component-specific. Therefore, setting density modes at the semantic level would disrupt the existing token flow. Instead, it makes sense to define density modes at the component level. More specifically the Element collection as most of our component spacing tokens already reference this collection.

Viewport and Density
Tokens that need to respond to both viewport and density will also reference the Element collection. However, for these cases, we can introduce new tokens (e.g., btwnButtons or btwnCardsGap. These tokens will reference the semantic collection rather than the static primitive spacing set, ensuring they remain dynamic.
For more on this concept, reference Token-Specific Mapping.

Static (No Responsiveness)
Elements that don’t need to respond to either viewport or density will directly reference the Primitive static spacing set.

TOKEN-SPECIFIC MAPPING

For components or tokens that need to adapt to both density and viewport, this will be managed through token-specific mapping.

For example, elements like the gaps between buttons or between cards must respond to both. In such cases, the tokens will reference the semantic token set instead of the primitive static set. However, static mode will continue to utilize static tokens from the primitive set.

This ensures that static mode remains fixed, unaffected by changes in density or viewport, while allowing other modes to maintain their responsiveness.

TOKEN ARCHITECTURE

Conclusion

OUTCOME

The implemented density framework delivered:

Scalability: Centralized tokens within the element collection, simplifying management and future adaptability.
Consistency: Cohesive density application across components and regions.
Flexibility: Supported user preferences while maintaining system-defined responsiveness.
Efficiency: Reduced token duplication by aligning dual-responsive tokens with existing semantic mappings.

CONCLUSION

The design system's density framework strikes a balance between adaptability and scalability, providing users with a customizable experience while ensuring consistent and cohesive design. By aligning token architecture with user and system needs, the framework supports a robust, future-proof design system.