When Shawn Cheris, director of experience design at Adobe, started working on Spectrum, Adobe’s design system, he was a one-man champion of a system to help Adobe designers and developers craft captivating user experiences. Today, Spectrum is widely used throughout Adobe. Here’s how Cheris drove that evolution.
With so many products, how does a design system improve how you develop customer experiences at Adobe?
Spectrum provides the structure and the underlying experiential through line that unites our products. We do that by providing resources to help make designers’ and engineers’ jobs easier. It’s also a contribution model that everybody can be a part of.
Now that we’ve got critical mass, we’re moving from sculpting to gardening. A lot of what we do today comes down to managing all the inputs and contributions. While a design system can provide guidance on crafting consistent customer experiences, it can’t cover everything. You have to give people opportunities to innovate while making sure they reuse the best of what already exists without inventing new stuff out of whole cloth unnecessarily.
How did you realize you needed a design system?
It’s been apparent to our centralized design team for as long as anyone can remember. Adobe has acquired a lot of companies, adding more and more stuff to our portfolio, so it’s a constant effort to tie it all together. In the last decade, we’ve put a lot of effort into making our 100-plus products and services look like they come from one company — from a brand perspective of logos and visual architecture. So it seemed logical to extend that into our product experience.
How did you get buy-in and encourage adoption?
It wasn’t well understood that the company should invest in a design system — not that anyone used that term then. So, we put a lot of work into piecing together a vision of how products like Photoshop, Lightroom, Premiere, and After Effects could look if they had a very consistent and modern user experience. Then, we created a vision video with a customer journey spanning all of Adobe’s ecosystems to show what that experience could look like. I probably showed that video hundreds of times. I gave a presentation to every product, design, engineering, and project manager who would give me their time.
Our initial adoption strategy included targeting the teams developing centralized frameworks for the front end of our products, whether they were for desktop, mobile, or the web. Focusing on engineering frameworks injected our point of view into both new and existing products.
How did you get adoption on existing products? Was that more challenging?
Yes and yes. Some products can adapt more quickly than others. Photoshop, for instance, is rounding the corner on three decades in the market. The older the product is, the more challenging it is to change some aspects of the user experience. That said, the Photoshop team really put a lot of energy into working with us and the UI has evolved tremendously in the last five years.
We had to work directly with engineers on our flagship products to figure out how to put our pretty pictures of the design system into an existing framework that can be executed in a realistic way. But once we got Photoshop to move a little bit, it became easier to say, ‘Well, Photoshop’s doing it, so what’s your excuse?’”
What misconceptions do you think people have about design systems?
Many designers think that in an ideal design system, they should be able to draw the elements they want in a visual tool and have them sort of magically transmogrify into engineering components. I think that frustrates engineers to a degree because it’s not a particularly realistic, respectful, or productive view of what that discipline brings to the table.
I think the truth of design systems is that a visual drawing tool will never be an ideal way to communicate with an engineer, because, fundamentally, it’s just a picture. We like to talk about the difference between building a house, engineering a house, and drawing a picture of the house. A picture of a house will never be a house.
A lot of this comes down to a fundamental trope among designers: Should designers learn to code and should coders learn to design? My view is that yes, designers need to put in whatever work it takes to ensure that they have a good grasp on the medium they’re designing for — what’s possible, what’s good, and what’s bad.
If all you want to do is draw a picture of a house, then just draw a picture. But if you want to really design a house, then you need to understand how houses are constructed. Should all architects be structural engineers? No, but they should probably have a pretty good understanding of how buildings are constructed. It’s the same thing with design.
A design system isn’t a magic bullet to solve this problem. It just provides a base set of ideas that everybody can work from.
What are some of the pitfalls you’ve seen in the development of a design system?
Designers assume that everybody just intuitively understands and accepts the value of the consistency you get from design systems. That’s not usually the case. Designers need to think about how the design system helps a company reach its goals. The more you align your system with your company’s goals, the more successful you’ll be. The more you fight against the grain, the more challenging it will be.