A design system can vastly improve your team’s productivity, but most of all, it leads to better products! The challenge lies in creating a mature system and leading its adoption across the company successfully. Let’s talk about how we learned to meet the needs of different designers and developers on different products, on different tech stacks. Attendees will go home with tips they can use to improve design systems of any stage.
Sarah Federman – Design Systems at Scale
Sarah is a designer and developer, which is why DesignOps makes so much sense.
But let’s start with a brief history of the universe. Back in the day UI was designed in Photoshop, sliced up and handed off to developers. Then over the years flat design helped bring vector tools to the forefront; and now we have tools like Sketch that have concepts like Symbols into them. At the same time the code grew from basic CSS to systems like OOCSS and BEM; and methodologies like Atomic Design.
We’re not designing pages, we’re designing systems of components. – Stephen Hay
We’ve also moved to a much heavier focus on client-side applications, particularly with React. It encourages a component based approach. This intersection has really exploded in recent months with crossover tools like React Sketch App. In reality the design and dev worlds have been coming together for years.
We have reached the rise of design systems – not just UI libraries or style guides, but well-rounded design systems. These often support money-making work without making money in and of themselves, so they can be open-sourced. This is helping the movement grow as people can get the code.
Design systems are a product that help us scale our design practice. Scale here means getting the best results with the least duplication of effort – keeping your designs DRY. Duplication leads to fragmentation – we have heard all the stories of companies finding dozens of shades of blue through their product suite, when there should have been one.
A design system is an organisational structure. What is the company structure? Are the designers embedded with product teams or centralised? Are product and marketing separate?
A design system is run like a product, not a project. They have ongoing work, they have a roadmap, they need staff like any other team. Design systems as product moves the narrative away from process.
Sarah’s favourite analogy is whiskey. What is it that makes a great whiskey so good? Was it the ingredients, the process, the people involved, the occasion you drank it, the fact it cost a bit of money?
Resources + Ops = product
Product + Emotion = experience
For a design system – operations are how things are made; product is what it is.
What goes into your design system depends on your organisation and what it needs.
Why do we even want a design system?
- fast iteration
- stronger brand identity
- common language
- better user experience
A good design system becomes a delivery mechanism for important goals… although it can also be a single point of failure!
There is a lot of activity in the tooling and operations space at the moment, giving us lots of opportunities to evolve the way people work together. Adobe is moving away from red lining (annotating the design details) to blue lining (documenting the invisible details like accessibility).
At what ‘scale’ is Adobe doing their design system (Spectrum)?
- 250 designers
- 124 branded tools in the market
- 4 colour themes
- 6 platforms
- multiple frameworks
This combination multiplies out so that a simple pill button has 1080 permutations!
How did they get there with Spectrum?
First they had to build trust.
They started with a website and an XD file, but since they were often out of date they hit a pain point about which one was the source of truth. People would be asking ‘does this work for my product, on its platform?’
So they raised the bar for what was considered canonical, creating Inclusion Criteria for adding things to Spectrum. Anything going in has to work cross-platform, support all 4 themes, be accessible and must be documented. This meant that a lot of features were effectively removed from Spectrum as they didn’t meet these criteria.
They declared that the website is the source of truth for Spectrum. Design assets are still available on a network drive, but they are versioned in synch with the website and released with a scripted process.
The documentation has huge amounts of detail including the interactions, details about implementation (is it available in the CSS and React implementations), usage guidelines (do and don’t examples).
Over time the templates were getting brittle, so they broke them up into more granular pieces – made it much more declarative than imperative. This reduced the need to know the full page design to be able to use components.
How do they build and deliver Spectrum?
They have several implementations – CSS, React and ‘native’ for specific platforms. They have recently standardised the web apps to React.
Spectrum DNA is stored in JSON – essentially design tokens. The variables are layered – there are global values, which are used in component variables.
The asset creation pipeline has significant scale challenges at Adobe, where single products like Photoshop need more than a thousand icons.
Designing at scale hit the next pain point: where did everything go? By raising the standard for inclusion, they removed things people had been using and they didn’t know what to use now. They’re working to reinstate all the funcationality, but they needed to go faster.
They now release “Spectrum Precursors”, for beta features. It lets people share and work on features before they are finalised and go into the main library. They’ve even used spot bonuses to encourage contributions!
They’ve also evolved the way they do documentation. They now start the docs before the development is finished, using Dropbox Paper. By bringing more disciplines in earlier, they find more gotchas.
How do they measure success? How can you assess adoption at scale?
Currently they are doing a trial with Spectrum Scorecards – simple, single-number scores; allowing self-assessment so the system can scale. The second part of the system is a Spectrum Assessment, done by a core team member who is more deeply familiar with the system. Currently the scores focus on the basics like color, elements, icons, inclusiveness.
The continued story of success for Spectrum is based on bringing together design, development and operations!