The document discusses the importance of design systems in scaling design practices, highlighting their benefits such as improved brand awareness, faster product iteration, and enhanced user experience. It outlines various challenges faced, including duplication of design efforts and outdated components, and explains how design systems can streamline processes through shared resources and communication. The document also details the structure and history of Adobe's design system, Spectrum, including its tools and approaches to measuring success and fostering collaboration.

1. Design Systems at Scale
Sarah Federman

2. What is a design system?

3. Essentially, a design system is a collection of
products that help you solve the problem of scaling
your design practice.

4. Benefits Include
• Quick iteration on products
• Stronger brand awareness
• Everyone speaks the same language
• Empowers developers
• Improves user experience

5. Scale means getting the best results with the least
duplication of effort
AKA keeping our design DRY

6. Scaling your design means solving
duplication of
• Asset and UI creation
• Code creation
• Accessibility work
• Localization
• Testing
• …etc

7. Duplication leads to fragmentation

8. We stop sharing things
• One off changes means more code and confusing UX
• Harder to onboard and move around in the codebase

9. Things get out of date
• Adopting new versions is hard
• When there’s more to keep track of, more things get left
undone

10. Design systems to the rescue!

11. We take care of the details so you can
do the hard stuff
• UI components
• Design files
• Code repos
• Documentation
• Design guidelines
• Code documentation
• Language/a11y/contribution/etc

12. Content
• Buttons, links, inputs,
icons, etc
• Fonts, colors, sizing
• Basic documentation
Simple Comprehensive
• UI Components
• Grid
• Code style
• Developer tooling
• Design tokens
• High level guidelines
• Accessibility information
• Internationalization
• Motion guidelines
• Voice and tone/writing
• Workflow tooling

13. And the stuff that makes it all work…
DesignOps
• Tooling
• Process

14. Design Systems @ Adobe

15. Spectrum

17. The problem space
• Over 200 designers
• Over 124 products
• 6 platforms
• 3 frameworks

19. This has 1,080 permutations

20. Call to action
Primary
Secondary
Warning
Over color

21. Standard & quiet styles

22. Five states
(default, hover, press,
focus, disabled)

23. Extra
Light
Light
Dark
Extra
Dark

24. Web MacOS Windows (UWP)
Web (mobile) iOS Android

25. Multiply that by a useful amount of UI components
and you get…a lot of work.

26. Fortunately, we have an amazing team

27. Team structure
• Designers
• Hybrids
• Engineers
• Project manager, 2 design managers
…but we all tend to cross over.

28. Spectrum-react
Spectrum-css
Spectrum-native
Spectrum Design Frameworks
Designers
Engineers
Hybrids

29. A bit of history

30. Two different standards
Coral/Topcoat: dev, Spectrum: design

31. 2016-2017: Forming, Norming, and Storming

32. Surprise! Everything is React.

33. 2017-2018: Performing (scaling)

34. Anatomy of Spectrum

35. • DNA + Tooling
• Design & Content
• Official Spectrum site
• Precursors
Spectrum

36. DNA
• Source of truth for design data
• Consumed by all frameworks (and some tools)
• Contains variables for things like colors, sizing, etc
• If we change a value here, it should propagate everywhere

37. Originally 2 repos
• Spectrum-origins & Balthazar
• Origins was a bunch of json
• Balthazar did some variable substitution and compiled to
different targets (scss, css, stylus, etc)

38. Combined into one tool
• One repo: Spectrum DNA
• We found that we didn’t actually need to be agnostic and it
wasn’t worth the effort. Balthazar was tightly coupled to
Origins
• JSON became standard JS

39. Plus In-App Tools and Asset Delivery Pipeline

40. Design & Content
• Designs for the site
• Sticker sheets
• Support
• UI design & Content

41. Principles
Human ReductiveRational

42. Taxonomy
Styles Elements PatternsGuidelines

43. Creating & maintaining sticker sheets is no fun
We made a tool for that!

44. Spectrum Site
• Handlebars templates
• JSON content
• Torq playground and component examples

45. Growing pains
• We began having a unique structure for each template
where we inserted values for each section
• Didn’t scale. We had created new templates for each page
and had to maintain them.

46. Componentizing content
• I designed a new system where we essentially
componentized all of our content into what I call content
types
• Testable via JSON schema validation
• Consistent, context-independent
• Can be delivered via API more easily

47. Demo time!
(hopefully)

48. Processes

49. Support
• Slack channel
• Office hours 3x/week
• Biweekly meetings with UI framework teams
• Attend each other’s sprint planning
• Quarterly hackathons

50. Releases
• Biweekly
• A snapshot of the system at that time (includes UI files and
DNA)
• We update the what’s new page on the site and post in the
#spectrum-bulletin slack

51. Roadmapping
• User testing to find out what components are most needed
and prioritizing on that
• Outcomes > Features

52. Measuring Success
• Spectrum Scorecard
• Understanding the meaningful indicators of adoption
• Determines the level of support
• Gives a quantitative view

53. Scorecard process
• 5 question Pre-Scorecard Assessment
• Product sends us the screens they want us to evaluate
• For each screen we ask questions that can be answered yes or no
• Scores are rolled up and averaged out in several topics
• Post-scorecard Self-Assessment
• Do we provide the things this product needs?
• How good of a job are we doing meeting the needs of
products?

54. Precursors
• Web app allows users to upload examples of spectrum-ish
designs
• These designs get approved or denied and the contribution
process begins
• Promotes transparency in the org
• Allows us to solve more problems faster

55. The Future

56. 2018
• Incentivizing contributions via spot bonus
• More tooling, more components, more scorecard, more
stuff
• Open source?

57. We’ve been known to tell a developer “If it isn’t
documented, it doesn’t exist.” Not only does it have to
be doc’d, but it has to be explained and taught and
demonstrated. Do that, and people will be excited —
not about your documentation, but about your product.
Mike Pope

58. Thank You!
@sarah_federman
Special thanks to @ammiller
Want to learn more?
• Look at style guides: http://styleguides.io/
• Look at more style guides: http://designguidelines.co/
• Listen to podcasts: http://styleguides.io/podcasts
• Slack group: designsystems.herokuapp.com
• Find out about events: https://www.sfdsc.co/