Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Design Systems at Scale

303 views

Published on

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, on different platforms. Attendees will go home with tips they can use to improve design systems of any stage.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Design Systems at Scale

  1. 1. Design Systems at Scale Sarah Federman
  2. 2. What is a design system?
  3. 3. Essentially, a design system is a collection of products that help you solve the problem of scaling your design practice.
  4. 4. Benefits Include • Quick iteration on products • Stronger brand awareness • Everyone speaks the same language • Empowers developers • Improves user experience
  5. 5. Scale means getting the best results with the least duplication of effort AKA keeping our design DRY
  6. 6. Scaling your design means solving duplication of • Asset and UI creation • Code creation • Accessibility work • Localization • Testing • …etc
  7. 7. Duplication leads to fragmentation
  8. 8. We stop sharing things • One off changes means more code and confusing UX • Harder to onboard and move around in the codebase
  9. 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. 10. Design systems to the rescue!
  11. 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. 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. 13. And the stuff that makes it all work… DesignOps • Tooling • Process
  14. 14. Design Systems @ Adobe
  15. 15. Spectrum
  16. 16. The problem space • Over 200 designers • Over 124 products • 6 platforms • 3 frameworks
  17. 17. This has 1,080 permutations
  18. 18. Call to action Primary Secondary Warning Over color
  19. 19. Standard & quiet styles
  20. 20. Five states
 (default, hover, press, focus, disabled)
  21. 21. Extra Light Light Dark Extra Dark
  22. 22. Web MacOS Windows (UWP) Web (mobile) iOS Android
  23. 23. Multiply that by a useful amount of UI components and you get…a lot of work.
  24. 24. Fortunately, we have an amazing team
  25. 25. Team structure • Designers • Hybrids • Engineers • Project manager, 2 design managers …but we all tend to cross over.
  26. 26. Spectrum-react Spectrum-css Spectrum-native Spectrum Design Frameworks Designers Engineers Hybrids
  27. 27. A bit of history
  28. 28. Two different standards Coral/Topcoat: dev, Spectrum: design
  29. 29. 2016-2017: Forming, Norming, and Storming
  30. 30. Surprise! Everything is React.
  31. 31. 2017-2018: Performing (scaling)
  32. 32. Anatomy of Spectrum
  33. 33. • DNA + Tooling • Design & Content • Official Spectrum site • Precursors Spectrum
  34. 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. 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. 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. 37. Plus In-App Tools and Asset Delivery Pipeline
  38. 38. Design & Content • Designs for the site • Sticker sheets • Support • UI design & Content
  39. 39. Principles Human ReductiveRational
  40. 40. Taxonomy Styles Elements PatternsGuidelines
  41. 41. Creating & maintaining sticker sheets is no fun We made a tool for that!
  42. 42. Spectrum Site • Handlebars templates • JSON content • Torq playground and component examples
  43. 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. 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. 45. Demo time! (hopefully)
  46. 46. Processes
  47. 47. Support • Slack channel • Office hours 3x/week • Biweekly meetings with UI framework teams • Attend each other’s sprint planning • Quarterly hackathons
  48. 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. 49. Roadmapping • User testing to find out what components are most needed and prioritizing on that • Outcomes > Features
  50. 50. Measuring Success • Spectrum Scorecard • Understanding the meaningful indicators of adoption • Determines the level of support • Gives a quantitative view
  51. 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. 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. 53. The Future
  54. 54. 2018 • Incentivizing contributions via spot bonus • More tooling, more components, more scorecard, more stuff • Open source?
  55. 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. 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/

×