►
From YouTube: UX Showcase: Sustainable cross-stage collaboration
Description
Pedro Moreira da Silva, Staff Product Designer in Create:Code Review, talks about how we as a design team can create a better way to enable cross-stage collaboration.
Slides: https://docs.google.com/presentation/d/1FghahwOe63z0RK5GDJBS7xTkDgUw0u2KwJajgHKBktU/edit?usp=sharing
Merge request: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/77771
A
So
this
is
a
very
common
expression
that
comes
up
almost
ever
should
come
up
every
day
at
gitlab
right,
so
boring
solutions.
We
see
something
in
the
product
that
someone
already
implemented.
We
don't
know
how
long
ago,
but
someone
did
maybe
yesterday
maybe
four
years
ago-
and
we
say
I
know-
let's-
let's
just
reuse-
that,
like
some
team
implemented
that
so
we
we're
we're
good.
We
can
buy
us
by
ourselves
some
time,
and
probably
users
are
already
accustomed
to
that.
A
So,
let's
reuse
that
as
a
pattern
right,
but
the
problem
is
especially
for
most
designers
and
uxers
that
are
recent
to
the
company
into
the
product
is
that
they
lack
knowledge
right,
and
so
they
do.
What,
for
example,
mike
in
previous
presentation
shows
that
he
had
to
go
down
the
rabbit
hole
to
understand
it.
So
we
go
through
all
of
the
discussions.
A
All
of
the
issues
merge
requests
documentation
that
we
can
find
to
look
for
a
rationale
and
for
decisions
just
to
make
sure
we're
in
the
right
location
and
like
like
a
child.
We
we
end
up
doing
that
many
many
times,
just
to
make
sure
that
we
got
it
right
and
it
seems
like
every
designer
and
every
technical
writer
and
every
ux
researcher
is
being
born
again,
trying
to
learn
all
of
these
things
over
and
over
again,
because
they're
not
documented
and
there's
no
clear
rationale
for
them.
A
So
another
problem
then
happens
when
teams
try
to
reuse.
What's
there
today
is
that
they
create
a
picture
based
on
assumptions.
So
it's
a
bit
like
the
broken
telephone
game
where
we
take
all
of
the
knowledge
and
the
discussions
and
decisions
in
russia.
Now
that
we
could
find
we
tried
to
map
all
of
that
in
our
head
and
yeah.
Maybe
maybe
that's
that's
the
intention.
Maybe
this
is
the
purpose
of
this
pattern.
Maybe
this
is
how
it
should
be
used.
Maybe
this
is
how
we
should
implement
it
technically.
A
So
we
put
all
of
those
pieces
together
based
on
assumptions,
and
the
final
thing
about
all
of
this
is
that
this
is
just
duplicate
work.
As
I
said
we
keep
doing
this
over
and
over
again
and
in
the
beginning
I
mentioned
people
that
are
for
here
at
gitlab
for
a
short
time,
but
this
happens
many
many
times
I
mean
at
least
for
me.
It
happens
many
many
times
already
in
my
tenure
at
gitlab,
and
so
this
comic
strip
describes
that
very
well.
A
So
that's,
I
think,
even
the
worst
cost,
so
this
has
compounding
negative
effects
that
I
think
we're
all
more
or
less
aware
of
that.
It
creates
more
technical
and
ux
debt.
It
creates
more
collaboration
costs
because
we
have
to
keep
repeating
things
and
asking
people
where
this
came
from
if
we're
doing
the
right
decision,
less
coherent
and
consistent
user
and
developer
experiences.
A
So
not
only
what
is
in
the
user
interface
and
the
user
facing
experience,
but
also
the
people
that
are
developing
and,
as
we
know,
their
gitlab
has
had
a
massive
growth
over
the
last
years,
and
so
the
people
that
are
coming
in
are
inheriting
a
lot
of
the
decisions
and
are
just
you
know,
assuming
from
what's
already
there.
So
maybe
it's
a
good
decision,
maybe
not
less
velocity,
of
course,
and
at
the
end
of
the
day,
the
bottom
line
is
less
value
to
everyone,
less
revenue
right.
A
So
this
is
here's
an
example.
This
is
a
screenshot
from
the
async
critique
critique
that
we
did
in
figma
for
the
merge
requests,
and
this
is
specifically
looking
at
all
of
the
merge
request.
Widgets,
and
you
can
see
the
amount
of
comments
here.
I
think
most
of
you
here
on
this
call
already
familiar
with
this,
but
just
to
show
you
the
scale
of
possibly
all
of
the
inconsistencies
that
exist
right.
Not
all
of
these
comments
and
all
these
screenshots
show
inconsistencies,
but
I
would
argue
that
the
majority
are
inconsistencies
or
even.
A
Implementations
that
follow
a
seemingly
a
pattern
that
we
think
exists
at
the
end
of
the
day.
That
pattern
is
not
the
best
solution
for
the
problem
at
hand,
so
this
is
basically
a
result
of
contributions
of
their
years
from
different
parties,
with
no
guidance
and
vision.
So
the
million-
or
should
I
say,
billion
dollar
question
right,
because
that's
that's
what
we
want
and
we're
aiming
for
a
billion
dollar
business
is:
how
can
everyone
contribute
sustainably?
Everyone
can
contribute
is
what
we
are
aiming
for
right.
So
how
can
we
do
that?
A
I
think
of
two
things.
So,
first
one
frameworks
to
guide
contributions
and
seconds
very
tightly
related
to
the
first
one
is
clear
collaboration
responsibilities.
So
what
does
that
mean
in
practice?
So
the
first
thing
frameworks
to
guide
contributions,
there's
a
link
at
the
top
to,
I
think,
a
still
open,
merge
request
that
I'm
hoping
to
have
merged
this
week.
That
is
focused
just
on
the
collaboration
of
teams
that
are
contributing
to
the
merge
request
experience.
A
So
the
the
these
frameworks
that
I,
in
that
merge
request,
I'm
calling
them
contribution
frameworks
the
lack
of
a
better
term.
I
don't
I'm
not
very
fond
of
the
term
if
you
have
suggestions,
I'm
open
to
to
that,
but
basically
there
are
just
guidelines
on
how
to
plan
design
and
build
solutions
that
are
coherent
and
consistent.
A
Current
experience
from
both
a
user
and
again
technical
perspective.
So
not
only
what
we
think
as
design
design
but
design
in
a
broader
sense,
also
the
technical
side
of
how
it's
designed-
and
we
actually
have
something
very
similar
in
our
handbook
today
in
the
product
designer
workflow,
it's
at
the
very
bottom,
and
maybe
not
a
lot
of
people-
remember
this
or
have
gone
that
far
down
to
to
this
section.
A
A
But
what
I'm
arguing
here
is
for
something
that
is
not
just
focused
on
ui
patterns,
but
it's
larger
than
that
right
and
I'll
give
some
examples
at
the
end,
and
the
next
part
is
clear
collaboration
responsibilities
because
we
can
say:
hey.
That's
a
great
idea:
let's
build
these
frameworks,
let's
document
these
guidelines
from
a
design
and
development
perspective,
but
who
who
does
that
right
and
we
need
to
have
clear
responsibilities
and
accountability
by
the
people
that
need
to
do
these
things.
A
So
one
of
the
things
that
I
from
it
was
a
suggestion
that
kai
my
product
manager
made
about
perhaps
using
the
rassi
models,
which
is
basically
a
model
that
very
simple
you
just
say:
who's
responsible
who's,
accountable,
who's
consultant
and
who's
in
foreign,
at
different
steps.
And
here
what
I
did
was
map
the
phases
on
the
left
side
of
the
the
table.
A
We
have
a
column
from
the
for
the
product,
development
flow
phases,
design
solution,
validation,
plan
and
so
on
and
mapping
those
to,
in
this
case,
your
group
and
the
code
review
group
and
how
we
would
collaborate,
and
so
who
is
responsible,
who's
accountable.
Who
should
be
informed?
Who
should
be
consultant
at
each
step
of
the
way
and
for
me
the
most
important
one
is
at
the
bottom
and
it's
bolded,
which
is
to
contribute
to
an
established
contribution
framework.
A
So
you
can
look
at
and
merge
requests
it's
it's
larger
than
this,
and
it
has
much
more
rationale
or
you're
free
to
ask
questions
at
the
end
of
this
presentation
about
it.
But
basically
what
I
really
want
is
for
groups,
regardless
of
who's,
working
on
something
to
feel
the
responsibility
of
we
went
through
this
process.
We
made
these
decisions,
and
this
is
why-
and
let's
document
this
as
fast
as
possible,
so
that
other
groups
can
learn
from
that
and
so
yeah
in
this
case
compounding
positive
effects.
A
A
But
to
do
this
we
need
one
platform
mindset,
so
we
need
to
we're
always.
I
think
we
try
to
do
it,
but
in
a
way
we
keep
ourselves
confined
to
our
stage
groups
right.
So
I'm
a
product
designer
in
create
code
review,
but
maybe
I
should
be
thinking,
I'm
a
product
designer
of
one
devops
platform
right
and
the
same
thing
for
technical
writers,
your
technical
writers
are
not
just
technical
writers
for
the
stage
group.
A
Most
of
the
things
that
they're
doing
for
their
stage
group
will
be
helpful
and
will
be
used
and
will
be
leveraged
years
from
now
or
tomorrow
by
other
people.
So
they
should
be
thinking
that
everything
has
this
butterfly
effect
and
also
ux
researchers
and
ux
researchers
and-
and
I
I
also
think
that
product
designers
when
we're
doing
research.
A
A
One
interface
one
conversation
thread
one
day
at
a
store:
zero
headaches.
But
again,
this
is
all
amazing.
I
don't
think
just
thinking
about
this
is
enough.
We
need
to
create
space
for
this
mindset.
We
need
to
do
that
intentionally
and
it
will
take
away
focus
from
other
things.
So
here
are
some
examples
on
the
on
the
right
side,
but
basically,
what?
A
What
do
I
mean
by
this
space
is
giving
uxers,
regardless,
if
they're
technical
writers,
ux
researchers,
product
designers,
identify
time
and
to
identify
opportunities
for
cross-stage
collaboration
and
time
to
plan
and
create
contribution
frameworks,
and
the
first
example
is.
I
think
this
presentation
that
you're,
seeing
today
that
I'm
presenting
to
you,
is
one
of
many
things
that
has
resulted
from
the
fact
from
the
opportunity
that
we
had
for
sun
jung
to
join
us
in
code
review,
and
so
I
have
been.
A
The
other
example
is
one
thing
that
I
we're
starting
to
do
right
now
in
q2
is
making
the
case
for
amy
ian
and
jeremy
to
create
a
framework
for
the
merge
request,
widgets,
where
they
will
act
as
true
one
platform
uxers,
and
they
will
need
to
collaborate
with
others.
But,
for
example,
jeremy
is
from
the
ux
foundation
team,
and
he
already
has.
A
I
believe
this
one
platform
mentality,
but
it
would
be
much
more
applicable
compared
to
what
he's
doing
in
the
more
in
the
design
system
and
ian
hean
is
working
in
the
package
group
and
package
doesn't
have
any
merge
request
widget.
If
I'm
not
mistaken,
I
don't
think
that
group
has
any
widgets
there,
so
he
will
be
completely
out
of
his
out
of
his
natural
environment
to
work
across
stages
as
a
one
platform.
A
Ux
and
amy
will,
of
course,
collaborate
with
other
technical
writers
and
finally
one
example
that
we've
heard
very
often
recently
is
the
navigation
and
settings
redesign.
That
michael
has
been
spearheading
and
doing
an
amazing
job,
but
we
need
to
keep
that
up,
because
this,
as
we
all
know,
has
compounding
positive
effects
and
even
for
ian
taking
time
away
from
package
doesn't
mean
that
package
will
not
reap
the
benefits
it
will.
Every
stage
group
will
reap
the
benefits.
A
A
So
here
are
some
examples.
I
won't
go
through
all
of
them.
This
is
just
to
to
complete
the
picture,
some
examples
of
opportunities
for
contribution
frameworks,
one
that
is
very
straightforward,
discussion
activity,
which
includes
threads
comments
and,
more
so
many
groups
that
could
leverage
from
framework
or
for
just
documentation,
development
and
design
documentation.
A
We
need
to
let
the
ultimate
goal
is
to
leverage
the
uxers
facilitation
critical
thinking
superpowers
so
that
they
can
focus
on
more
impactful
problems.
But
we
need
to
create
space
for
that
and
when
we
do
that,
and
we
have
the
ability
to
set
these
frameworks
in
place,
that
will
provide
immense
leverage
for
uxers
to
focus
on
the
right
problems.
Because
engineers,
other
teams
and
the
wider
community
would
be,
will
be
much
more
autonomous
to
build
the
right
thing
and
also
build
it
right.