There’s no way around it — any design system project comes with disagreement and spirited debate. Because a design system serves not just many products, but also many stakeholders, from designers and engineers, to marketers and content strategists. Each product team and each discipline brings a unique set of goals and perspectives, and often they’re at odds. These disagreements, if left unresolved, can K.O. your design system before it even gets started. I know, because it’s happened to me. The good news is — it doesn’t need to be this hard. Through my successes and failures building design systems, I’ve uncovered some strategies you can use to keep your team moving forward in harmony. You’ll leave this talk with an understanding of the following: - How to document governance processes to help your team answer the most polarizing questions surrounding design systems, such as when to use an existing component vs create a new component. - How to involve stakeholders across your organization, without stalling your design system or falling victim to design by committee. - How to define your design system team’s roles and responsibilities, as well as how others can contribute to the system.

1. Governing Conflict In
Design Systems
JD JONES @JAYMES_JONES

5. Polarizing
Topics

6. To build, or not to build?
POLARIZING TOPIC

7. 01 To build, or not to build?
Product
Market Fit
Design
System
VS

8. 01 To build, or not to build?
Design system will
bring value
More value and lower risk
than other initiatives
VS
+ Value- Value
+ Risk
- Risk
I’M VALUABLE!
I AM NOTHING!

9. You spend time and money to build a system,
and no one uses it.
The biggest risk

10. Validate
Problems exist
Problems are painful enough
01 To build, or not to build?

11. 01 To build, or not to build?

12. 01 To build, or not to build?
Research In Context
Tasks are complex
The problems are in the details
Memory is fallible

13. I like numbers I like stories I like turtles
Know your audience
01 To build, or not to build?

14. How should our components work?
POLARIZING TOPIC

15. Eliminate ambiguity. Enable
people to see, understand, and
act with confidence.
02 How should our components work?
Design Principles

16. Design principles are fuzzy
I will ruin your dreams
02 How should our components work?

17. Specific enough to help groups
of people choose between
different design options.
02 How should our components work?
“ Luke Wroblewski

18. 02 How should our components work?
Brainstorm
Discuss
Vote

19. 02 How should our components work?
Brainstorm
Discuss
Vote
Constraints and criteria
Specific enough to help groups of people
choose between different design options
Internal projects
Process
Always test your
riskiest assumptions
Prioritize page load
over decoration
or Execution

20. Brainstorm
02 How should our components work?
Vote
Targeted Review
How understandable is this principle?
What clarifying questions do you have?
Is this principle specific and objective
enough to help us choose between
different design options? Why or why
not?
How well does this represent Modus’
culture, values, and approach to work?
Discuss

21. Consistency is not king. Matching users'
current knowledge is more important than
consistency.
02 How should our components work?
Brainstorm
Vote
Discuss
Provide visual examples

22. 02 How should our components work?
Brainstorm
Vote
Leave your design corner
Discuss
Get feedback from engineers, product
managers, writers, and marketers.

23. Brainstorm
02 How should our components work?
Voting
Don’t delay feedback
Justified and defensible
Silent rounds of written feedback
Vote
Discuss

24. 02 How should our components work?
Refine your principles
When are principles not specific enough?
Sit in on meetings where teams use the
principles
Brainstorm
Discuss
Iterate
Vote

25. How flexible should our components be?
POLARIZING TOPIC

26. But how will this button work on
my great, great grandson’s hover
car dashboard?

27. We have to get our
components exactly right
the first time, because
changing them is hard.
VS
03 How flexible should our components be?
The design system helps
us change components
quickly and safely, so we
have room for error.
DON’T DO

28. Update once, propagate everywhere
03 How flexible should our components be?

29. UI Audit
Governance Plan
Integration
Strategy
Colors
Typography
Layout &
Spacing
Buttons
03 How flexible should our components be?

30. 03 How flexible should our components be?
More Difficult to Change
Naming conventions
Governance processes
Breaking changes to color, typography, and spacing
Visual Breaking Change in Design Systems by Nathan Curtis

31. 03 How flexible should our components be?
Test Before You Release
Start with Sketch symbols
Test symbol usage in daily work
See where the component needs to be more flexible
and iterate

32. 03 How flexible should our components be?
Make Contributing Easy
Proactive, continuous
user research
Use existing channels
Operationalize how people
contribute, and how you judge
their suggestions

33. Existing, Extended, or New Component?
POLARIZING TOPIC

34. Using a new component
when an existing one
solves the problem well
04 Existing, Extended, or New Component

35. Using an existing
component when a
new one solves the
problem better
04 Existing, Extended, or New Component

36. 04 Existing, Extended, or New Component

37. 04 Existing, Extended, or New Component

38. 04 Existing, Extended, or New Component

39. Does the New Component
Address usability issues?
Address accessibility issues?
Directly impact some business goal
Address a previously unknown scenario
04 Existing, Extended, or New Component

40. Anything and Everything
POLARIZING TOPIC

41. Take turns playing facilitator
05 Anything and Everything

42. 05 Anything and Everything
Responsible
These people do the work
Accountable
It’s their buns on the line
Consulted
Subject matter experts with valued opinions
Informed
Kept in the loop on progress and key milestones

43. 05 Anything and Everything
Gary Larry Harry Carrie Sharie Bob
Color R A C C I I
Typography R A I C I I
Tone and Voice C C R A I I
Page
Performance
C I I I R I
Code Style I I I I A R
Responsive
Behavior
R A I I A R
RACI Matrix

44. Thank You!
JD JONES @JAYMES_JONES