Design systems can achieve a world of good for companies and organizations. They tell a cohesive story about your products, while helping users navigate them in a clear and consistent way. The path to implementing them, on the other hand, is often anything but clear. Especially at large organizations, comprehensive UX design systems require a huge amount of cooperation from many different teams. So, how do you get buy-in?
Adobe is implementing its own design system, Spectrum, and now we’re sharing some stories of how we got to this point. To learn more about Spectrum, its challenges, and its solutions, check out our first post “Introducing Spectrum: How Adobe Is Building a Design System at Scale.” Below we’ve outlined some of the key steps we’ve taken to get company-wide buy-in on Spectrum, in hopes that it will help in your own companies and organizations. It hasn’t always been easy, but the results are undoubtedly better when all teams and stakeholders have a say in the future of our design system.
Building for scale as a team
Adobe contains a massive product library, with apps and tools across several platforms. Building for a design system at scale is no simple feat, which is why it is especially important to work smart. Scaling isn’t just about serving a gajillion users, it’s about getting the best results with the least duplication of effort.
Solving for this kind of scale requires bringing together design, engineering, and operations in unique and unforeseen ways. Here are the steps we’ve taken to get Spectrum off the ground in the most efficient (and effective) way possible.
1. Create trust across teams.
Transparency and consensus-building are key. In order to get buy-in across product teams, we started by building trust between the Spectrum team and the teams of designers and engineers building Adobe products.To do this, we’ve had to make sure our design system was as clear and comprehensive as possible. Early in the process, when we were just setting up Spectrum for scale, we created a simple and flexible taxonomy (styles, elements, patterns, and guidelines), defined our principles (rational, human, reductive), and established clear inclusion criteria that set the bar at a high level of quality. This paid off later in the process, as we looped more team members in.Everything that goes into Spectrum must meet the following criteria:
- Accessible: conforms to WCAG 2.0 AA standards.
- Cross-platform: has been evaluated on UWP, MacOS, iOS, Android, and web.
- Cross-theme: has been evaluated across all four primary color themes.
- Well-documented: includes examples, usage guidelines, and links to further reading.
- UI kits: includes a UI kit with reusable vector objects of every variant and state.
- Single source of truth: design and engineering resources are built using the exact same parts and variables.
Our goal is for everyone at Adobe to be able to use Spectrum with confidence. To pull off all of the above, we brought together subject matter experts under one team, so we can produce a single source of truth equally relevant to designers and engineers when they’re getting started with Spectrum.
Part of building trust is ensuring people can get the info they need quickly. We invested early in a website that enables users to explore and interact with Spectrum content.
Trust isn’t just created by all the information we display on the website — it’s also embodied in our day-to-day actions. We’ve taken the following steps to maximize buy-in and help product teams feel at ease with any changes Spectrum makes:
- Predictable cadence: we ship updates to the design documentation on a regular schedule, with a change log and an archive of all previous versions.
- Backlog/roadmap exposure: our backlog is available for all Adobe employees to see, and we allow people to add items directly to it.
- Clear policies: we adhere to the philosophy of making process policies as explicit as possible, and, where applicable, publish them directly on the Spectrum website.
2. Implementing intelligently at scale.
When design values aren’t connected to a single source of truth, implementations quickly become misaligned.
Ever wonder how applications get 200 text styles or shades of gray? It happens quicker than you’d think. When you rely on manual human effort at scale, you’re bound to fail. Keeping things connected to a single source of truth ensures our design intent is mapped consistently across a variety of implementations, and that makes Spectrum an “easier sell” as a design system for multiple product teams with their own individual needs.
One way we do this is via our repository of design variables, which we call Spectrum DNA. This repository, which is co-managed by a designer and engineer on the Spectrum team, is a collection of values that defines visual attributes — colors, type styles, padding, and so forth (basically, any aspect of the design that can be expressed as data).
Here’s an example. Let’s take the classic button element.
When a button is displayed on your screen, it is composed of several design variables. Things like the font used on the button label, or the border thickness, can be expressed as values — sometimes these are known as design tokens.
When these variables are abstracted into a separate repository, we can quickly build the button across a variety of implementations — in React, Objective-C or UWP, for example — in a super consistent way. And if any of those variables change, we can change them in one location and distribute those changes evenly across the ecosystem.
Duplication leads to fragmentation. So even though Adobe has a complex landscape of frameworks in play, we strive to reduce duplication of design constants and other essential data as much as possible. This means we’re able to effectively convey the principles of our design system and make sure they’re being deployed in the best way possible.
3. Empowering contribution.
Establishing the standards (building trust) and tools (implementing at scale) necessary to address Adobe’s unique needs has resulted in a whole new set of challenges for us to solve. Now that we’re absorbing all this complexity and distilling it, it takes a lot more work for Spectrum to grow.
We can’t accomplish this mission by ourselves. We need the expertise and creative energy from other teams to expand the system, and to provide the necessary outside perspective to keep Spectrum honest. This not only encourages buy-in, but it also helps Spectrum evolve holistically (an impossible feat otherwise).
Favor community over control.
Nathan Curtis, Principles of Designing Systems
Our first attempt at opening Spectrum to more community influence is a project called Spectrum Precursors, launched earlier this year. This project, which aims to establish a holding ground for new patterns, is centered around a website that is a sibling to the main Spectrum website. This site allows product teams at Adobe to view patterns that have been contributed by other teams, and to upload their own patterns.
Items on the Spectrum Precursors website are considered acceptable for designers to use in their projects, even though they haven’t been fully validated across the various criteria detailed earlier. They might not be validated across all of our supported platforms, for example, or they might simply be in need of more documentation, but they are consistent with Spectrum’s basic rules.
Our ultimate goal is to enable people to contribute “official” design patterns, not just Precursors. But Precursors is a start. It helps us widen the top of the funnel — to capture emerging ideas, and to enable designers across Adobe to see what other people are making.
This is the key to Spectrum’s success: we’re striving to not only get widespread buy-in for our design system, but we’re harnessing the intelligence and abilities of our various teams to build Spectrum in the smartest and most effective way possible.
Stay tuned for more to come on Spectrum, and if you’re looking for more information, be sure to read our introductory post on building a new design system at scale.