►
From YouTube: Slippers Design System Architecture Decisions
Description
Brandon Lyon, Javier Garcia, Lauren Barker, and Tyler Williams discuss the Digital Experience team's architecture decisions for the Slippers design system.
Digital experience handbook page: https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/
Slippers architecture decision: https://gitlab.com/gitlab-com/marketing/inbound-marketing/growth/-/issues/752#note_467618241
Meeting agenda: https://docs.google.com/document/d/1vgUVwJ2ZT7iA_f3AEkU3LI-fwghUut_K3AdOapx3VRA/edit
A
All
right
we
are
finally
recording.
This
is
my
first
like
get
lab,
unfiltered,
zoom
meeting,
recording
so
a
couple
hiccups,
but
we
are
going
to
be
talking
about
the
architecture
decisions
we
made
for
slippers,
which
is
the
marketing
design
system,
and
we
kind
of
came
to
these
decisions
a
little
bit
before
the
new
year
early
mid-december,
and
it's
been
a
couple
weeks.
People
have
taken
some
vacations,
some
breaks,
we've
had
some
space,
and
so
this
is
sort
of
a
high
level
overview
of
what
the
decision
was.
A
Why
we
made
it
some,
you
know
known
unknowns,
unknown
unknowns
and
sort
of
a
refresher
and
recap
in
case
there
are
some.
You
know
new
thoughts
after
the
breaks
so
yeah
we
can
just
kind
of
hop
right
into
it.
So,
in
a
nutshell,
I
think
the
decision
we
came
to
here
is
that
we're
going
to
be
building
slippers
as
a
standalone
package.
A
I
think
to
begin
that's
a
node
package,
although
there's
definitely
options
for
that
to
be
hosted
in
a
variety
of
different,
like
packaging
platforms,
so
that
we
can
import
it
into
about
gitlab.com
and
any
other
appropriate
web
properties
and
we'll
sort
of
package
up
a
utility-based
css
framework.
That's
going
to
be
based
on
tailwind
and
our
own
usage
of
it
and
we'll
be
using
vue.js
to
build
out
some
components
and
storybook
to
sort
of
do
the
documenting
and
demonstration
of
those
components
and
so
yeah.
A
This
is
to
sort
of
help
us
meet
the
q4
fiscal
year,
21
digital
experience,
okr,
which
was
the
marketing
design
system,
epic,
and
this
was
the
infrastructure
strategy
for
that,
and
so
I'm
this
is
like
week
four
for
me,
so
I
was
gonna,
ask
the
the
the
other
three
of
you
on
the
call
to
sort
of
fill
in
the
gaps.
The
context
of
you
know
the
decision
making
here
what
it's
going
to
do
for
the
broader
gitlab
community.
B
B
Just
because
up
to
this
point
it
hasn't
been
all
that
consistent
and
so
we're
trying
to
go
back
and
see
in
which
ways
that
we
can
help
make
the
site
easier
to
develop
and,
in
turn
will
help
us
with
our
okrs.
I
think
that's
like
a
good
way
of
summing
it
up,
but
I'd
love
to
hear
if
anyone
else
has
more
thoughts.
C
Yeah,
so
I
think
some
of
the
difficulties
when
you
run
into
without
a
design
system,
anyone
can
make
anything
and
it
becomes
a
little
bit
of
a
chaotic
wild
west.
We
still
to
be
clear.
We
still
want
to
allow
people
to
contribute,
but
maybe
in
a
more
structured
fashion-
and
this
will
allow
us
to
have
a
cohesive
brand
identity
and
for
the
website-
and
you
know,
it'll
make
it
so
that
people
can
have
a
resource
to
look
at
where
they
don't
necessarily
need
to
know
how
to
code.
C
They
can
just
copy
paste
whatever
they
need
to
make
it
easier
for
them
to
contribute
if
they
are
maybe
a
little
less
code
savvy
or
a
little
less
familiar
with
the
code
base
or
things
like
that.
It's
kind
of
similar
to
you
know
the
principle
of
people
who
maybe
know
a
little
bit
about
development,
but
don't
want
to
build
all
the
things
can
pull
in
bootstrap.
It's
it's
a
similar
process
for
us
here.
We're
trying
to
create
a
system
that
someone
can
pull
in
and
you
know
product
has
pajamas.
C
However,
various
reasons
that
I
won't
get
into
here.
It's
not
suitable
for
us
this
time,
but
we
want
to
align
technologically
so
we're
going
to
try
and
make
sure
that
whatever
decisions
we
make,
you
know
can
use
their
tools
and
they
can
use
our
tools
so
we're
all
kind
of
in
the
same
court.
However,
you
know
it's
we're,
building
our
own
path
with
our
own
tool
here
that
will
still
hopefully
service
the
website
and
all
the
needs
of
people
using
it,
such
as
the
handbook
and
so
on.
D
A
A
Sorry,
my
talk
got
a
new
toy
for
the
holidays,
so
it
still
has
a
loud
squeaker
but
storybook,
I'm
really
excited
about
because
of
like
sort
of
the
inline
documentation
and
that
single
source
of
truth
thing
where
you
can
see
not
only
like
hear
our
documentation,
thoughts
on
it,
but
here's
what
it
really
looks
like
either
like
in
isolation
or
in
composition
with
other
things.
I
think
that's
really
cool
awesome.
Anything
else
before
we
hop
into
sort
of.
A
I
thought
the
next
thing
we
could
talk
about
is
sort
of
these
like
known
unknowns
or
like
questions
concerns
that
we
know
we
have
going
into
it.
Unless
there's
anything
else,
we
want
to
do
for
the
setup,
awesome
and
so
brandon
you
mentioned
pajamas
and
some
of
the
reasons
it's
like
not
suitable
for
the
work
that
we
need
to
just
for
solving
the
challenges
we
have
and
javi.
I
know
before
I
went
on
vacation,
you
mentioned
you
were
going
to
set
up
some
time
to
talk
with
pajamas
team.
A
B
Is
that
the
needs
of
pajamas
and
the
use
case
that
we
have
are
divergent
at
the
moment,
which
is
the
reason
why,
for
for
our
purposes
right
now,
it
makes
more
sense
for
us
to
do
this.
Other
thing,
I
think
that
you
know
in
an
ideal
world
we
would
want
both
of
these
things
to
be
living
together
and
so
right
now
it's
about
trying
to
figure
out.
Is
there
a
path
forward
for
that
to
happen?
If
so,
how
does
that?
B
Look
like
an
example
of
that
that
I
was
thinking
about
is
how
how
do
we
use
the
svgs,
and
how
do
we
make
sure
that
stuff
like
that
gets
to
be
consistent
throughout
the
site?
Just
because
from
how
slippers
foundation
is
looking
like,
it
looks
like
we're
going
to
be
relying
on
their
their
svgs,
the
ones
that
they're
using
within
pajamas
so
stuff
like
that
that
we
need
to
kind
of
sort
out.
D
A
Mcginnis
is
putting
a
lot
of
thought
to
that.
I
don't
have
any
other
details,
but
I
think
that
it
makes
sense
that,
as
we
move
forward
with
slippers
staying
in
close
conversation
with
pajamas
about
keeping
alignment
sharing
resources
where
it
makes
sense
to
doing
our
own
thing
where
it
makes
sense
to,
I
think,
there's
a
lot
of
opportunity
there.
A
You
know
sort
of
in
both
directions
and
I
think
that's
the
other,
like
one
of
the
cool
things
about
building
slippers
as
a
package
is
that
we
could
easily
import
it
into
pajamas
or
import
pajamas
into
it
as
a
like
peer
dependency,
or
something
like
that.
So
there's
a
lot
of
options
on
the
table
that
makes
us
sort
of
flexible
when
we
approach
it.
That
way.
B
So
I
think,
there's
definitely
an
opportunity
there,
especially
if
we're
theming
tailwind
to
our
own
liking.
It
makes
it
possible
if
they
had
set
it
up
properly
properly.
I've
tried
to
look
beforehand
to
see
if
they
have
a
tailwind
set
up
in
the
way
that
we
think
about
it
as
it's
done
in
slippers,
but
I
don't
think
they
do
so
anyway.
B
A
Awesome
thanks.
That's
really
good
insight,
it'll
be
really
useful
yeah.
I
think
the
other
thing
too
is
we've
talked
about
like
what
the
first
steps
here
look
like
and
sort
of
these
small
changes,
and
I
think
it'll
be
good
to
like,
and
that's
the
that's
one
of
the
values
here
right,
but
I
think
doing
the
small
changes
will
like
if
we
encounter
those
conflicts.
At
least
it
won't
be
on
like
a
huge
scale,
where
we've
built
something
massive
that
has
a
fundamental
conflict
at
its
core.
A
A
How
do
we
make
sure
that
slippers
is
useful,
regardless
of
what
happens
there?
I
I
feel
solid
about
that.
I
think
that
bundling
this
up
as
a
package
is
the
answer,
but
obviously
you
know
there
are
specifics.
Whatever
infrastructure
decisions
are
made
for
the
static
site
generator
and
those
tools
will
still
kind
of
impact,
how
we
go
about
integrating
slippers.
So
that's
something
to
keep
in
mind,
but
it's
for
me
like
a
low
concern.
A
A
We
have
to
spend
a
little
extra
time,
building
out
some
processes
and
doing
a
little
more
to
make
it
to
make
easy
paths
to
adoption
and
to
keeping
it
updated
and
living,
but
I
think
that's
great,
because
I
think
that
contributes
to
the
quality
of
it.
I
just
do
know
from
like
my
own
experience
with
past
design
systems.
This
is
the
place
where
things
fall
apart
right,
it's
not
the
it's,
not
the
infrastructure
decisions.
It's
not!
The
actual
design,
it's
how
much
like
how
easy
is
it
to
use?
How
adoptable
is
it?
A
How
adaptable
is
it,
and
if
it's
not
those
things
that
I
think
that
design
systems
tend
to
sort
of
die
out
very
quickly
but
yeah?
That
was
the
end
of
my
like
known
unknowns,
because
I
don't
know
how
that'll
all
shake
out,
but
I'm
feeling
really
optimistic
about
it.
Do
does
anyone
else
have
like
known
unknowns,
they
wanted
to
flag
and
bring
up
in
the
conversation
or
talk
about
that
last
one.
C
C
You
know:
design
system
components,
we
might
apply
raw
html
and
css
that
uses
design
system
files
coming
from
figma,
and
you
know
our
ux
ui
people
and
apply
that
to
a
page.
So
there's
a
little
bit
of
crossover,
we're
kind
of
in
a
middle
sort
of
transitional
spot
here,
where
we
don't
have
a
full
design
system,
tooling
built
out
yet,
and
so
we
don't
have
documentation
for
it
yet,
and
so
we
don't
have
a
tool
to
show
people
how
these
things
work
together,
visible
yet,
but
we're
working
towards
it.
A
A
So
I
think
that
I
imagine,
like
my
guess-
would
be
that
we'll
be
in
that
state
for
a
while
and
that
that's
fine,
like
I
think,
like
I,
I'm
of
the
opinion
that
those
sort
of
like
incremental,
like
being
like
halfway
in
halfway
out,
is
better
than
holding
off
and
waiting
until
we're
totally
ready
or
like
rebuilding
all
8,
000
pages
or
whatever.
Like
you
know,
I
know
that's
not
the
gitlab
way,
but,
having
recently
come
from
another
company
where
that
was
the
the
the
mode
of
operation,
it's
really
one.
A
A
Can
we
carve
out
some
time
to
pull
it
into
the
design
system
appropriately,
build
that
out
so
that
it's
done
well
done
correctly
and
like
done
in
the
way
that
we
want
slippers
to
be
done?
And
then
we
can,
you
know,
sort
of
reap
the
benefits
of
of
that
good
work.
So
I'm
excited
cool
anything
else
on
known
unknown
stuff.
That
has
come
to
mind
for
like
concerns,
javi.
B
A
Sweet,
I
also
have
a
header
for
unknown
unknowns,
which
is
always
a
weird
thing
to
ask
because,
like
by
their
definition,
we
won't
know
them.
But
I'm
wondering
if
things
have
come
up
in
our
conversation
here
or
like
in
the
break
or
like
broader
thoughts
on
concerns
and
stuff
if
anyone's
got
them,
I
feel
I
I
don't
have
any,
because
I
had
the
opportunity
to
think
about
this
and
write
down
my
known
unknowns.
D
C
Yeah,
I
think
that's
a
good
point,
there's
kind
of
a
lot
of
you
know.
People
are
always
building
and
adding
things
and
there's
a
lot
of
groups
that
claim
kind
of
stakeholder
ownership
of
a
certain
specific
fifteen
to
their
needs,
and
so
their
long
term.
We
may
end
up
creating
more
sites
in
the
mono
repo
directory,
where
each
has
a
different
build
set
up
or
we
may
try
and
you
know,
do
what
we
can
to
facilitate
their
needs
or
they
may
you
know,
have
things
they
need
to
adopt
for
facilitating
our
needs.
C
We
don't
really
know
it's
one
of
those
things.
We
don't
know
what
we
don't
know
in
theory,
it
shouldn't
be
too
much,
but
there's
all
kinds
of
custom,
ruby,
gremlins,
that
we
don't
know
that
are
there
that
we
run
into
from
time
to
time.
Like
one
example
that
comes
to
mind
is
recently,
we
were
working
and
we
updated
a
graphic,
but
we
didn't
know
that
that
svg
file
was
actually
being
generated
in
code,
and
you
know
the
was
being
referenced
by
pages
that
we
didn't
know.
C
B
I
think
part
of
it,
too,
is
how
do
we
convince
other
people
to
use
it,
and
I
think
that's
like
a
hard
part
just
because
if
someone
has
done
something
their
way
for
a
long
time,
even
if,
like
from
an
objective
standpoint,
it's
easier
one
way
or
the
other
just
because
they
understand
their
old
habits
better
than
they
understand
anything,
that's
new.
How
do
you
get
someone
to
break
out
of
that
habit?
B
A
Yeah,
I
think,
like
in
a
lot
of
ways
we'll
have
to
sort
of
like
I'm
really
excited
to
be
working
on
this
design
system,
and
I
think
a
lot
of
other
folks
are
too,
and
I
think
that,
like
you
know,
doing,
a
new
thing
is
always
exciting,
but
especially
something
like
this,
where
it
feels
like
we're
really
moving
forward
in
a
cool
direction.
But
I
think
that
also
brings
with
it
some
challenges.
A
Where,
like
we
may
be
more
excited
about
things
that
either
like
other
people
who
need
to
use
it
one
they
just
like,
don't
like
it,
which
would
be
too
bad,
but
maybe
more
realistically,
like
we're
excited
about
things
that
don't
add
value
to
the
other.
So,
like
that's
sort
of
like
the.
What
is
it
like?
Efficiency
for
the
right
people,
sub
value,
sort
of
thing
where
it's
like?
A
Let's
make
sure
that,
like
we
might
be
really
excited
about
this
component,
we're
working
on
or
like
these
specific
design
set
of
design
tokens,
but
perhaps
most
of
the
people
who
are
supposed
to
be
benefiting
from
what
the
work
we're
doing
in
slippers
needs
something
else
entirely.
And
so
I
think
we're
gonna
need
to
do
a
lot
of
yeah.
A
I
think
there's
probably
a
lot
of
work
in
the
collaborative
side
of
finding
out
who
needs
what
and
making
things
that
are
easy
to
use
and
like
resolve
those
problems
quickly
and
intuitively,
and
not
letting
our
own
excitement
like
this
is
like.
I
personally
know
that,
like
I
let
my
excitement
about
things
get
in
the
way,
sometimes
of
like
having
clarity
on
what
other
people
need,
because
I'm
just
excited
about
something
that
personally
excites
me.
A
Cool
so
yeah,
those
are
the
sort
of
like
concerns,
but
I
wanted
to
also
end
on
like
on
an
exciting
note,
because
this
is
such
cool
stuff,
and
I
can't
wait
for
you
know
the
next
couple
weeks
months
years
of
all
this,
and
so
I
wanted
to
talk
about
sort
of
again
just
like
pulling
back
high
level,
because
we've
been
talking
sort
of
in
the
weeds
about
what
happens.
If
this,
what
happens?
A
I
think
that
leaning
on
tailwind
css,
but
less
about
tailwind
as
like
the
framework
itself
and
more
about
the
utility
based
approach,
which
I
think
is
you
know,
regardless
of
like
an
actual
objective
merit.
I
think
that,
like
it
like
it's
the
trend
and
it's
the
it's
moving
up
in
the
trends,
I
think
a
lot
of
modern
web
teams
are
starting
to
use.
Utility-Based
css
and
I
think
it's
super
powerful
and
like
like
I'm
personally
excited
about
it.
A
I
think
that
there
are
some
like
technical
things
we
have
to
keep
in
mind
and
we'll
have
to
you
know,
be
very
love
to
be
very
judicial
about
where
we
use
it
and
why,
but
using
vgas
and
having
that
sort
of
in
our
wheelhouse
is
going
to
bring
us
into
alignment
with
a
lot
of
the
product
teams.
I
think
it's
going
to
like
improve
the
cohesion
there
and
the
collaboration
potential,
and
it
also
just
just
gives
us
really
powerful
tools
when
we
want
to
do
more
complex
things
through
our
marketing
properties.
A
I
think
it
expands
the
range
of
problems
that
we
can
solve
and
challenges
we
can
take
on
as
a
team
when
we
have
more
powerful
tools
and
I
think
it's
a
reasonable
tool
to
depend
on
it's
certainly
like
been
validated,
especially
at
gitlab
in
many
ways
and
yeah.
I'm
just
excited
like
this.
Video
comes
at
a
time
like
after
we've
sort
of
come
to
this
decision
had
time
to
think
on
it.
A
I
think
people
are
still
really
gelling
with
it
and
so
for
me,
especially
being
new
and,
like
super
excited,
to
get
started
on
stuff.
I
think
I'm
really
excited
that
we're
at
this
point,
because
it
means
we're
going
to
start
having
a
lot
more
like
visible,
tangible
deliverables
and
and
people
can
see
and
provide
feedback,
and
we
can
iterate
on
and
like
start
really
doing
this
work
so
yeah.
I
want
to
open
it
up
to
everyone
else.
D
C
B
B
Out
and
being
like
hey
like,
would
you
mind
giving
us
30
minutes
of
your
time
to
do
like
an
interview
and
seeing
like
in
what
way
you
use
the
about?
I
think
that
that
could
be
interesting
depending
on
the
needs,
because
I
from
I
guess
from
from
my
perspective,
it's
I
just
don't
it's
kind
of
in
the
unknowns
unknown
section
as
well,
where
it's
just
like.
I
don't
know
what
type
of
stuff
other
people
are
doing
here.
B
A
Well,
cool
thanks
everyone.
I
really
appreciate
the
time
you
all
took
for
getting
this
together
and
for
all
the
time,
like
all
the
good
conversation
and
stuff
that
led
up
to
this
and
like
I'm,
also
just
like
personally
grateful
to
be
like
joining
this
team
and
project,
because
it's
like,
like
lauren,
like
it's,
really
exciting
like
this,
is
such
an
exciting
thing
and
I'm
I'm
so
jazzed
to
be
getting
in
on
the
ground
floor
on
this
thing
and
that's
really
cool
so
yeah.