Refactoring Design System Tokens for a Multidimensional Future
Written by Mark Malek & Rebecca Hemstad
For product design and development, creating a scalable and flexible design system is paramount. In our last article, “Refactoring Token Names for Seamless Design System Maintenance ”, we described the implementation of our token system. Recently, the design team at SAS led another effort to accommodate additional user needs and preferences regarding density and themes. This article chronicles our journey from research and design through implementation, sharing the insights we gained along the way.
Initial Challenge
Our existing token system was robust, yet it lacked the versatility to support different density modes. Density in design systems is about creating flexible and adaptable UI components and layouts that allow the user to control how compactly the information is displayed. In our case, the initial request for higher-density layouts came from a data-intensive application. The feedback directly from users was that they wanted a denser, information-rich layout. The integration of density modes, along with traditional theme modes (like light, dark, and high contrast themes), necessitated a complete overhaul of our token structure.
Key Aspects of Density
The following six aspects of density are important considerations in a design system:
1. Number of Variants. Density can be offered in multiple variants, like cozy, compact, and comfortable. A design system should provide a sufficient variety of options.
2. Scalable and Responsive Designs. A design system should accommodate diverse screen sizes and devices, adjusting the density accordingly to ensure usability and accessibility across devices.
3. User Control. Users should be able to choose their preferred density. This is particularly desirable for complex applications in which users spend a lot of time, often requiring tailored experiences.
4. Consistency. Standardizing density options within a design system ensures a consistent look and feel across products and platforms even if the actual content density varies according to user preferences or device characteristics.
5. Accessibility. Users with visual impairments may require more space between elements to interact with them effectively.
6. Visual Hierarchy and Readability. A well-designed system uses density to highlight essential elements, ensuring that the interface is easy to navigate and reducing cognitive load on the user.
Product Team Research
We began our research into density variants in collaboration with product teams. After one team showed us areas in their application where higher-density layouts would benefit the user experience, we interviewed other designers to see if high-density UIs could be used more broadly. Through a series of workshops and user testing sessions, we gathered insights on how different density settings affected the user experience across various products.
We began by analyzing the use cases we gathered during our research, determining how many density modes we would need to satisfy those use cases, and what we needed to change in our library to support them. Conversely, low-density is preferred in more content-driven applications, such as dashboards, landing pages, and marketing tools, where readability and visual comfort are prioritized.
Designing with Density in Mind
Our first step in the design phase was to conceptualize how density would impact our component library. We began by analyzing the use cases we gathered during our research, determining how many density modes we would need to satisfy those use cases, and what we needed to change in our library to support them.
In this early design phase, we realized that in a high-density mode, elements like table cells and inputs need to be more compact to fit more information on the screen, whereas in a low-density mode, these elements could afford more padding and spacing. We then created preliminary mockups and prototypes to visually express these differences.
The first requirement to emerge was the need to evaluate any token that had a numeric value. These included tokens related to spacing, such as margins, padding, gaps between elements, etc. Additionally, we needed to evaluate tokens defining the sizes of elements, including widths of dialogs, input fields, cards, and other components. Typography tokens, particularly font sizes and line heights could be adjusted to make text elements more compact or spacious while maintaining readability. Tokens that defined the sizes of icons also needed to be scaled up or down to remain proportional to adjacent typography. Lastly, the border radius of elements (e.g. buttons, input fields, cards) had to be slightly adjusted depending on the density mode.
It all seemed straightforward except for the font size tokens and line heights. In theory, we would want our font sizes to scale responsively depending on device. And in that regard, it should be handled separately from density scaling. However, our system currently does not scale type in this manner.
We mitigated any accessibility issues by setting minimum font-size and line-height values. For low density, these values increased, but for compact mode, we ensured no font size was smaller than 12px. However, for Chinese locales, the default font size and line-height were increased to accommodate the characters, causing some problems.
Based on how our JSON files are loaded, any locale needing larger font size and line height (e.g. Chinese) would not be affected by density switching. While it would have been ideal to adjust font size and line height with density switching, we weren’t able to.
And here’s why: Our default font size is 14px. For compact sizing it reduces to 12px. The default font size for certain locales is 16px. It cannot be reduced to 14px due to the font-family, and it won’t visually change when switched to the more spacious density schema which is 16px. This could be solved by working with percentage shifts, but it’s complicated and something we can’t adopt now. Luckily, the future looks promising.
Naming the Density Modes
When it was time to choose names for density modes, we wanted to align with the overall tone and language of our design system, as well as the preferences and understanding of our target users. We evaluated the naming schemes of other three-variant density systems, including:
• default, tight, spacious,
• balanced, streamlined, expanded
• medium, data-dense, relaxed
• standard, compact, comfortable
We chose the conventional usage of standard, compact, and comfortable for our external user base (the terms that customers will see when they choose to modify the density mode). Our developers opted to use low, medium, high to represent the same options in the coding environment.
Transitioning to Token Names and Values
With a clear understanding of our design principles, we moved on to defining the actual values. This involved utilizing our existing naming convention that would accommodate both theme and density variations.
Re-architecting JSON Files
With our tokens finalized, the next challenge was to re-architect our JSON files to support a new multidimensional structure. Previously, our JSON files were organized by theme. However, to support independent density modes, we needed a more flexible approach and it needed to work with all Figma variable types.
We decided to adopt a domain-based structure, where tokens were categorized by their functional domains (e.g., web, product, mobile) rather than themes in our JSON structure. Our manifest files set the order in which the files are applied.
First, core:
We have a basic set of “core” tokens for each domain. These include colors, motion, shadows, sizes (borders, containers, outlines), and some typography (ratios, letter-spacing, word-spacing, italics, obliques, overflows, word-wraps, word-breaks, text-transforms, and font-weight styles). Additionally, we have a set of language-based tokens for each domain.
Then, theme, density, and language:
Products use the light theme by default, with optional dark and high-contrast themes. Then come the density mode files, followed by the languages.
When imported into Token Studio (pro subscription), we can use multidimensional themes to create separate domain libraries with collections for brand, core, density, languages, and themes.
Publishing and Integration
Once our JSON files were re-architected, we published them in the central repository, making them available for developers across the organization. To facilitate the transition, we provided comprehensive documentation and conducted workshops to familiarize the teams with the new token structure.
The response from the development teams was overwhelmingly positive. The clear and consistent token names, combined with the flexibility to choose different density modes, significantly improved the efficiency of their workflows. Furthermore, the modular JSON structure made it easier to update and maintain the tokens, ensuring long-term sustainability.
Conclusion
By incorporating density modes alongside theme modes, we created a more versatile and user-centric design system. Our collaborative approach, involving extensive testing and feedback from product teams, was crucial to the success of this project.
As design systems continue to evolve, the ability to adapt to various contexts and user needs becomes increasingly important. Our experience highlights the importance of thoughtful design, clear naming conventions, and robust testing in creating scalable and flexible design systems. We hope our journey inspires others to explore the possibilities of multidimensional design systems and to continuously strive for better user experiences.
