Refactoring Design System Tokens for a Multi-Dimensional Future
Project Overview
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 ”, our design system team at SAS laid the groundwork for implementation of our token system. Recently, we led another effort, to integrate both density and theme modes to accommodate various user needs and preferences. This article chronicles our journey, from research, design, implementation, and the valuable insights we gained along the way.
Initial Challenge
Our existing token system was robust, yet it lacked the versatility to support different density modes alongside theme. 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. Based on feedback directly from their users, the expectation was for 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
There are fundamentally six key aspects of density to consider in a design system.
1. The first is the number of variants. Density can be offered in many modes, for example, compact and comfortable.
2. Secondly, effective density implementation plays a crucial role in creating scalable and responsive designs. A design system should accommodate various screen sizes and devices, adjusting the density accordingly to ensure usability and accessibility across devices.
3. Thirdly, enabling our users to choose their preferred density enhances user control. This is particularly desirable in complex applications where users spend a lot of time and require tailored experiences.
4. Consistency across products is the fourth key aspect. By standardizing density options within a design system, we can ensure a consistent look and feel across our products and platforms even if the actual content density varies according to user preferences or device characteristics.
5. Accessibility is another key aspect. Users with visual impairments may require more space between elements to interact with them effectively. A design system that considers this can better meet accessibility standards.
6. Lastly, density affects visual hierarchy and readability. A well-designed system uses density to highlight essential elements and ensure that the interface is easy to navigate. This reduces cognitive load on the user.
Product Team Research
We began by collaborating with the initial product team that asked for a high-density mode. This team explained the user request and showed us areas in their application where higher-density layouts would benefit the experience. We decided to expand this conversation and interview other product 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 learned that high-density is particularly favored in layouts which required comparing models and code editing tools, where screen real estate is at a premium. 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 research and determining what needed to change to support three density modes.
In this discovery 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, which helped us gain deeper clarity into the scope of what we needed to accomplish.
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, card, 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 (like 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, and this is why it became integral to our density requirements.
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 (like Chinese) would not have these changes affected by density switching. While it would have been ideal to adjust font size and line height with density switching, we had to compromise.
To put it in a nutshell, 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. Before you say, hey wait, can’t you solve this by working with percentage shifts? I’d reply, yes, but it’s complicated and something we can’t adopt now. But the future looks promising.
Naming the Density Modes
When it comes to choosing names for density modes, we knew it needed to align with the overall tone and language of our design system, as well as the preferences and understanding of our target user base. We evaluated several scales currently adopted by 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.
This naming convention ensured that our tokens were both descriptive and scalable, allowing for easy maintenance and future expansion.
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 primarily by theme. However, to support independent density modes, we needed a more flexible approach and it needed to work with Figma variables.
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 implementation brainstorming 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. The 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 multi-dimensional design systems and to continuously strive for better user experiences.
