How to create new processes to sustain a design system How to evolve the way companies build and ship products How to decide on a governance model for design systems

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

70. Let’s chat!Kaelig Deloumeau-Prigent
@kaelig
kaelig@shopify.com