►
From YouTube: Collaborating around objects | GitLab Design Talks
A
A
C
A
Really
excited
to
be
speaking
with
both
of
you
really
talented
designers,
so
our
value
of
collaboration.
Maybe
you
can
just
kick
off
and
tell
me
a
little
bit
about
what
it
cut.
What
collaboration
has
been
like
since
for
you,
since
joining
gitlab
you've
both
been
here
at
different
times,
so
it
may
be
interesting
to
see
how
how
how
your
perception
of
collaboration
may
have
shifted
or
whatever.
So
maybe
we
can
start
out
with
holly
and
she
can
tell
us
about
collaboration
and
then
and
then
pedro.
B
Well,
pedro,
I
think,
has
been
here
longer
than
I
saw.
I
am
curious
to
hear
his
his
perspective
on
it.
I've
been
with
get
lab
for
about
a
year
and
a
half,
and
when
I
think
of
collaboration
here,
I
think
of
asynchronous
communication
and
the
challenges
that
have
come
along
with
sort
of
being
involved
in
a
lot
of
conversations
at
one
time
online.
B
So
that
would
be
a
bit
of
a
challenge
that
I've
encountered
from
a
collaborative
standpoint,
but
gitlab,
I
think,
does
a
really
good
job
of
trying
to
encourage
team
members
to
really
communicate
about
what
they're
working
on
we
share.
We
have
the
ux
showcases.
We
have
slack
channels.
We,
of
course,
collaborate
in
the
issues
and
mrs
themselves,
so
I
think
that
it's
become
a
lot
easier
for
me,
but
it
took
a
little
bit
of
time.
C
Yeah,
well,
I
would
say
collaboration
is
a
very
interesting
value,
because
I
mean
all
of
them
are,
but
in
a
way,
I
think
collaboration
is
an
overlap
or
has
the
most
overlap
with
all
of
the
other
values
of
results,
iteration
efficiency
and
diversity,
and
inclusion
and
belonging
and
yeah.
I
think
at
the
end
of
the
day,
it's
just,
I
think,
about
being
kind
and
a
nice
person
to
work
with,
but
that
is
not
enough,
because
sometimes
you
need
to
know
how
to
communicate.
C
Well,
I
think
that's
one
of
the
main,
the
keys
about
collaboration
is,
you
have
to
know
how
to
get
your
point
across.
You
have
to
know
how
to
listen,
but
also,
at
the
end
of
the
day,
we
need
to
put
everything
aside
and
focus
on
what
matters
and
that's
just
moving
the
ball
forward,
regardless
of
who's.
Moving
the
ball
forward
who's,
given
their
opinion,
we
have
that
value
or
rule
of
no
consensus
is
required.
C
So
it
only
takes
one
person
to
decide
and
move
the
ball
forward
and
we
do
that
in
a
kind
way
in
a
way
that
is
respectful
of
others,
time
of
others,
backgrounds
as
well
like
using
language
and
that
anyone
can
understand
and
being
inclusive
in
that
way
as
well.
So
yeah,
I
think
it's
it's
an
overlap
of
so
many
different
things
and
at
the
end
of
the
day,
it's
just
like
being
a
good
co-worker
and
in
our
case
we
collaborate
also
with
our
users
and
customers.
So
that's
that's
even
more
extended
in
that
regard.
A
Super
so
I
think
that's
a
really
interesting
point
that
you
bring
up
that.
The
way
you
communicate
is
it's
an
intrinsic
part
of
our
value
of
of
of
collaboration,
and
I
think
that
applies
not
only
to
like
our
process
for
how
we
approach
and
implement
and
develop
and
design
and
and
all
that
wonderful
stuff
that
happens
within
our
our
validation
and
build
tracks.
But
I
think
we
can
also
apply
that
same
sort
of
communication
based
thinking
and
and
focus
on
language.
A
So
I
wonder
whether
you
you
both
have
been
working
on
on
some
really
interesting
things
recently
within
gitlab,
adding
to
our
design
system,
some
bigger
level
frameworks.
So
maybe
maybe
you
can
both
sort
of
go
into
these.
These
conceptual
model
frameworks
sort
of
give
people
an
introduction
as
to
why
and
what
they
are
and-
and
we
can
go
from
there.
C
B
C
C
Was
more
productive
in
a
more
productive
collaboration,
because
if
we
were
simply
looking
at
the
ui,
which
is
the
simplest
thing
to
do,
and
the
easiest
thing
is
just
to
look
at
what
we
have
in
front
of
us.
We
miss
in
a
lot
of
a
lot
of
details
and
it's
difficult
for
us
to
take
a
step
back
and
realize
what
other
paths
are
available
to
us
or
what,
where
what
are
we
missing
from
this
problem
or
from
the
solution?
So
one
example
that
I
can
share
today.
C
Let
me
bring
that
up
it's
from
instrumentation,
so
in
we
have
this
epic
to
instruments.
Code
review,
so
code
review
is
a
is
a
new
group
that
was
created
in
gitlab.
It
was
a
split
from
a
an
older
group,
the
source
code
group
and
right
now
we
need
to
define
the
mao,
which
means
monthly,
active
users
and
to
define
that
to
know
how
many
users
are
actively
using
our
features,
we're
first
focusing
on
our
main
object,
the
merge
requests
and
so
kai
the
pm.
C
An
aggregate
way
of
looking
at
all
of
these.
The
usage
of
merge
requests,
which
would
then
give
us
the
monthly
active
users
for
our
group,
and
so
one
of
the
things
that
I
realized
was
it
was
would
be
it's
easy
for
us
to
come
up
with
this
list.
If
we're
just
looking
at
merge
requests
and
we
look
at
the
sidebar
and
we
see
oh,
merge
requests
have
labels
and
they
have
participants
and
notifications,
and
you
can
close
them.
C
You
can
open
them
by
looking
at
the
ui,
but
then
I
realized
we
were
missing
some
things
that
are
much
easier
to
look
at
if
you
look
at
the
conceptual
model,
so
in
the
conceptual
model
of
merge
requests,
which
just
looks
at
the
object
itself
without
any
concern
of
ui,
we
already
have
a
lot
of
what
we
needed
to
know
what
we
needed
to
instrument
right.
We
have
all
of
the
attributes
and
then
all
of
the
actions
create
edit
delete
and
so
on.
C
So
for
me
it
was
really
easy
to
help
kai
come
up
with
the
list
or
extend
the
his
initial
list
by
looking
at
all
of
the
action
that
we've
already
identified
like,
for
example,
one
of
the
things
that
was
missing
were
approval
rules,
actions
on
the
approval
rules,
so
it
was
just
as
easy
as
extracting
all
of
these
and
adding
them
to
the
lists.
So
this
was
one
example
of
using
the
conceptual
model,
and
I
made
some
suggestions
here
and
then
andrei.
He
made
a
suggestion
about.
Oh
what?
If
what?
C
If
we
should,
we
track
the
toggling
of
a
new
mode
that
we've
introduced,
which
is
to
review
one
file
at
a
time.
We
call
it
a
file
by
file
mode.
Is
this
something
that
we
want
to
track
as
part
of
user
engagement
and
the
usage
of
of
our
features?
And,
and
so
what
then
I
I
turned
and
their
attention
to
the
semantic
layout
right
and
then
the
fact
that
some
actions
are
considered
transactional
and
others
not
so
much
right.
C
So
an
action
that
changes
the
attribute
state
of
the
object
is
transactional
and
something
that
that
is
that
doesn't
change.
Those
attributes
or
states
is
usually
a
purely
visual
action
right,
so
in
this
case
changing
the
mode
of
visualization
of
if
you're
reviewing
one
file
out
of
at
a
time
or
you're
looking
at
multiple
files.
At
the
same
time,
that
is
a
user
preference
that
only
changes
how
they
visualize
the
object
and
the
attributes
of
that
object.
C
So
it's
not
it's
something
that
we
need
to
track
separately,
but
it's
not
the
usage
of
the
object
itself.
It
doesn't
impact
the
attributes
that
we've
seen
here.
So
this
was
a.
I
think
a
nice
example
that
that
touches
on
both
things,
one
is
the
conceptual
way
which
is
completely
abstracted
from
visualization
and
then
how
we
lay
it
out
on
top
of
the
main
ui,
so
that
we
can
then
look
at
the
actions
and
attributes
in
context.
C
A
I
want
to
take
a
little
step
back
and
and
sort
of
discuss
the
the
pain
point
between
the
the
different
teams
within
git
lab
that
led
to
us
having
to
think
about
applying
objects
to
our
design
system.
I
know
myself
when
I
first
came
to
gitlab
I
I
saw
our
design
system.
I
thought
it
pajamas
absolutely
great,
and
then
I
looked
at
our
product
and
I
saw
that
there
was
actually
a
lot
of
inconsistency,
but
that
inconsistency
didn't
arise
from
a
lack
of
documentation
around
our
components.
A
So
the
analogy
that
I've
used
in
the
past
is,
if
you
can
think
of
components
like
words
in
a
sentence,
you
can
string
those
components
together
and
use
the
correct
words,
but
whether
or
not
you
string
them
together
in
the
right
order
gives
it
meaning.
So
it
felt
like
our
design
system
had
these
words,
but
it
was
lacking
a
particular
grammar
and
that's
where
I
felt
like
the
there's,
the
opportunity
for
for
the
usage
of
objects
or
a
conceptual
model
or
or
whatever
it
may
be.
B
B
So
if
I
just
share
my
screen,
can
you
see
my
screen
perfect?
Thank
you.
So
we've
been
working
on
some
some
customizable
issue
types
concepts.
We
currently
have
the
concept
of
an
issue
and
we
recently
have
implemented
incidents
as
an
issue
tight
and
one
of
the
ways
that
I
have
been
looking
into
sort
of
breaking
down.
These
concepts
has
been
similar
to
what
pedro
is
doing,
not
not.
B
Quite
as
detailed,
though,
I
do
think
that
what
you've
done
will
help
to
inform
my
work,
but
what
I
realized
through
these
customizable
issue
types
concepts
is
that
I
needed
to
really
understand
the
the
words
of
the
sentence
in
this
situation.
So,
if
we're
going
to
have
an
incident
issue
type
for
example,
what
are
the
words
that
need
to
make
up
that
sentence
of
an
incident?
What
are
the
things
that
need
to
be
in
that?
And
how
does
that
change?
The
sentence
from
an
issue?
B
C
Yeah,
I
I
think
it's
the
more
and
more.
We
explore
objects
and
just
more
less
you
ui
work
and
less
ui
guidelines
and
less
specifically
ui
components.
I
think
the
easier
it
will
be
to
collaborate
with
our
counterparts,
product
management
and
engineering,
because
it
will
be
easier
for
them
to
discuss
things.
C
I
mean
it's,
it's
not
easy
for
for
them
to
discuss
like
should
we
use
radio
buttons
or
check
boxes
or
a
modal,
or
I
mean
that
that
should
be
up
to
us,
the
product
designers,
but
when
it
comes
to
more
general
thinking
about
the
problem
that
we're
solving
the
words
as
nick
was
saying,
like
there's
this
this
metaphor
very
similar
to
what
you
were
suggesting
nick
about
the
objects
which
the
object
where
the
objects
are,
the
nouns.
The
actions
are
the
verbs
and
the
attributes
are
the
adjectives
in
the
sentence
right.
C
So
when
you,
even
when
you
hear
users
in
research
when
you're
interviewing
them
and
they're
always
referring
to
something-
that's
probably
the
the
nouns,
the
verbs
and
the
adjectives
that
you
should
also
use
in
your
ui,
because
that's
what
they're?
That's
how
they're
describing
their
experience
or
their
needs
or
their
problem,
and
so
the
more
we
get
into
that
more
meta
level.
Micro
level.
C
I
think
it
will
be
easier
to
have
those
conversations
and,
at
the
same
time,
I
think
we
will
be
able
to
solve
problems
better
as
product
designers,
which
will
in
a
way
render
those
issues
that
we
have
of
inconsistency
render
them
irrelevant,
because
if
we
solve
the
problem
right,
it
will
be
much
easier
for
us
to
apply
the
right
paradigms
and
the
right
components.
It
will
be
a
non-issue.
B
A
A
I
think
there's
a
great
opportunity
that
we
have
within
lab,
based
on
our
context
of
being
so
transparent,
as
well
as
working
asynchronously,
where
there
is
the
need
for
more
concretely
documenting
this
type
of
material.
So
I
don't
have
the
answer,
but
I
feel
like
the
right
answer
could
definitely
appear
within
our
context.
A
B
C
Yeah,
I
I
agree.
I
I
mean
I
had
one
question,
but
I
think
we
were
almost
that
time,
but
it
was
yeah
what
else
other
than
than
objects.
Are
we
missing
in
for
better
collaboration,
not
only
between
designers
but
with
other
people,
but
I
think
that's
it's
another
conversation
on
its
own,
probably
but
yeah
it's.
C
Basically,
I
think
that's
what
needs
to
be
done,
because
there
are
so
many
parts
of
gitlab
that,
honestly,
I
I
don't
know
about,
and
it's
it's
impossible
for
anyone
right
now
to
know
everything
about
gitlab.
So
we
need
everyone
to
contribute,
and
hopefully,
as
nick
was
saying,
we
are
in
a
unique
position
to
create
a
mark
in
the
world
about
how
design
operates
at
this
level,
but
also
given
that
we're
an
open
source
project
mainly
and
have
contributions
from
everywhere.
C
I
think
that's
an
added
layer
of
complexity
and
challenge,
but
I
think
in
the
end
that
just
forces
us
to
be
more
transparent
and
have
simple
language
and
ubiquitous
terminology
so
that
everyone
can
understand
and
contribute.
So
I
think
that's
a
challenge
with
our
design
system
is
also
making
it
accessible
to
everyone.
Even
if
you're,
not
a
designer
or
engineer.