Designing design systems: Supporting implementation and adoption

Encouraging proper use of a design system—and knowing when it needs to flex


Flowing swirling blocks of vibrantly-hued color in a blue-to-purple-to-pink-to-red-to-orange-to yellow gradient.

Graphic by James Provenza

A design system can’t reach its full potential if no one’s using it as intended. Beautifully designed components need to be paired with thoughtfully written guidance and ongoing support as the system evolves.

Since very few people are poring over design system fundamentals, unless they need them for specific use cases, design system designers must take on the job of librarians, evangelists, and advisors. They catalog, organize, and maintain libraries of guidelines, documentation, and assets, but also actively motivate, support, and guide the design and product teams that use the system.

Spectrum, Adobe’s design system, serves more than 100 unique applications and a multidisciplinary team of more than 600 people worldwide in Adobe Design alone. In addition to the work of maintaining and updating our system, as we rolled out our comprehensive Spectrum 2 update, our challenge was to guide its proper use.

A hand-drawn illustration of six books with titles in hand-drawn type. In multiple colors and sizes, the books are proppped up as if on a bookshelf with the spines visible, against an ocean blue background. The titles (from left) are: Toasts (purple type on a yellow book), Sliders (green type on a purple book), Buttons (yellow type on an orange book), Progress Circles (purple type on a blue book), Segmented Control (orange type on a green book), Checkboxes (yellow type on a purple book).

Since every design system is in a “living” state of constant iteration, understanding the best ways to help others implement it takes time and experience. From documentation and communicating updates to encouraging collaboration and triaging feedback, we’ve built practices for supporting ongoing usage across design teams and navigating the inevitable challenges that arise from real-world use cases.

Create an infrastructure for capturing ongoing documentation

Documentation for the Spectrum 2 update began as a playbook, a place for us to document and guide design decisions to share with internal beta testers. The content from that playbook was eventually adapted into an internal site, which serves as our primary source of documentation. As opposed to individual documents or design files, websites provide stability and officiality to information.

A hand-drawn illustration of a web browser window against a purple background. Inside the drawing of the browswer window is a screenshot of a page from the Spectrum 2 website with an overview of content containers. Alongside the body copy of the containers overview is a Table of contents that includes links to Styles, Padding, Emphasis, and App frame.
A screenshot from the internal Spectrum 2 website with the definition of containers and how they’re used in Spectrum’s components.

They’re also the most scalable way for systems designers to share information (like guidelines for button text wrapping behavior or a table of font sizes) and promote good design practices. Design documentation will vary depending on team needs, but should ideally include:

We supplement our website documentation in two ways:

Key screen explorations are a useful form of design documentation that demonstrate concrete ways to flex a system. Crafted and iterated upon alongside product design teams, they apply foundational concepts to be relevant to in-product needs. They consist of no more than one or two screens from a product flow that show a design challenge and suggested solutions.

Since very few people are poring over design system fundamentals, unless they need them for specific use cases, design system designers must take on the job of librarians, evangelists, and advisors.

For Spectrum 2, we’d pushed an idea of removing dividers (visual lines used to separate groups of semantically related content) in favor of using spacing, color, shadows, or typography to group content. The approach provided a fresh visual style but was sometimes misinterpreted: We wanted teams to remove dividers when unnecessary, but not in cases where the hierarchy would be unclear without them. The best way for us to show our intended usage was to share key screen explorations. By pointing out small tweaks we’d made to the spacing and providing options for dividing and grouping content, we helped make general examples and guidance more readily understandable and relevant.

One word of caution: Key screens should be used as tools to inspire. Be careful of getting stuck creating product-specific flows on behalf of product design teams. It’s important to learn when to toss ideas back to product designers to flesh out, instead of going too far on your own (since they know their products best, redesigning entire flows for them can be an ineffective use of your time).

A hand-drawn illustration of two overlapping rectangles composed of multiple shades of blue and white on a bright pink background. Inside the rectangles are sketches of content blocks demonstrating various ways to section content both subtly and explicitly with and without hard line divisions.
Key screen explorations help articulate design concepts in concrete terms. This example shows content before (top) and after dividers, tweaked spacing, containers, and typography are used to group content and improve the information hierarchy.

Workflow specific guidance. When we set out to define Spectrum 2, the primary goal of our documentation was to provide high-level guidelines alongside system-level thinking about how we arrived at them. Our theory was that the guidelines would cover multiple use cases and give designers autonomy to confidently make decisions. What we found is that product teams respond best to a combination of high-level guidance alongside specific examples applied to real-world applications—and as system designers help with the interpretation of guidelines for specific product needs, those focused examples can supplement future documentation.

Spectrum has a lengthy backlog of topics that we’d like to build guidance for, and we often begin that work from existing solutions for complex use cases. For example, our guidelines for a “table” component are informed by complex needs in our Experience Cloud products (like Adobe Workfront and Adobe Analytics), which require displaying many types of data—from people to dates to controls. Before system-wide guidance is ready, pointing teams to existing guidelines from other teams promotes early alignment, and provides a starting point to develop broader guidance for more use cases.

Supplementing documentation will evolve as design and design system team sizes require, but there are some added ways to ensure that people have the information they need, when and where they need it:

Communicate updates to ensure teams stay current

Design systems are in a constant state of evolution. While documentation sets teams up for a thorough understanding of a design system, communicating updates ensures continued success.

In addition to more generalized, structured announcements for updates (like bug fixes and changes to components), the same platform used for announcements (our design team prefers Slack) can also be used to collect examples of updated components that are live in-product or used in design explorations (these examples can be used later to inform design system updates that will scale to a wider range of use cases).

Since updates to internal websites and component libraries can give teams a better idea about how a system update will impact their work, announcements should correspond with updates to those resources. If, for example, a component is deprecated, teams will have detailed information about what specifically changed—and can go into their libraries and make necessary adjustments.

During the early stages of Spectrum 2 development, we shared updates along the way so product teams could begin explorations. Since then, we’ve continued sharing in-progress updates, before they’re officially “ready,” with different groups of small audiences—each with varying product needs and use cases. Asking teams to implement ideas in their designs is not only a great way to share potential updates, but also to vet them. Small group conversations can help solidify guidelines as they’re adapted for new use cases.

Provide a means for feedback, collaboration, and ongoing support

As teams grow and a design system evolves, it’s important to provide ongoing support for questions, guidance, and requests. Creating an infrastructure for fielding and responding to queries ensures that teams feel supported and will continue to look to the design system for guidance.

Don’t be afraid to share a strong opinion. System designers must be opinionated to maintain coherency across products—and adhere to good design practices.

Communication channels range from personal to impersonal but the best formats for capturing and responding to feedback are going to depend on the size of the team using a design system and the number of people available to respond to them. We primarily use three:

A hand-drawn illustration of feedback form on a lime, teal, and grass green background. The form, with a blue header has fields for Name, Team, and Share detailed information. Inside a green button at the bottom is a hand-drawn paperclip and "Attach an example" in hand-drawn type.
Feedback forms are a helpful way to quickly collect bug reports and functionality requests. Fields that will help you obtain critical information to triage requests: name, team, component library or website, and areas for sharing detailed information and attaching examples.

System designers must be the experts on the components and guidelines to actualize what design systems promise: consistency and continuity. No matter the maturity of a design system, when people need guidance or training, there are ways to be a strong collaborator:

When sharing feedback with teams, set the context by acknowledging product expertise and then provide ideas in a constructive way. Acknowledge what you don’t know but be firm about what you do know. Even if something is obviously “wrong” to you (our team has seen our fair share), keep in mind that you’re working towards a shared goal: the best design solution for a given problem. Shared trust and an openness to being wrong helps to create a more collaborative atmosphere—and that’s critical to the success of a design system.

To understand whether a request is viable, how it might impact the design system, or even to suggest a scalable solution, systems designers must understand, not just what someone wants, but why they want it.

Because design systems cover a wide range of users across products, from design to marketing, they sometimes only directly support the broadest use cases. When designers are looking for solutions to problems that are specific to a narrow user segment, there may be times when a design system can’t fulfill the request. In cases where you’re not directly building solutions, work with teams to support them in creating their own solutions that still fit the broader ecosystem.

Additionally, design systems can’t (and shouldn’t) reinvent the wheel every time a need arises. When a specific request doesn’t align with system principles or foundations, explain why, then spend time providing alternate solutions. Be as transparent as possible about your team’s decision-making process. For Spectrum we have guidelines about what we will consider for updates and what we won’t, so it’s easier to provide rationale for our decisions:

What we will add

What we won’t add

It’s impossible to talk about ongoing support without stressing the importance of asking the right questions. To understand whether a request is viable, how it might impact the design system, or even to suggest a scalable solution, systems designers must understand, not just what someone wants, but why they want it. Clarifying questions (like where it will be used, what its purpose is, and why an alternative isn’t working) will help uncover the reasoning behind a request even when it seems straightforward.

After digging deeper into a recent request for a donut chart component (a specific type of chart that displays data in segments of a circle) that wasn’t yet included in Spectrum resources, we found that what the team was really looking for was a circular meter. It turned out that the linear meter offered in Spectrum would work just as well. By not taking the request at face value, and better understanding the request, it was easier to offer alternative solutions that fit an underlying need.

Two white rectangles on a bright orange-to-pink gradient background. In the rectangle on the left is a circle outline drawn one third in pink and two thirds in blue with the words "35K visitors," in hand-drawn type in the center. Inside a speech cube, with an arrow pointing to the blue line are the words "75% of users" in hand-drawn type. In the rectangle on the right is a line drawn (from left) two thirds in blue and one third in gray. Above the blue part of the line are the words "Tutorials completed 75%" written in hand-drawn type.
Donut charts (left) visualize data and show information about the individual segments that make up a whole—like displaying the percentage and quantity of visitors from different operating systems. Meters (right) visualize progress precipitated by user actions—like visualizing the completion of a tutorial sequence.

It takes time and experience to learn the ins-and-outs of a design system and the best ways to help others implement it. Whether a design system is large or small, the best way to ensure its adoption is by making information available in a way that's useful and guides proper usage. Over time, I've learned that the best way to do that is by fostering shared ownership of the system through documentation, communication, and collaboration.

Special thanks to PJ Buddhari, Stefan Chitu, Angelie Herreria, Matt Knorr, Jess Sattell, Allison Shaw, and Deanna Smith for their insights behind the work in this story. And thank you to the entire Spectrum core design team—our librarians, evangelists, and advisors.

Header copy
Design your career at Adobe.
Button copy
View all jobs
Button link
/jobs