Spectrum: the foundations

Overview

The Spectrum design system is aimed toward the unification of an entire enterprise-level cross-platform product suite for the Creative Cloud, Document Cloud, Experience Cloud, and other products extending into Adobe's third-party developer ecosystem. Spectrum is a single-source-of-truth for design tokens, artifacts, components, documentation, and more.

My role

The majority of my tenure at Adobe has been spent building, supporting, and evolving the Spectrum design system. Over the years, I have taken on many different roles that have been critical in its growth and success.

Primary roles and responsibilities:

• Product management
• Design tokens lead
• Foundational systems design
• Component design
• Design prototyping
• Documentation
• Framework partnerships

Product management

I fulfilled this role during the beginning phase of Spectrum's formalization. The system already had a set of distinct, yet dispirate resources used by various product teams. My objectives were to identify the key areas of opportunity to help drive product success with Spectrum. This included gathering requirements from product teams, evaluating the landscape of framework and technology support, and identifying direction for the Spectrum product.

I was able to provide insight into the tech landscape and identify core frameworks teams to support for the biggest early impact for Spectrum. I created mechanisms in Jira and Confluence for tracking the process and status for multi-platform component implementation. These mechanisms were enhanced to create a view of component usage in a handful of high profile products. This helped to give a view of which components were most used, where they were used, and their status regarding implementation over time.

Component statuses captured in a wiki for tracking implementation and reviews.

Design tokens lead

Tokens strategy

I directed the strategy for tokens that grew into a systems-oriented authroing environment, where conditional logic and inheritance was a direct representation of design intent. This led into innovative solutions and ensured stability in this strategic approach for our consumers.

A JSON file defines Action button's API. The template file is for authoring tokens and captures conditional values based on any of the API options for the component.

Token naming and standards

Standardized names for common component attributes, with specifications on how they relate to component design. This ensured a consistent naming convention for tokens, as well as clear expectations for engineers regarding what a token is relative to.

A primary goal was to standardize on an agnostic naming convention for the parts of a component, that way we had a unified or common language when speaking with engineers on any team. The mapping of these attributes to platform-specific attributes along with visual aids helped resolve questions about how they related.

Design token wiki defined core "attributes" and relative information for each platform.

Formalized a naming convention and data structure for design tokens. Tokens were expressed in flat variable names and structured JSON with a consistent hierarchical approach.

The naming convention was enforced via code within the design token system. Any of the standard API options used in a component would be automatically sorted to the proper order, and states were appended to the end of tokens as specified in our standard. This provided ability to generate tokens, automate visual regression testing, and generate styles for component implementations.

Component tokens were not hand-written. Attributes were written with data mapping their token use based on API properties, and the tokens would be automatically generated within the tool itself. This made component-level token authoring a simple process focused on mapping styles without the added worry of conforming to the standard naming conventions.

Naming conventions were documented in a wiki, but enforced through code in our token system.

Tokens documentation, implementation, and review

Created detailed specifications for components to assist in token authoring and token consumption. These specification files illustrated every component-level token for the component, any related aliases they used, the core (or "global") tokens, and an example token value for the default color theme and platform scale.

Specificity in these files was necessary because at the time there was no sufficient support for specs and design tokens in UI design tools. This also provided a high degree of detail in the information we captured, which helped teams support multiple themes and platforms, which secondary design inspection tools could not properly surface.

Detailed specifications provided values and tokens for each component in every theme and each platform scale.

I worked in collaboration with frameworks teams on iOS, Android, UWP (Windows), CSS, React, Web-Components, and several internal frameworks to implement Spectrum components. This included gathering requirements for tokens, fixing and evolving the data in design tokens, and reviewing individual component implementations for proper token usage.

Early work consisted of evaluating screenshots of every component variation in each interactive state for every supported theme and platform. However, I worked with teams to automate this process as much as possible. Builds from each library automatically exported these screenshots. Once a component was approved, the screenshots from the approved build could be used for visual regression testing.

Foundational systems design

Designed and played a key role in authoring foundational design systems such as typography, color, spacing, and component (UI) iconography. I also worked on the creation and evolution of many other sub-systems implemented in our components, such as selection styling and interaction behavior, a system for common component attributes such as size, spacing, padding, and responsive behavior for all list-like components.

Typography system

Defined a typographic scale with type-relative margin sizes for long-form text in order to ensure proper balance and visual rhythm of typography. This included size pairing recommendations for creating hierarchical content.

Icon scaling system

Created a system for scaling our component icons (UI icons). These icons are specifically used in the design of components themselves, such as chevrons for pickers, and checkmarks for check boxes. We wanted to ensure that these icons scaled in size proportionally to the type scale. However, stroke width for icons needed scale at a different rate in order to hold an appropriate visual weight when compared to accompanying text.

I created a prototype to evaluate and define the system that scales icon strokes at a proportionally different rate than the icons scale themselves. This enabled us to refine icon shapes systematically, accounting for a proper visual weight as icons changed in size.

Color system

Created an adaptive color system to support a wide range of user needs. The color system was contrast-based in order to anchor our definitions in accesibility. The tool Leonardo was created to help facilitate this work, and was pivotal in accomplishing what I was able to create for Spectrum.

One unique quality to Spectrum's adaptive theme is that the target contrast ratios passed to Leonardo are generated mathematically. The formula to generate the target contrast ratios is based on a percentage of the available contrast gamut for the current brightness of the theme. In other words, the target ratios adapt in order to retain a perceptually linear distribution of lightnesses, meet or exceed contrast minimums, and to generate colors that do not exceed the available amount of contrast.

Spacing system

Created a basic spacing system to be used when creating layouts. These spacing increments provide flexibility and balance for a variety of design scenarios. The scale was evaluated against existing design system patterns and product designs in order to ensure the system met expectations and needs.

Component design

Component design included inception of new components, as well as refining contributions from internal teams in order to create a stable component

Design process included gathering requirements across multiple products, then amalgamating requirements into a feasible middle-ground that could be used to define a core, flexible component that can be used to meet all other requirements.

Standardized API for components

Formalized options and created new ones evolved into what our team called a "design API". The design API is a set of common properties and options for components. This API predictably defines what options are available and which are mutually exclusive or can be combined with others.

The design API provided clear guidance for engineering teams implementing components, so that every available variation was presented in each framework as design intended. Options and properties were named in a way that could easily translate to platform terminology. The design API also defined types of properties, such as boolean, enumeration, or custom values. This ensured all implementations were consistent in how variations were implemented.

A secondary benefit to the design API was that it created a clear framework for our team to define component options in documentation. Sections could be predictably written based on what options we decided a component would support. The sections in Spectrum components' "options" section were also appended with a "table of options", which is a tabular representation of each component's API.

The design API was also pivotal in standardizing our design tokens, which could be enforced through code and used to generate data for all possible permutations of a component.

Xd file with defined API properties and options for components. These options surface in tokens and website documentation for each component.

Windows high contrast mode

Provided redesigned components themed in Windows High Contrast Black theme. The purpose of this work was to provide engineering guidance regarding the Windows color keywords to use in implementation. Worked with the Spectrum-CSS and accessibility teams to ensure the designs met expectations for users who rely on High Contrast Mode, as well as using common conventions for the Windows keywords.

Ultimately this was a unique translation of Spectrum's design language. Semantics and use of color had to conform to a more simplified semantic set, which needed to rely on OS keywords for end-user customization.

Output from this effort surfaced as guidance and collaboration with teams, along with custom UI kits available on Spectrum's website.

Partial view of Windows high contrast mode UI kit for Checkbox.

Case study: Tree view

Tree view is a core component to many Adobe experiences. In the Experience Cloud, Tree view is a mechanism for file and asset management. In the Creative Cloud, Tree view is customized into the many forms of Layers panels.

The component needed to be designed to be flexible with clear guardrails. Over 50 requirements were gathered across multiple teams across clouds to identify core functional aspects of Tree view. Many requirements were resolved in the core design of the component, whereas other requirements were resolved with usage guidelines on how to properly extend the component.

This was an extremely important component to properly design for Spectrum, as Tree views are used for core aspects of user experiences with very different purposes.

Example view of two common use cases for Tree view: asset management and layers panels.

Documentation

Documentation is a critical aspect of Design systems, and every decision made was documented in some fashion. There were two primary modes of documentation: internal team documentation and external consumer documentation.

Internal team documentation

Core elements of how Spectrum's design language is constructed were documented in the form of annotated Xd files. Our team relied on these "foundational" Xd files for a number of important aspects of how we design. I defined and documented the system we use for creating any list-like component, with specificatoins for possible API properties like size and density. Components that leverage this template include List view, Tree view, Side navigation, Column view, and accordion.

"Stack items" Xd template file with anatomy, areas, and specifications for size and density options.

External consumer documentation

Every element of Spectrum's design language that was consumer-facing was documented on the Spectrum website. I contributed to documentation for every component or foundational system that I designed, including Tree view, Breadcrumbs, Color, and more.

This documentation was created for external use, so it needed to be clear, organized, and actionable. This included writing copy, creating visuals, and in some cases refining the information architecture for the site itself.

Documentation on Spectrum.adobe.com

Design prototyping

Prototyped tools and examples to assist in complex design problems such as scaling for dynamic type and zoom, responsive opacity checkerboard pattern, responsive iconography styling, color generation and evaluation tools, and personalization features for Adobe products.

Prototype for evaluating adaptive design rules for list items, their component parts, and how things scale relative to iOS dynamic type and zoom.

Framework partnerships

Collaborated with frameworks for CSS, React, Angular, Vue, iOS, macOS, UWP, and 4+ internal Adobe frameworks. Leveraged token system strategy to aid in cross-communication with frameworks teams and evaluating their implementations of Spectrum.

Set up a recurring cadence of meetings for questions, review, and sharing information once a week. These meetings became pivotal in collaboration across platform teams for designing components and properly supporting product teams.