►
From YouTube: How designers can work together in the same team
Description
Pedro and Sunjung, Product Designers at GitLab, talk about the experience working in the same team during three months.
0:00 👋 Intro
03:32 💡 Pro tips: How to onboard & offboard more efficiently
08:58 👀 Things that we did during the partnership
15:09 🤝 Conclusion: Is such a shift worth it, even if it’s temporary? - YES!
A
All
right,
hello,
everyone,
my
name
is
piel
romero
de
silva
and
I'm
the
staff
product
designer
working
in
the
code
review
team
at
git
lab
and
today
me
and
sanju.
We
will
talk
about
a
partnership
that
we
had
during
three
months.
What
we
call
three
milestones
here
at
kit
lab
where
sanjiong
joined
us
in
our
team.
She
was
working,
another
team
and
she
joined
us
temporarily
as
a
product
designer
as
well
and
working
with
our
team
but
I'll.
Let
her
introduce
herself
as
well.
B
B
A
Exactly
yeah
perfect
introduction,
sanjong
yeah.
I
just
wanted
to
add
that
we
the
reason
that
sun
jung
stayed
with
us
during
that
time
and
it
was
temporary,
is
of
course
she
has
another
team
that
she
works
in,
but
because
the
code
review
team,
which
has
the
merge
requests
feature
at
kit
lab,
is
one
of
the
most
important
areas
of
our
product
is
where
all
of
the
collaboration
happens
in
for
the
users
and
when
our
organizations
are
using
gitlab
to
yeah
to
take
advantage
of
all
of
its
capabilities.
A
What
we
did
that
we
think
enabled
this
partnership
to
flourish
and
work
well
in
this
short
time
period.
What
are
the
things
that
we
personally
learned
from
this
experience,
and
that
is
more
the
personal
side
of
this
conversation
and
finally
we're
going
to
wrap
it
up
with
the
conclusion
and
what
we
recommend
for
the
partnership.
A
A
B
B
A
Yeah
yeah
one
other
thing
that
I
think
helped
with
that
onboarding
I
mean
you
mentioned
that
we
had.
We
provided
you
with
reading
materials
to
get
acquainted
as
fast
as
possible
to
what
we
were
doing
in
what
our
product
area
was
all
about.
But
I
think
it
was
also
important
to
work
with
others
outside
of
myself
and
you
to
set
the
right
expectations
and
so
yeah.
We
knew
it
was
three
months,
but
so
we
wanted
to
know
what
do
we
intend
to
achieve
with
these
three
months?
A
What
are
reasonable
expectations
to
set
for
myself
for
you
sanjo,
and
I
think
that
was
very
important,
but
again
I
mean
we
we
had
to.
I
think,
change
things
as
we
went
along.
You
know,
because
I
I
had
a
plan
in
the
beginning
and
I
thought
hey.
This
is,
I
think,
the
work
that
sanjong
would
appreciate
doing
and
what
also
aligned
with
our
goals
in
our
product
area,
but
we
had
never
worked
together,
so
it
was
also
kind
of
a
wild
guess
for
me
to
understand
what
best
fitted
your
work
style.
B
Yeah
it
took
some
time,
but
I
think
we
ended
up
managing
all
the
tasks
that
we
plan
to
or
that
we
needed
to
and
also
it
was
really
nice
that,
like
you,
also
recommended
me
to
schedule
some
of
the
coffee
chat
with
the
new
team
members,
the
doubt
was
also
really
helpful.
I
just
get
to
know
each
other
and
also
just
wanted
to
hearing
their
working
cell
because
it's
different
from
people
to
people
so
that
really
helped
for
me
to
import
it
to
the
team.
A
And
also
some
of
them
you
kept
in
touch,
so
I
mean
at
gitlab
for
those
of
you
who
don't
know
we
work
asynchronously
we're
a
completely
completely
distributed
company,
so
every
person
works
from
whatever
they
want
in
the
world
and
whenever
they
want
so,
and
so
we
don't
expect
others
to
be
online,
but
you
had
these
synchronous,
coffee
chats.
These
zoom
calls
with
other
people
in
the
team
and
some
of
them
you
kept
those
recurring
chats
right.
A
Awesome
yeah,
I
think
I
think
that's
those
are
great
things
to
to
know
for
other
people
that
are
experiencing
this
and
are
thinking
hey.
How
am
I
going
to
on
board
and
how
am
I
going
to
manage
the
work
that
I
had
from
the
previous
group
and,
as
I
say,
I
think,
setting
expectations
with
everyone,
not
only
in
the
new
group
that
you're
joining
the
new
team,
but
also
the
previous
team?
A
How
what
is
going
to
happen
with
the
work
that
you're
doing
and
what
kind
of
support
would
are,
is
reasonable
to
expect
from
you
yeah,
and
I
I
don't
know,
if
there's
anything
else
you
want
to
add,
or
if
we
can,
we
can
talk
about
things
that
we
did
more
specifically,
that
maybe
helped
us
work
during
this.
This
time.
B
So
I
really
enjoyed
that
and
also
the
the
another
thing
that
I
liked
was
about
having
like
one
single
source
of
true
as
retrospective
issue,
so
that
we
could
like
revisit
okay
this
month
it
went
okay
or
how
can
we
improve
in
all
the
all?
So
two
ux
managers
were
involved
in
also
the
product
manager,
like
counterparts
were
involved
in
and
they
provided
really
nice
feedback
so
that
we
could
improve
our
partnership
like
continuously.
So
I
really
like
that
part
and
yeah.
A
So
I
think
that
was
that
was
a
good
thing
for
us
and-
and
that's
also,
I
think,
allowed
us
to
gather
some
of
the
topics
that
we're
now
talking
about,
because
we
had
everything
documented.
It
was
easy
to
go
back
to
that
conversation
that
issue
what
we
called
internally
and
look
at
everyone's
comments
and
try
to
extract
the
themes
and
interesting
bits
to
talk
about
now.
A
Yeah.
Another
thing
that
we
did-
and
that
was
I
think
more
in
terms
of
the
planning
and
organization
of
the
work
inside
of
each
sprint
or
as
we
call
it
at
gitlab
milestones,
is
having
like
a
kanban
board,
a
place
where
we
could
see
all
of
the
work
that
was
assigned
to
ourselves
as
designers,
and
we
were
trying
to
have
every
issue
every
task
that
needed
ux
support.
A
But
I
I
mean
there's
a
balance
here,
but
I
think
we
had
to
direct
sanjong
as
much
as
possible
because
we
had
such
a
short
time
frame.
It
was
three
months,
but
it
flew
by
really
really
fast
and
so
yeah.
I
tried
to
direct
her
into
the
issues
that
she
and
the
tasks
that
she
needed
to
work
on,
so
that
we
started
working
as
fast
as
possible.
B
Yeah,
I
think
we
we
actually
both
needed
some
time
to
be
on
board
to
each
other's
working
style
because,
like
for
designer,
it's
like
not
common
to
having
two
designers
on
one
cross-functional
team.
So
I
think
what
we
did
like
assigning
ourselves
to
increase
the
visibility
that
okay,
this
design
issue
is
owned
by
petrol
and
the
other
issue
is
owned
by
me.
A
Exactly
yeah,
that's
that's
a
great
idea
to
assign
weights
to
the
tasks
or
issues
to
understand
how
each
person
works
and
what
they
found
find
difficult
or
large
compared
to
another
designer,
because
we're
short
on
time,
I'm
going
to
suggest
that
we
jump
to
the
conclusion
part
where
we
talk
about
the
pros,
the
risks
and
the
costs.
And
if
we
have
a
time
we
can
talk
about
the
things
that
we
learned
and
if
that's
okay,
so
I'm
going
to
suggest
that
we
each
pick
like
a
pro
a
risk
and
a
cost.
A
Yeah
so
yeah,
I'm
in
terms
of
for
me
pro
is,
is
it
was
a
very
positive
thing,
was
having
sun
jung
bringing
a
different
perspective
and
challenging
the
status
quo
and
triggering
new
ideas
just
because
she
was
coming
from
still
inside
of
gitlab.
She
was
coming
from
a
different
part
of
the
product,
a
very
different
part
of
the
product,
but
she
during
her
day-to-day
work.
She
was
already
using
some
of
the
features
that
we
were
working
on
in
code
review.
B
That's
good
to
hear,
and
for
me,
as
an
ic,
it
was
an
amazing
learning.
Experience
like
learning
from
you
learning
from
a
new
team
still
in
the
same
company
but,
as
you
mentioned,
is
a
different
area
of
our
product,
so
just
getting
used
to
just
getting
used
to
the
new
area
and
new
knowledge.
It's
it's
really
good
opportunity
for
me
to
grow.
A
We
had
two
designers
working
and
now
it's
only
me,
and
so
what
can
happen
is
that,
after
this
partnership
and
and
once
the
new
designer
leaves
in
this
sanjo
in
this
case,
sanjon
returns
to
her
team
that
her
work
may
become
stale
or
that
she
might
not
see
her
work
come
to
fruition,
and
so
these
are
some
of
the
risks
that
we
also
have
to
plan
accordingly.
To
make
sure
that
we
have
time
to
follow
through
with
the
work
that
she
was
doing.