Design Systems at Scale
•
5 likes•1,680 views
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.
Report
Share
Design Systems at Scale
- 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
- 21. Standard & quiet styles
- 22. Five states (default, hover, press, focus, disabled)
- 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.
- 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
- 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
- 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/