►
From YouTube: Design Systems Aren’t Hard - Dustin Younse, Indeed
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
to
the
talk,
my
name
is
Dustin
yachts.
This
is
Design,
Systems
aren't
hard,
but
they
are
complex
and
also
hard
on
the
internet,
I'm
known
as
Mills
Yap
Taff,
which
is
a
name
I
picked
in
1998,
and
just
never
got
around
to
changing.
I've,
been
working
on
large
website
since
roughly
2008
been
working
with
design
systems,
since
we
used
to
call
them
swatches
or
even
just
style,
tiles
I
currently
work
in
design
engineering,
and
indeed,
which
is
a
job
that
I
think
comes
with
probably
the
greatest
laptop
sticker
around.
A
So
you
might
be
asking
yourself
what
exactly
is
a
design
system?
I
first
saw
this
graphic
from
Nate
Baldwin
and
a
talk
at
artifact
conference
fall
of
2019.
It
really
drove
home
just
how
many
different
definitions
there
are
to
the
term
design
system.
Just
how
complicated
it
can
be.
Each
of
those
circles
is
an
artifact
and
the
team
made
that
artifact,
whether
it's
you
know
the
UI
kit,
the
component
library,
the
documentation,
a
lot
of
people,
don't
think
about
content
strategy.
A
A
A
A
If
you
take
a
look
at
this
graphic
one
more
time,
we
can
see
that
each
of
these
artifacts
is
coming
from
a
different
team,
either
communicating
or
not
communicating
with
other
teams,
something
like
documentation,
maybe
it's
owned
by
a
team,
or
maybe
it's
owned
by
technical
writers.
The
UI
presentation
layer
could
be
owned
by
a
UX
department,
while
the
actual
UI
kit
and
the
visual
design
language
is
owned
by
maybe
a
brand
team
or
a
marketing
team
teams
that
you
know
don't
necessarily
work
together
on
a
day
to
day
basis,
and
that
doesn't
really.
A
You
know
clear
things
up
when
you're
trying
to
think
about
what
a
design
system
is.
So,
let's
think
about
it
from
a
different
angle.
What
isn't
a
design
system?
A
figma
library?
That's
not
a
design
system,
you
know
figma
library
or
a
UI
kit
built
with
some
other
tool.
It
could
have
all
of
your
components
in
it
could
have
all
of
your
colors
all
of
your
buttons
and
show
people
how
your
your
menus
look
yeah.
This
is
going
to
represent.
A
Maybe
one
team's
idea
of
the
design
system
really
well,
but
it
may
not
be
perfectly
suited
to
another
team.
You
know
developers
they
like
figments
a
lot
nicer
than
using
some
other
software
at
times
for
a
developer
to
get
in
and
get
the
data
that
they
need
to
make
the
product
that
they
need,
but
it
doesn't
tell
them.
You
know
it
often
doesn't
tell
them
things
like
how
things
look
when
they
animate
or
what
they
look
like
when
a
page
transitions.
A
A
This
is
the
kind
of
thing
the
developers
always
want
when
they're
talking
about
design
system,
they
want
something
that
lets
them
do
the
least
amount
of
work
when
it
comes
to
building
new
product
new
interface,
a
react
component
library
is
a
great
way
to
share
code
easily
helps
you
build
functional
prototypes
or
even
entire
products
really
quickly
with
a
minimum
of
custom
code.
But
this
still
isn't
a
design
system.
A
So
what
else?
An
external
website
promoting
your
design
system?
You
know,
I,
think
we
all
loved
to
check
out
the
latest
design
systems
are
being
released
by
some
of
the
big
companies
out
there.
The
you
know
the
Google's,
the
git
hubs,
all
kinds
of
really
great
things
to
look
at
things
to
learn
from
lightnings
been
doing
really
great
work
with
web
components.
A
Polaris
is
amazing
for
theming,
but
these
are
actually
not
designed
systems
either.
These
these
are
just
kind
of
a
snapshot
frozen
in
time
of
the
system
that
that
company
is
actually
using
internally
a
lot
of
times
these
public
versions
that
they
release
they
can
lag
by
months
or
even
years
behind
what
is
actually
being
used
inside
of
the
company.
A
A
We're
talking
about
user
interface,
design,
how
the
digital
experience
looks
interaction,
design
how
it
feels
you
know
when
you're
actually
clicking
around
you're
going
through
and
using
the
software
content
strategy.
Again.
This
isn't
always
super
obvious,
but
this
is
a
huge
part
of
a
design
system.
We
need
to
know
how
our
digital
experience
should
sound
to
the
customer
when
they're,
when
they're
reading
our
interface
and
near
and
dear
to
my
heart
documentation.
We
need
to
know
how
this
digital
experience
is:
crafted,
whether
we're
designers
or
developers,
whether
we're
in
marketing
it
doesn't
matter.
A
A
Design
systems,
unfortunately,
they
take
time
they
take
time,
because
it
takes
time
to
reach
an
agreement
on
big
things
on
small
things.
You
might
be
surprised
to
learn
just
how
long
it
can
take
to
agree
about
something
as
simple
as
button
you
know,
just
your
standard
primary
button
can
be
weeks
or
months
of
back-and-forth
in
negotiation.
A
Maybe
you're
testing
your
ideas
and
your
assumptions
in
your
life
product
using
a/b
testing.
This
is
going
to
take
time
here
are
the
primary
buttons
from
by
five
different
design
systems,
they're
all
very
similar
they're
all
buttons.
They
all
have
text,
you
can
click
them
and
they
do
a
thing,
but
they
don't
have
very
distinct
differences,
whether
it's
color
or
shape
shadow.
A
Sometimes
a
design
system
will
have
put
icons
on
a
button.
Sometimes
it
won't
on
the
Internet.
The
button
is
one
of
your
primary
interaction
points
with
a
customer,
and
that
means
that
a
lot
of
people
have
a
lot
of
opinions
about
inside
of
your
company
and
it's
going
to
be
a
large
source
of
frustration
when
you
start
building
a
design
system,
so
you
need
to
be
prepared
for
that.
A
A
A
When
everyone
on
your
team
knows
how
a
thing
should
be
built,
they
can
just
go
build
it.
They
don't
have
to
stop
and
think
they
don't
have
to
ask
questions.
They
just
know
in
my
current
job
I'm
working
on
design
systems,
and
we
do
a
lot
of
support
more
support
than
you
might
think,
and
the
absolute
number
one
question
we
get:
how
do
I
do
X?
A
How
do
I
use
a
primary
button?
How
do
I
use
a
secondary
button
in
relation
to
a
primary
button?
How
do
I
invoke
a
modal
and
the
number
two
question
why
this
is
you
know
as
important,
if
not
more
important
than
the
first
one,
to
give
people
the
ability
to
do
things
on
their
own?
They
need
to
know
not
only
what
they
should
do,
but
they
also
need
to
know
why
they
should
do
it
so
that
the
next
time
they
encounter
a
problem.
A
Believe
that
a
design
system
is
a
service,
not
a
product,
and
this
it
can
be
difficult
inside
of
companies
to
convince
people
of
this.
They
want
to
treat
it
like
a
product.
They
want
to
do
roadmaps
as
if
it
was
a
product,
but
at
the
end
of
the
day
it's
not
it's
a
service,
it
is
providing
answers.
It
is
deciding
on
new
answers
to
new
questions.
It's
you
know,
helping
people
integrate
the
design
system
with
a
new
product
or
an
existing
product.
A
You
know
legacy
code
bases
that
power
large
chunks
of
corporate
websites
are
very
hard
to
get
design
systems
working
sometimes,
and
that
is
the
job
you
know
treating
it
like
a
service.
You
know
having
support
channels
having
dedicated
people
in
those
support
channels,
people
who
aren't
writing
code
that
day,
all
they're
doing
is
there
to
ask
questions.
Answer
questions,
because
really
you
need
to
answer
questions
not
read
code.
A
Coming
back
to
this
picture,
you
know
again
there's
a
lot
of
artifacts
here.
What
do
you
think
is
the
most
important
one?
What
would
you
guess,
I
think
if
you
come
from
a
design
background,
you're,
gonna
kind
of
tend
towards
the
ones
that
are
kind
of
reddish,
pink,
the
UI
presentation,
layer
or
the
components
or
the
UI
kit,
if
you're
a
product
person
you're
gonna,
be
very
drawn
to
the
purple,
you're
gonna
want
to
talk
a
lot
about
processes.
A
If
you
only
have
the
time
or
the
money
to
do
one
thing
and
do
it
well,
what
should
it
be?
I
would
say:
documentation,
I,
think
documentation
is
the
single
most
important
piece
of
the
puzzle.
A
design
system
we've
already
talked
about
is
made
up
of
agreements.
You
need
to
write
those
agreements
down.
You
can't
just
say:
oh
well,
you
know
two
months
ago
in
a
meeting
on
Tuesday
somebody
said
this,
so
let's
do
that.
A
A
If
you
have
the
budget
I,
don't
strongly
recommend
you
hire
a
service
designer.
This
may
not
be
a
job
pal
you've
heard
of
before
I
hadn't
before
I
started
my
current
job,
a
service
designer
is
there
to
think
about
people
and
think
about
infrastructure.
You
can
think
of
them
as
the
personification
of
documentation
and
customer
support.
They
may
often
come
from
a
UI
background
or
development
background,
but
they
are
there
to
think
from
you're
a
busy
about
the
customer.
A
They
can
help
drive
adoption
of
new
design
systems.
If
you
know
you
have
a
deadline,
you
need
to
have
a
design
system
rolled
out
by
a
certain
date.
They
are
absolutely
invaluable.
They
are
the
extroverts
to
the
to
the
development
and
design
introverts.
They
will
make
the
relationships
they
will.
You
know
find
the
data
convince
the
stakeholders
that
need
to
be
convinced.
A
And
finally,
your
documentation
should
change
as
often
as
necessary,
shouldn't
think
of
it
as
set
in
stone.
You
know
we're
not
rating
things
in
spiral
notebooks,
but
you
should
think
about
what
kind
of
software
that
you
use
when
you're
writing
down
your
documentation.
It
should
be
something
that's
easy
to
edit
quick
to
edit
that
everybody
has
access
to
I
would
recommend
not
using
a
git
repository
I.
Think
that's
a
common
pitfall
for
teams.
A
You
know
developers,
they
love
git
repositories,
they
love
markdown,
but
that's
not
the
friendliest
for
designers
or
product
designers
love
things
like
figma.
They
love
to
write
things
down
in
there.
That's
not
the
friendliest
for
a
developer,
so
think
you
know
think
about
something
kind
of
abstracted
something
agnostic,
I've
seen
people
use
things
like
notion
really.
Well,
you
can,
you
know,
obviously
use
something
like
Google
Docs.
It's
got
a
lot
of
great
tools,
one
of
the
nice
things
about
something
like
Google
Docs
is
it
lets.
A
At
the
end
of
the
day,
design
systems
can
be
used
to
help
everyone.
That's
a
great
thing
when
I
say
everyone,
I,
don't
just
mean
designers
and
developers,
but
specifically
the
users,
users
that
aren't
always
thought
about
design
systems.
Give
you
accessibility
at
scale.
They
give
you
a
system
that
you
can
be
reasonably
assured.
A
button
is
gonna
work
as
a
button
links
are
gonna
work
as
links.
A
A
You
can
be
sure
that
when
you
pull
in
a
form
field,
it's
going
to
accept
accented
characters.
It's
going
to
accept
various
types
of
Unicode,
like
somebody
wants
to
put
an
emoji
in
a
field,
it'll,
probably
work.
If
you've
made
one
form
field
work
that
way
they
should
all
work
that
way
things
like
right-to-left
text
presentation,
it's
just
going
to
work.
This
is
an
incredibly
difficult
thing
to
do
on
just
about
every
product.
A
I've
ever
worked
on,
but
once
you
do
it
once
and
you
do
it
right,
it's
really
easy
to
use
that
across
all
of
the
different
places
where
you're
displaying
text
in
our
in
our
products
that
indeed
we
actually
have.
We
are
global
company.
We
have
lots
of
job
postings
that
are
mixed
languages,
and
this
is
a
very
complicated
thing
to
fix,
but
once
you
fix
it
once
it's
it's
fixed.
A
If
somebody
wants
to
write
a
job
title
in
Japanese
in
a
job
description
in
English
easy
somebody
wants
to
write
a
job
title
in
German
and
a
job
description
in
Arabic.
It's
done.
That's
great,
so
always
think
about
how
you
can
take
those
hard
problems
that
need
to
be
solved
and
figure
out
a
way
to
solve
them.
Once
for
everybody
drive
that
that
scale
of
inclusion,
let's
scale
of
accessibility.
A
So
if
you
learn
nothing
else
from
this,
talk
learn
this.
If
you
do
nothing
else
write
documentation,
if
you
can
do
nothing
else,
plus
one
thing
hire
a
service
designer
Design
Systems
are
hard
and
that's
the
work
and
that's
okay,
there's
you
know
in
our
industry.
It's
it's
really.
It's
really
tempting
to
try
and
make
things
easy
for
ourselves
as
designers
and
as
developers
at
the
expense
of
ease-of-use
for
an
end
user,
and
we
need
to
avoid
that
trap.
We
need
to
do
the
hard
work.