►
From YouTube: Design systems & iteration | GitLab Design Talks
Description
Taurie, Jeremy & Nick discuss iteration's impact on design systems and vice versa.
Links:
- Design system: https://design.gitlab.com/
- OKR: https://gitlab.com/groups/gitlab-com/-/epics/758
- Direction: https://about.gitlab.com/direction/create/ecosystem/frontend-ux-foundations/
A
B
A
C
C
We've
really
iterated
our
way
from
where
we
are
now,
but
we
started
with
just
a
ui
kit
in
sketch,
so
that
was
just
to
ensure
that
designers
had
a
consistent,
ui
library
to
pull
from,
and
we
knew
that
a
ui
kit
is
not
really
a
design
system,
there's
a
lot
of
other
aspects
to
a
design
system.
So
from
there
we
started
building
out
kind
of
more
of
a
skeleton
site
to
house
all
the
different
sections
and
areas
of
a
design
system,
and
we
just
added
a
bunch
of
to
to-do
notes
to
add
content.
In
later.
C
You
can
still
see
a
lot
of
those
there
because
we're
still
working
on
it.
We
didn't
like
push
out
an
entire
pajamas
website
with
like
fully
built
out
components
and
all
the
documentation
written
or
anything
like
that.
We
really
just
iterated
towards
having
all
of
those
different
aspects,
and
that
includes
like
other
content,
such
as
like
foundational
design,
tokens
or
design
principles
and
accessibility
content.
We
have
our
v-pad
in
there,
so
it's
really
just
been
iteratively,
adding
all
of
those
different
aspects
over
time
and
we've
also
been
updating
them
like
as
new
designers
join.
C
B
So
we've
you
know,
we've
also
updated
kind
of
our
tool
set
around
that
and
I
think
one
of
the
one
of
the
key
things
about
the
iterations
is:
it
happens
often
organically
and
not
so
much
planned,
and
there
is
a
lot
of
planning.
But
what
I
mean
by
that
is
that,
as
we
grew
a
great
deal
in
the
last
year,
we
would
have
some
things
that
were
set
in
stone
and
documented
and
then
you'd
have
new
designers
come
on
and
ask
questions
like.
Why
is
this
this
way?
What
about
this?
B
C
We
were
trying
to
figure
out
a
way
of
creating
a
process
that
allowed
designers
and
engineers
to
contribute
in
a
way
that
was
a
little
bit
structured,
so
they
had
something
to
follow,
so
we've
really
kind
of
iterated
our
way
through
creating
like,
for
example,
issue
templates
that
designers
can
follow
to
add
new
content
to
the
design
system.
We've
created
like
a
what
we
call
the
component
life
cycle
that
has
these
four
different
stages
so
which
is
like
you
know,
we
create
the
documentation
for
the
component.
C
A
B
Sure
I
think
that
it
it
can
help
just
by
being
able
to
to
kick
back
new
things
into
the
product
and
to
be
a
source
of
truth
for
those
ideas
and
and
a
place
to
point
to
so
it's
it's
not
a
like
a
dictatorship
where
some
design
systems
are
kind
of
like
this
is
the
overruling.
But
it's
it's
something
kind
of
under
undergirding,
our
our
thinking
and
and
it
allows
us
to
constantly
point
back
to
it
and
make
sure
that
as
git
lab
grows
and
new
features
grow.
B
We
have
something
to
leverage
to
iterate
on
and
to
build
on.
So
it's
it's
kind
of
building
a.
What
do
you
call
it?
A
not
a
gum
drop
but
like
a
jawbreaker
from
the
inside
out.
You
know,
rather
than
kind
of
dissolving
in
we're
kind
of
adding
these
layers
and
iterating.
Based
on
that
that
core
thinking.
C
Yeah-
and
I
also
add
that
pajamas
is
meant
to
help
increase
operational
efficiency,
so
by
having
kind
of
these
comprehensive
guidelines,
reusable
components
and
all
of
these
standards
designers
can
work
from
the
foundation
that
improves
efficiency,
which
means
that
tanks
can
iterate
faster,
so
kind
of
having
like
efficiency
and
iteration
go
hand
in
hand.
I
think
and
able
to
in
order
to
iterate
quickly.
It
needs
to
be
efficient
and
pajamas
helps
facilitate
that.
A
So
the
first
iteration
of
a
feature
may
just
be
like
a
text
field,
while
the
next
iteration
of
a
feature
may
be
more
enhanced
with
like
a
button
and
so
on,
and
then
you
sort
of
using
using
these
components
like
stepping
stones
and
to
quickly
add
more
and
more
things
on
until
finally
sort
of
a
a
better
configuration
of
features
of
of
ui
components
is
sort
of
arrives.
So
yeah
it's
been.
C
Yeah,
I
would
say,
iteration
looks
similar
to
working
on
the
product
I
like
to
think
about
a
design
system
really
just
in
the
same
way
as
you
would
a
product
for
that
users
have
it's
just.
Maybe
the
users
of
the
design
system
are
the
organization
that
you're
working
for
so
that
means
the
same
thing
that
we
would
say
for
any
other
product
like
boring
solutions
as
big
at
gitlab,
getting
the
smallest
thing
out
there
as
soon
as
possible,
and
then
getting
feedback
and
iterating
on
it
from
there.
C
I
mentioned
this
earlier,
but
like
just
adding
a
ton
of
to-do's
for
things
that
we'll
get
to
later
next,
and
I
also
think
it's
important
to
point
out
that,
even
though
we
work
with
an
mvc
mindset
for
the
design
system,
what
makes
it
into
production
needs
to
be
accurate.
So,
like
we
don't
just
merge
in
anything
because,
like
somebody
open
a
merge
request,
at
least
to
the
best
of
our
ability
like
no
one
is
perfect.
So
not
everything
is
going
to
be
like
super,
accurate
and
perfect
from
the
first
go.
C
System
is
something
that
the
entire
team
is
using
to
build
the
product.
We
don't
want
to
merge
things
in
the
spirit
of
iteration
that
we
know
are
confusing
or
not
helpful.
So
to
do
that,
we
want
like
we
want
to
start
with
small
merge
requests.
So
then
we're
adding
maybe
it's
accurate,
partial
documentation
to
something,
and
then
we
can
iterate
on
it
from
there.
C
C
You
know
I
knew
you
can
ask
me
that,
and
I
was
trying
to
think
of
an
example
before
this
call.
I
was
having
such
a
hard
time.
I
know,
and
I
know
I
come
up
with,
or
I
encounter
this
often
the
only
I
don't
know.
If
jeremy,
you
have
an
example,
the
only
example
I
could
think
of
when
I
was
thinking
it
through
this
earlier
was,
with
our
recent
drag
and
drop
documentation.
We
were
working
on.
C
We
left
out
a
bunch
of
content
that
we
hadn't
yet
defined
so
like
what
should
the
animation
look
like,
and
I
think
that's,
okay,
it's
better
than
just
be
as
long
as
we
say
like
this
is
something
that
we're
working
on
next,
like
we're
gonna
work
on
what
this
actually
means.
That's,
okay,
but
we
don't
wanna,
say
like
use
an
animation
to
do
this
thing.
We
want
to
say,
like
use
this
specific,
like
animation
type,
that
we've
defined
and
have
like
specific
guidelines
for
that.
C
B
B
We're
still
on
that
path
with
with
that
component
in
particular,
but
I
don't
know
if
that's
a
helpful
example
or
not,
but
that's
kind
of
one
of
the
ways.
What
of
how
iteration
might
look
like
from
a
design
standpoint
where
you're
kind
of
doing
tooling,
in
multiple
places
and
and
constantly
kind
of
evaluating,
where
it's
used,
how
it's
used?
Who
uses
it?
A
Yeah,
that's
that's!
That's
really
interesting.
I
think
yeah
iteration
can
take
many
sort
of
shapes
and
forms,
so
it
doesn't
necessarily.
It
doesn't
seem
to
necessarily
have
to
be.
Like
here's
a
feature,
here's
a
little
bit
more
of
a
feature.
Here's
a
little
bit
more
of
a
feature.
It
can
also
be
things
like
levels
of
fidelity
as
well.
A
So
like,
like
you
said
with
the
to
do's,
you
could
have
first
thing
would
be
like
a
sentence
and
then
a
to-do
or,
and
then
next
thing
would
be
maybe
adding
a
chart
and
then
next
thing
would
be
maybe
adding
a
couple
of
toggles
or
something
to
change
how
the
chart
looks
or
whatever
it
may
be.
So,
like
there's,
there's
different
ways
that
you
can
approach
iteration,
whether
it
be
fidelity
or
content
or
documentation,
layout
structure,
there's
loads
of
different
ways.
C
Yeah-
and
I
think
that
also
goes
back
to
like
treating
the
design
system
as
you
would
a
product
because
that
means
at
that
point,
you
have
to
build
out
a
road
map
for
how
you're
going
to
get
that
content
in
there.
So
the
same
as
you
would
build
a
roadmap
for
some
feature
set
within
getlab.
We
need
to
do
the
same
thing
for
the
design
system.
B
I
I
would
say
the
biggest
challenge
is
making
sure
that,
as
you
iterate,
everything
is
iterating
right,
so
you
can
iterate
in
pajamas,
but
that's
isolated
to
a
degree
from
the
product,
and
so,
if
we
and
we're
experiencing
this
now,
you
know
you
update
something
as
simple
as
a
hex
value
in
the
product
in
gitlab
ui.
If
you
don't
change
the
way
that
gitlab
thinks
about
that
hex
value,
then
then
not
everything
is
going
to
be.
B
You
know
iterative,
it's
not
going
to
catch
up,
and
so
it's
making
sure
that
you
know
as
you're
building
up
the
clock.
All
the
gears
are
connected
and
kind
of
telling
the
right
time,
and-
and
I
found
that
that's
one-
you
know-
that's
definitely
one
of
the
challenges.
It's
just
making
sure
that
that
iteration
keeps
momentum
through.
You
know
the
entire
life
cycle
of
its
like
intended
goal
and
use.
A
Cool,
so
one
of
the
things
that
I
was
wondering
about
when
I
first
joined
gitlab
is
understanding
that
iteration
was
such
a
like
widely
used
value.
It
was
like
really
really
taken
seriously
in
gitlab.
I
was
just
wondering
how
do
you
manage
like
an
ever-changing
ui
within
the
product
in
order
to
make
sure
that
customers
don't
go
crazy
when
a
button's
here
one
day
and
then
they're
the
next
and
then
they're
the
next
like?
How
do
you
actually
manage
the
yeah,
the
user
experience
of
iteration.
C
Yeah,
I
think
that's
one
of
the
main
reasons
why
we
started
the
design
system,
so
there's
at
least
some
sort
of
guidance
or
guidelines
around
how
to
use
each
of
these
individual
parts.
So
then,
even
while
the
ui
is
ever
iterating
or
ever
changing,
there's
at
least
some
semblance
of
usage
guidelines
that
help
designers
know
how
to
use
which
component
and
where
to
use
it
and
and
how
to
structure,
content
and
all.
C
That
come
together
to
form
the
user
experience
and
that's
not
to
say
that
the
design
system
is
like
the
sale.
There
can
definitely
be.
I
think,
jeremy
touched
on
this
earlier.
There
can
definitely
be
like
outliers
or
things
that
are
done
separately
from
the
design
system.
There
should
just
be
reasons
for
those
for
those
kind
of
changes
or
things
that
don't
match
what
we
have
in
the
design
system.
B
Yeah,
I
think
that's
good
and
and
to
add
on
that
you
know
we
do
we
document
everything,
and
so
one
of
the
things
that
I've
found
that's
helped
is
to
actually
document
where
those
changes
are
headed
so
that,
as
a
user
encounters
a
change
in
the
ui
or
somebody
you
know
internally
so
often
is
like
why?
Why
did
this
happen?
Did
something
just
change
here?
Is
this
known?
B
You
have
some
documentation
to
point
back
to
to
say:
yes,
that's
that's
known,
and
we
realize
you
know
this
is
kind
of
the
mvc
for
this,
but
this
is
where
we're
headed
that
really
helps
a
lot,
because,
as
a
as
a
designer,
when
you
have
thought
ahead
in
that
way,
you're
more
comfortable
knowing
some
of
the
things
that
are
going
to
trip
up
along
the
way
you
you
understand
that
hey
we're
migrating
buttons
and
we're
going
to
have
two
buttons
next
to
each
other
that
are
potentially
conflicting
because
one's
been
migrated.
One's
not
we're.
B
C
Yeah,
well
I
mean
what
we're
working
on
right
now
in
q3
of
this
quarter
is
just
migrating,
some
components
from
pajamas
into
the
into
production,
the
gila
production.
So
this
quarter.
It
includes
migrating
eight
components.
We
have
few
and
hamill
components,
so
we
want
to
get
those
utilizing
what
we
have
in
our
design
system.
Beyond
that
we
have,
I
mean
everyone
in
the
ux
department
and
engineering
and
product.
Really
anyone
can
contribute
to
the
design
system,
so
ensuring
that
we
have
processes
in
place
that
help
facilitate.
C
That
is
always
going
to
be
part
of
our
direction,
because
the
foundations
team
can't
do
this
all
on
our
own.
We
really
look
towards
the
people
who
are
working
directly
with
users
to
help
guide
us
and
what
our
direction
should
be
and
then
there's
a
bunch
of
other
initiatives,
specifically
that
jeremy's
been
working
on.
Maybe
he
can
touch
on
them
a
bit
around,
like
accessibility
he's
been
working
on
color
palettes.
B
Yeah
lots
of
lots
of
things,
so
yeah
story
mentioned,
like
color
palettes
things
that
that
are
kind
of
under
the
hood
that
that
are
going
to
make
the
product
better
as
as
some
of
the
migration
happens.
So
if
it's
color
palettes
for
accessibility
that
you
know
the
buttons
leverage
when
they
get
migrated,
if
it's
documentation
behavior
all
that
kind
of
stuff,
you
know
we're
kind
of
we're
trying
to
come
at
it
from
multiple
ways,
both
what
you
see
visually,
but
also
how
it's
built
and
and
there's
there's
also
a
lot
of
research.
B
A
B
I
would
just
say
like
yeah:
no,
no
help
is
too
small
or
not
appreciated
right.
It's
all
appreciated
and
it's
all
helpful,
there's
multiple.
You
know
in
this
cycle
of
iteration
there's
multiple
on-ramps
and
so
whether
you're,
more
development-minded
or
more
design-minded
or
accessibility-minded,
or
even
just
the
ux
of
of
a
certain
thing.
There's
there's
always
going
to
be
an
on-road
to
it.
It
doesn't
mean
you
have
to
take
something
from
a
to
z
and
and
see
it
through
the
whole
way.