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

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

17.
This has 1,080 permutations

18.
Call to action
Primary
Secondary
Warning
Over color

19.
Standard & quiet styles

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

21.
Extra
Light
Light
Dark
Extra
Dark

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

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

24.
Fortunately, we have an amazing team

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

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

27.
A bit of history

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

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

30.
Surprise! Everything is React.

31.
2017-2018: Performing (scaling)

32.
Anatomy of Spectrum

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

34.
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

35.
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)

36.
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

37.
Plus In-App Tools and Asset Delivery Pipeline

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

39.
Principles
Human ReductiveRational

40.
Taxonomy
Styles Elements PatternsGuidelines

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

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

43.
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.

44.
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

45.
Demo time!
(hopefully)

46.
Processes

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

48.
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

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

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

51.
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?

52.
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

53.
The Future

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

55.
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

56.
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/