Design leader and UX/Design Ops author Marti Gold shares her best practices for creating a usable design system. That's a design system that PEOPLE WILL ACTUALLY USE. Without making it anyone's full time job to maintain. Presented at Firecat First Friday, June 2021. Firecat Studio hosts UX, Usabillity, Accessibility, Digital Marketing, Creative and like topics to further our mission of making the world better, one experience at a time. https://firecatstudio.com

1. M A R T I G O L D | J U N E 2 0 2 1
USABLE DESIGN
SYSTEMS
F I R S T F R I D A Y
Creating and
Implementing
1

2. M A R T I G O L D | J U N E 2 0 2 1
About Me
My name is Marti Gold, and I’m the Director of Strategic
Experience Design for SiriusXM-Pandora.
I work in the Automotive Division, which means my team is
focused on HMI innovations for the in-car experience –
which can be completely different for every OEM, car model,
and trim level.
Therefore, I must have a Design System that gives my team
the freedom to iterate and quickly create designs for every
unique requirement and every possible aspect ratio, for
every car in the world.
Contact: marti.gold@siriusxm.com
2
B I O

3. M A R T I G O L D | J U N E 2 0 2 1
So, what is a
‘Design System’
and why do
I need one?”
“
3

4. M A R T I G O L D | J U N E 2 0 2 1
Defining a “Design System”
I N T R O
4
It is the addition of guidance,
to ensure understanding on
why a particular pattern is used,
that distinguishes a
Design System from other formats.

5. M A R T I G O L D | J U N E 2 0 2 1
A long time ago, I was Creative Director at
Travelocity, where I created that company’s
Online Style Guide. It took months to build,
and needless to say, I was very proud of it. But
in September of 2013, I heard noted UX
speaker Jared Spool, say the following:
But to understand
how to make them
truly usable, I have
to tell you a story...
5
S T O R Y

6. M A R T I G O L D | J U N E 2 0 2 1 6
In RULE-BASED design,
style guides are created so that
UNINTENTIONAL DESIGNERS
can ACCIDENTALLY
create great designs.
– Jared Spool
“
The problem is that
design style guides
NEVER WORK.
People stop using them.”

7. M A R T I G O L D | J U N E 2 0 2 1
I N T R O
“Rules Based Design” means precisely what it says:
A system based on a series of rules that must be
followed in order to maintain consistency.
• They are usually far too prescriptive and
detailed.
• They take a long time to create.
• They are time-consuming to maintain.
Designers are then required to create using
pre-designed templates filled with pre-designed
elements – and they hate it.
Worse, these systems always lead to the same
circular sequence of events...
7
Although I didn’t want to believe it at the time,
it turns out he was absolutely right.
Image of a highly
complex style guide

8. M A R T I G O L D | J U N E 2 0 2 1 8
Stakeholders present a
use case that needs an
“exception”
New
Standards
are created
and
published
Designers say no and
try to enforce their new
standards
Stakeholders bypass
design and take their
change requests to Dev
Production pages
become increasingly
inconsistent
The first non-compliant
pages appear
Someone says,
“I know…
we need standards!”

9. M A R T I G O L D | J U N E 2 0 2 1

10. M A R T I G O L D | J U N E 2 0 2 1
So why does this happen?
I N T R O
I began researching the cyclical nature of updating style
guides/standards in 2013. If I was experiencing this, others must be
as well.
Turns out I was correct. My book, UX Style Frameworks, was
published in 2015. Around that same time, a number of other highly
workable solutions began emerging. Within the next few years, full
blown Design Systems began evolving quickly.
BUT...
10
Some of the inherent usability issues cannot be solved
simply by adding guidance or updating the documentation
to support new types of reusable components.

11. M A R T I G O L D | J U N E 2 0 2 1
The good news?
Your Design System can break this cycle.
I N T R O
Design Systems are still just a
communication tool.
In the second half of this deck, I’ll
walk you the process of kicking off
the creation of a Design System.
11
But before you go through all that effort,
how do you know people will actually use it?

12. M A R T I G O L D | J U N E 2 0 2 1
Ironically, there are five “rules”
that can help ensure your
design system is not “rules based”
so it remains usable for YOUR organization.
12

13. M A R T I G O L D | J U N E 2 0 2 1
Rule #1:
There can
be only one.”
Caption for the photo
13
R U L E S
“

14. C O N F I D E N T I A L
Multiple sources
means conflicting
information.
Let’s say you have a Marketing department, a UX department, and a
Development team all using their own guidelines or libraries.
My research shows that out of 124 common elements and
interactions*, 93% will be defined in at least two of them.
What are the chances that all three of those sources are in sync?
* 124 elements taken from Bootstrap component list + a few additional items. From the
book “UX Style Frameworks, Creating Collaborative Standards”
14
R U L E S

15. C O N F I D E N T I A L
Conflicting
information means at
least one set of docs
is wrong…
15
R U L E S
You need to insist on one source
that is accessible to everyone...
• Marketing
• User Experience/Product
Design
• Product Management
• Developers
• External Vendors (optional,
but ideal)
… and once people
lose trust in the
documentation,
they will ignore it.

16. M A R T I G O L D | J U N E 2 0 2 1
Rule #2:
You only
have five
minutes.”
Caption for the photo
16
R U L E S
“

17. C O N F I D E N T I A L
How standards die...
Your designer has a
pressing deadline, and
needs to know what
shade of blue to make
the “submit” button.
Designer checks
“standards
documentation” and
finds eight different
shades of blue in three
different documents.
Designer gives up and
goes to the website in
production. They find a
“submit” button, then
use a screenshot/eye
dropper or a CSS
Inspection tool to get
the hex code.
Developer then codes
the button to match the
color specified by the
designer, usually
without even checking
to see if the color specs
conflict with the code
repository.
17
P R O C E S S
...and this is how you
end up with submit
buttons in 37 shades of
blue.
In which case, you
might as well be using
inline styles.

18. C O N F I D E N T I A L
Ask yourself these questions...
• How many people have actually read your
standards? Have you?
• Do different departments within your org maintain
different standards documentation?
• Do those docs contain conflicting information?
Within the same source?
• Do they have an index? A search function?
• Do they exist in electronic form or are they .pdfs?
18
S E C T I O N
If you want to maintain standards, EVERYONE must be
able to find the spec they need in less than five minutes.

19. M A R T I G O L D | J U N E 2 0 2 1
Rule #3:
Hold on
Loosely.”
38 Special In Concert
19
R U L E S
“

20. C O N F I D E N T I A L
“Perfection is Unattainable”
When creating or revamping your
standards, beware the dangers of...
• Defining too many elements
• Over-specification
• Over-engineering
If you do these things, the first
business case will need an
“exception” – and you will be trapped
in the cycle you saw earlier.
Give your designers the building
blocks, but then let them DESIGN.
20
S E C T I O N
Not This
This

21. M A R T I G O L D | J U N E 2 0 2 1
Rule #4:
Say What
You Mean.”
21
R U L E S
“

22. C O N F I D E N T I A L
You must adopt a consistent vocabulary
Sadly, many things in the digital
world use the same word to
describe two completely different
things. Companies develop their
own internal understanding, but
problems can emerge when
employees move.
If an business owner insists on
having an “overlay,” what do they
actually mean?
22
R U L E S
...the business owner expected
this.
The designer and developer
created this...

23. M A R T I G O L D | J U N E 2 0 2 1
Rule #5:
Think
Republic,
not
Dictatorship.”
23
R U L E S
“

24. C O N F I D E N T I A L
Standards controlled by a single department
almost always fail.
They usually fail for one of these three
reasons:
• It is impossible for one department to
keep the documentation up to date and
to communicate changes to everyone
that is impacted.
• It is impossible for one department to
fully understand the needs and
requirements of the others.
• The authors are not always right.
24
R U L E S

25. M A R T I G O L D | J U N E 2 0 2 1
For your Design System
to survive it must be
collaborative.
Everyone should share a
sense of ownership,
responsibility, and pride.
25
R U L E S

26. M A R T I G O L D | J U N E 2 0 2 1
Rule #5a:
Beware of
Bikeshedding.”
26
R U L E S
“

27. C O N F I D E N T I A L
It is easy for teams to become focused on the
design system and delay real work.
Everyone must remember that a
Design System is a TOOL. It only
exists to speed up actual work.
Because these systems provide
designers a sense of control, it is
easy to lose track of priorities
Sharing ownership among teams,
adding Design System stories to
your sprint planning, setting a max
number of the hours per week,
and rotating tasks/ designers will
help eliminate this problem.
27
R U L E S

28. M A R T I G O L D | J U N E 2 0 2 1
The Five Rules of a Usable Design System...
“There can be
only one.”
28
R U L E S
“Hold on
loosely”
“You only have
five minutes”
“Say what
you mean”
“Think republic,
not dictatorship”
AND
“Beware of
bikeshedding”

29. M A R T I G O L D | J U N E 2 0 2 1
With the Five Rules
in mind,
where do you start?
“
29

30. M A R T I G O L D | J U N E 2 0 2 1
When starting this process, always
remember that building a Design System
is NOT your goal.
Your goal is to create real deliverables
quickly and efficiently, with as little
rework as possible. A Design System is
only a tool that supports that goal.
30
B U I L D

31. C O N F I D E N T I A L
Step 1: Conduct some basic user research
Remember you are building a tool, so your employees are your
users. It’s shocking how many companies completely overlook
this key step when planning a Design System.
Find out the following:
• How many departments currently have guides/standards
of some kind (style guides, libraries, asset repositories,
etc.) How are those systems used? What do they
include? Can you get a copy?
• If there are multiple standards, why does each group feel
their version works best for them?
• What does each department want to keep? What should
be tossed out? What worked and what didn’t?
31
B U I L D

32. C O N F I D E N T I A L
Step 2: Hold a cross-department kick-off workshop
A Kick-off workshop gets everyone in one place at one
time to level set expectations and goals.
• Talk open and get a commitment to share the use
and support the System,. Because of Rule #1
(“There can be only one”), this agreement is
important.
• Present and review the research found in Step 1
and ask for any clarifications. This will help define
the scope of the System
• Ask each department to select a representative
from their department to be part of a Working
Group. (more on next slide).
32
B U I L D

33. C O N F I D E N T I A L
Step 2 (con’t): Create a DACI chart
A DACI sets expectations regarding cross-departmental contributions
and communications during the building stage of your Design System.
D - Driver. The person who is coordinating the effort (often a PM)
A - Approvers. The stakeholders who will ultimately need to approve
the work. Should be limited to 2 or 3 max.
C - Contributors. The Working Group that is actually constructing the
initial draft of the Design System. These are the people selected to
represent each of the key departments. That person will gather their
department’s requirements and represent that department in any
collaborative efforts or negotiations.
I - Informed. Those who need to be informed about the progress of
the Design System, but are not engaged on a day-to-day basis.
33
B U I L D

34. C O N F I D E N T I A L
Step 3: The Contributors then gather requirements
and select a publishing platform
What platforms must your design system support? (Web,
mobile, smart speaker, etc.)
What asset types must be supported?
Those will often determine which publishing platforms or
tools should be evaluated. Any tool on this short list must
be able to...
• Integrate into each department’s existing workflow
with a minimum of disruption.
• It must permit collaborative feedback and editing
(comments, co-editing based on permissions, etc.)
• It must be able to present all necessary asset types
so these can be documented, located, and
downloaded.
34
B U I L D

35. M A R T I G O L D | J U N E 2 0 2 1
Quick Sidebar:
What is
“Atomic Design”?
Atoms: Basic UI elements that cannot be broken
down any further (icons, buttons, input fields, etc.)
Molecules: Atoms that form a more complex
reusable component (such as a search bar - contains
an input field, search button and icon.)
Organisms: Even more complex components
that include both molecules and atoms (i.e. a top
navigation bar.)
You will hear a lot about a methodology
created by Brad Frost known as Atomic
Design. In Atomic Design, there are
five distinct stages. Each stage builds
on the previous, acting as an
aggregate of items from the preceding
stages.
1
2
3
Templates: Organisms are combined into a
template of empty blocks for use across multiple
pages.
4
35
S I D E B A R
Pages: The final stage where specific instances of
templates are created. Based on your use cases,
completed pages will help evolve your templates.
5

36. M A R T I G O L D | J U N E 2 0 2 1
Less Important Sidebar:
My Team’s
Variation of
Atomic Design
For my team, I use a somewhat similar
construct, but have removed the
concept of templates and pages.
Instead, we have a flexible grid system
at our base. In addition, my lowest level
includes core typography and colors. I
called this base level “Scaffolding.”
S I D E B A R
Atoms: Basic UI elements that cannot be broken
down any further (icons, buttons, input fields, etc.)
Molecules: Atoms that form a more complex
reusable component (such as a search bar - contains
an input field, search button and icon.)
Organisms: Even more complex components
that include both molecules and atoms (i.e. a top
navigation bar.)
1
2
3
4
36
Scaffolding: The underlying structure on which
everything else is built. Includes flexible grids,
colors, typography

37. C O N F I D E N T I A L
Step 4: Organize your assets into their proper level
and define any missing atoms.
Depending upon the structure you select, the Contributors
can now begin assigning assets to their proper level
(Scaffolding, Atom, etc.).
• At this point, most managers are shocked to realize
that your teams have been designing/developing at
the “Organism” and “Page” level.
• As a result, you may have a virtually infinite variety
of atoms and molecules. (remember the “submit
button with 37 shades of blue”?)
37
B U I L D
The Contributors should
CULL RUTHLESSLY at this stage.
Everything must earn it’s place.

38. C O N F I D E N T I A L
Step 5: Only do Scaffolding and Atoms, then STOP
and publish what you’ve done for feedback.
IMPORTANT: Great Design Systems are never presented to the
organization as a “Grand Reveal.” Invite everyone on your DACI
chart. Use this meeting to...
• Explain the publishing tool you’ve selected and why.
• Present your scaffolding and atoms as examples of the
proposed granularity of documentation, how the system will
be organized, and its ease of use.
• Ask for feedback from everyone, and demonstrate how to
they can add feedback into the actual system on their own
time (comments, questions, etc.).
• Gather the feedback and iterate at this level before
proceeding to molecules and organisms.
38
B U I L D

39. M A R T I G O L D | J U N E 2 0 2 1
Once you get to
this point, relax.
You have a
Design System.
The remaining work
is just iterations.
39
C L O S I N G

40. M A R T I G O L D | J U N E 2 0 2 1
Your Design System is just a tool.
It should provide your designers with
information, tools and materials to improve
their efficiency.
It should not prescribe
design solutions for them.
40
C L O S I N G

41. M A R T I G O L D | J U N E 2 0 2 1
THANK YOU!
41