Design Systems Operations
4 likes988 views
The document outlines the journey of establishing design systems operations, highlighting the experiences from various organizations like Lunaweb, BBC, Financial Times, and Salesforce. It discusses the importance of effective tooling, collaboration between designers and developers, and the adoption of design principles to enhance product development and user experience. The main goal is to create a frictionless delivery process that allows teams to focus on high-value creative tasks while maintaining consistency and quality across products.
Design Systems Operations
- 1. The Road to Design Systems Ops Kaelig Deloumeau-Prigent @kaelig kaelig@shopify.com
- 2. Today’s agenda 1. My story 2. Design Systems Ops 3. Q&A
- 3. Aside: what are Design Systems?
- 5. Introduction As building our products becomes more complicated, we need to ensure our tools are up to the task at hand.
- 6. But we’ll get back to that… Story time!
- 7. LunaWeb —Small Web Agency —Employee #2 (19 today) —Doing a bit of everything: server maintenance, project management, front-end, design, UX, support… —Specialized in UX and front- end as we hired a designer and more back-end developers
- 8. LunaWeb Building Boilerplates —Lots of repetitive work, should be abstracted away —Email boilerplate, website boilerplate, static site generator… —As we got better at selling our front-end expertise, we started building boilerplates, styleguides, and component libraries for our customers
- 9. BBC News —Developer in the BBC Responsive News core team —Worked with BBC GEL on a BBC-wide responsive grid —Introduced BEM at the BBC —Initiated BBC News' component library (GUTS), enabling anyone to prototype quickly
- 12. The Guardian Project context —2012: theguardian.com starts a responsive redesign —3 teams working on theguardian.com, high level of autonomy, everyone (20+ people) can touch the Sass codebase —Fast pace of design iteration: no way to build a component library that would stay up to date more than 2 weeks
- 17. The Guardian Solution: extract the core principles behind the design language and translate them into code via Guss1 . This block’s width, on tablet and up, is 3 grid units .block { @include mq(tablet) { width: span(3); } } 1 https://github.com/guardian/guss
- 24. The Guardian Results —With Sass closer to the design team's language, designers & developers sit together and iterate very fast —Increased sense of ownership for designers —Consistency across pages and team workflows —Less time spent on looking for hex codes, font sizes, breakpoint values… means more time for higher value tasks
- 26. Financial Times Challenges —Heterogeneous tech stacks —Experts needed everywhere —Wasted developer time re-inventing the wheel, testing… —Culture dominated by engineers, little space for designers
- 27. Financial Times Solution: Origami —High quality reusable components that follow a spec —Tools to build & use components —Services to deliver components (CDN, Bower…) —Free-markets model2 where anyone can use (or not) Origami, and contribute to it 2 http://matt.chadburn.co.uk/notes/teams-as-services.html
- 35. Financial Times Team Structure: Core Team —Curates components —Documents/evangelizes best practices (web, performance, a11y) —Builds tooling, examples, monitors services —Trains designers, developers and product managers to think in systems and teaches them how to have an input
- 36. Financial Times Team Structure: Product Teams —Can contribute just like on an open source project —Build components for their own products —If a product wants to reuse something built by another team, they can even improve the component better —Third party companies (e.g. for marketing sites): simple consumers
- 38. Salesforce Challenges —Lots of teams writing front-end code —Inconsistencies everywhere, lack of reusability, accessibility —Designers constantly chasing assets & re- inventing the wheel —Many stacks from many acquisitions —Partners asking “How do I build Salesforce apps that look like Salesforce”
- 39. Salesforce Solutions —Design tokens! They abstract the fundamentals across platforms —Deliver HTML / CSS so any acquisition, customer, partner or internal team can decide what to build upon (React, Aura, WC…) —Document all the things: design principles, patterns, best practices… —Share and maintain a Sketch UI Kit
- 40. Salesforce My team’s role —Automation: testing, linting, bots, CI/CD —Integrating the delivery process with the core platform —Misc. operational work: GitHub / OSS / npm / monitoring —Developer / designer experience: tools, prototyping env
- 48. Shopify
- 50. UX Acceleration —Theme within Shopify’s "UX Systems" team —Tools —Services —DX (Developer Experience) —DevOps for designers!
- 51. Reducing the distance between people, teams, and activities, combined with reducing the batch size of your work, allows you to deliver more value, more continuously, with greater quality. – Jeff Sussna (DevOps for Designers)
- 52. It is a role? or a practice?
- 53. I don't have an answer yet. I'd define it as a practice, that some people happen to champion.
- 54. All you need to ask is: When the end result (code) is a poor representation of the original intent (design), where does the process fail our users?
- 55. We want to reduce decision fatigue with a frictionless delivery process. This allows people to spend their calories on the creative stuff.
- 56. What kind of decisions can we make for our users?
- 57. Design meets performance —What's the best way to load assets? —fonts: web? iOS/Android? design tools? —SVG: <img src="foo.svg" />? <svg><path… >? <svg> + <use />? Base64 in CSS? —Image optimization: —SVG (manual optimization to avoid lossy artifacts?) —PNG/JPG… or even webp via an image service? —When? At build time or on the CDN?
- 58. Developer Experience —Local development environment —Fast setup, fast to run, live reload… —Linter configurations (JS, CSS, Markdown…) —Locally, in pull requests, CI —Releasing (ideally: single-button release!) —Loading JS/CSS in products —Building a new component…
- 59. Testing —Can developers run all tests locally? How fast is it? —Visual regression testing —Accessibility —Can something like a Chrome Extension help products test against the design system rules?
- 60. Where to start?
- 61. User research & surveys —What tools/languages are people already using? —Dev: React, WordPress, Rails, HTML/CSS, IDEs —Design: Sketch, Abstract, UXPin, Craft… —Where do people get blocked? (git is common) —Who are the casual design systems users and who are the experts? (useful to find allies)
- 62. Measure & Monitor —Analytics on your design system site(s) —Build times (local boot time, CI) —# of technologies leveraging the design system —# of pull requests (+ time to answer/merge) —MTTR (Mean Time To Repair) —In production, across all dependant products —Quality: # of linting errors, a11y issues…
- 63. Focusing on the right thing —From this baseline, emit a bunch of hypothesis —Target your impact where people already spend their time —Don't force them to learn new tools for the sake of it —Ask yourself what success looks like for “the business” and how your time can be best used at this level
- 64. Aside: on tooling acceptance Tell people what you're going to do and how you think this will help them. Some people can develop a resistance to new things, make sure to communicate it clearly if you're going to revolutionize their workflow.
- 65. If a design system is “a product, serving products” (Nathan Curtis). How do we shape it so that it’s desirable, respected, maintainable, beyond taste and technology?
- 66. How do we make sure it serves both the interests of the company and the interests of the people using it and contributing to it?
- 67. This is what Design Systems Ops is all about.
- 68. Thank you
- 69. Shopify is hiring! Get in touch: kaelig@shopify.com