Designing design systems: Scaling a product design system for marketing interfaces

How the Consonant team reinterpreted Spectrum's product design guidelines for Adobe.com

Graphic by Emma Gustafson

Design systems like Spectrum provide the atoms and molecules—the color tokens, typefaces, type hierarchy, styling tokens, shadows, base iconography and core UI like buttons—used by designers and engineers to craft and scale consistent product experiences. But the very specific content needs of marketing can't always be addressed using the components, patterns, and principles that provide the foundation for a company’s in-product experiences.

That’s where Consonant comes in. Consonant is Adobe’s marketing design system. It sits on top of Spectrum, Adobe’s product design system to support the content needs of marketing. By extending Spectrum to accommodate the templates and patterns of marketing it infiltrates every user experience and customer journey on Adobe.com—from search through product use.

The process for designing that visual connection between Adobe marketing and Adobe products means clearly defining Adobe's marketing content needs then reinterpreting Spectrum's product design system components for the needs of marketing assets.

How marketing experiences differ from product experiences

Marketing content is fast, fluid, and content heavy. Although what comprises “marketing content” might vary slightly for everyone, the content on Adobe.com generally fits into three categories: product marketing (images and copy that support people looking to learn more or buy); brand campaigns (splashy, advertising-like content and partnerships); SEO pages (information-dense, product-oriented pages for search engines). The needs of these content types are different from product needs in four distinct ways:

• The design system patterns and components that provide clarity in products can be too subtle for the information hierarchies that help users meet their research or purchase goals in the information-dense world of marketing.
• Product experiences tend to be utilitarian and product design systems assist people in their use, while the expectation for marketing experiences is that they will be expressive representations of the brand.
• Marketing experiences must create a visual foundation for the coexistence of multiple products with different marketing approaches. Guidelines based on a design system allow for diverse implementation while maintaining visual parity.
• For sites like Adobe.com, where web marketing and web products are adjacent, marketing design systems can create more cohesive customer journeys by employing a visual language that foreshadows in-product experiences and persists when a customer returns to the marketing site.

Beyond the more obvious visual challenges, marketing content also requires strong governance:

• Web content designers, both in-house and at agencies, often work with large content teams which creates the need for a prescriptive, templatized workflow.
• Responsive patterns must have SEO tech built into them and, because of audience breadth, support for accessibility, left-to-right languages, technology differences, and performance requirements (web components from product design systems can be too heavy for the content on marketing pages to load quickly).
• The varying needs of tutorial (instructional materials), community (user forums), and editorial (stories and perspectives) content require a visual approach that’s not always as uniform as product design.
• Design systems that support marketing content must be coded for the website and the content management system (CMS) so they can be used by graphic designers, writers, and web authors.
• The content and user interfaces of marketing pages are continually tested and updated based on the needs of marketing-oriented metrics like traffic or revenue. In a marketing ecosystem the design system requires flexibility.

Identify marketing content needs

Content strategy is a key part of meeting the unique needs of marketing pages (i.e., the specific information contained in them and the UI that helps people make sense of it to achieve their goals). To start, we conducted an extensive exploration, where we evaluated these content needs to identify the UI patterns we needed to accommodate them. This allowed us to define and document three artifacts we'd need to standardize that UI on Adobe.com:

1. A defined UX pattern. Designs that account for specifications from Spectrum guidelines, system architecture, design tool requirements, CMS requirements, SEO, and accessibility.
2. A design tool template. Comprised of components from design libraries (in our design tool and the CMS) these templates ensure that designers have access to standardized content blocks, from marquees (page headers) and cards (content containers for information) to other UI elements, that match what’s available in the CMS.
3. A CMS content block. The ability to predictably recreate the design vision (of a marquee, editorial card, or UI element) expressed in a template in the CMS.

Consonant works by providing these pieces to web designers and web authors in a predictable, efficient workflow that ensures parity between the choices a designer makes and what the author publishes. It enables a designer to pull a set of UI patterns into a design tool to create web pages, which can then be handed off to web authors who access the same patterns in their CMS. That one-to-one relationship between the template in the design tool and the content block in the CMS is key. It enables designers to do quick art-and-copy mockups in the design tool with the confidence that once the content blocks are published on the site, they’ll reflect their design intent.

To ensure we were building these pieces correctly, we formed a cross-functional team that included representation from every team with a stake in Adobe.com content creation. Together, they could make the patterns built in our design tool map to content blocks in our CMS, then they could build in tandem. Team makeup included those responsible for creating content from baseline design requirements to authoring in a CMS:

• The UX designer represents the needs of graphic designers and art directors by establishing baseline design requirements and behaviors, then defining the rules for them. What layouts need to be supported? What are the type sizes? What are all the content types? Does it need to support a headline and body copy? Is it sticky? Does it need to animate?
• The design tool architect (a designer who specializes in component building in design software) thinks through how all the design requirements will be transformed into components and ensures that the UX designers baseline designs can be used to build components and templates. How will I layer multiple options? What component properties am I going to have to use to make this happen? What is the overall designer experience like?
• The engineer focuses on how designs will be expressed in code. What’s straightforward in design software can be more complicated to implement in a CMS and vice versa. The engineer builds the templates and components to insure they're working properly and can be published.
• The design publisher (a specialist publisher with expertise in both design and front-end engineering) represents the needs of the web author. This person thinks through what the authoring experience will look like for someone publishing content and how that same person would access choices built into the CMS, then works with the engineer on optimal solutions.

Since design tools and content management systems aren't flexible in the same ways, our end goal was to identify all UX requirements up front to pinpoint any problems that might arise between mapping components in the design tool and building content blocks in the CMS. Because we were considering two very different environments, that still required a one-to-one connection, our vetting process for how and what to build helped us achieve the desired level of parity before we got to the actual building phase.

Translate product design system components for marketing content blocks

Testing and refining UI decisions at each step, including when and where to deviate from the product design system, creates a unified throughline between the product design system and marketing content. The most impactful and optimized marketing content blocks tie back to products in a clear and comprehensive way.

Consonant's UI starts with Spectrum, then adapts it to meet the more expressive needs of marketing.

Marquees, Consonant’s page headers, are an example of how it uses the atoms and molecules of Spectrum to create more complex UI elements that can be standardized. This common component in Consonant uses Spectrum guidelines for things like corner radius, type hierarchy, and button styling.

Editorial cards show how organisms must be flexible enough to support various use cases such as content merchandising, events, and product promotion. With Consonant, a designer can create all these cards with a single component in our library, including different elements such as eyebrows, actions, and product lockups as well as different media, aspect ratios, border radii, and even the ability to stagger them for emphasis.

Quick action cards are designed to lead people directly to product interactions. That intent, which serves a different purpose than editorial cards, is a crucial part of Consonant, leading us to make different organisms that may look similar, but support different information and intent.

Consonant reinterpreted Spectrum design guidelines to meet the unique needs of Adobe.com by outlining a content strategy that considers the dynamic requirements of marketing content and the site’s authoring environment. By sharing the same design language, it extends Adobe's design system beyond the in-product experience to every touchpoint, from search to engaged product use.