►
Description
Pedro Moreira da Silva, Staff Product Designer from the Create:Code Review team at GitLab, shares how the Create team came together to co-create a User Journey Map based on their hypotheses.
- Slides: https://docs.google.com/presentation/d/1cRsXW2LzzEK0W3oj20DVqMlgAwR-MQQL8TxocQ8lNoY/edit?usp=sharing
- Epic: https://gitlab.com/groups/gitlab-org/-/epics/6964
- User Journey Maps: https://gitlab.com/groups/gitlab-org/-/epics/6964#group-user-journey-map-ujm-murals
- Findings and recommendations: https://gitlab.com/gitlab-org/create-stage/-/issues/12950
- References (GitLab, Literature, Templates): https://gitlab.com/groups/gitlab-org/-/epics/6964#-references
A
A
My
name
is
pedro
morer
de
silva
and
I'm
a
staff
product
designer
in
the
create
code,
review
area
of
gitlab-
and
we
all
know
gitlab
is
the
devops
platform,
and
it
is
a
platform
that,
when
we
join
all
of
the
features
it
compounds
in
value
right.
So
one
of
the
things
we
have
written
in
the
handbook-
and
we
described
is
the
golden
journey
where
we
say
that
our
customers
get
the
most
value
out
of
the
gitlab
product
when
they
use
multiple
features
together
and
in
this
creates
sorry
in
this
golden
journey.
A
The
create
stage
is
the
first
and
most
important
stage,
and
it
is
highlighted
here
in
orange
or
bolded.
The
golden
journey,
where
you
observe,
as
the
most
common
stages
adopted
by
paid
customers
and
serve
as
foundation
to
adopt
other
stages,
so
it
starts
from
create
then
goes
to
verify
and
release,
and
we
hypothesize
that
if
the
golden
journey
is
complete,
all
stages
of
gitlab
are
available
to
use.
A
So
why
don't
we
design
with
that
in
mind
right?
Our
users?
Don't
see
stages
or
groups,
but
we
do,
and
sometimes
we
do
try
to
design
with
that
journey
in
mind.
But
it's
just
hard.
Our
organizational
structure
encourages
silos,
but
the
nature
of
our
products
is
the
complete
opposite
of
that
in
our
product.
It's
just
one
platform
and
our
users
don't
see
silos.
A
So
what
can
we
do
about
that?
Maybe
use
the
user
journey
maps
to
help
blur
the
lines
between
the
stage
groups
and
the
stages
and
solidify
one
platform
might
set
so
on
the
right
hand,
side.
You
can
see
an
example,
or
you
know
the
structure
of
a
typical
customer,
slash
user
journey
map
where
we
have
a
specific
user.
A
They,
you
know,
carry
out
a
specific
scenario
and
have
specific
goals,
and
we
map
out
and
visualize
from
start
to
finish
all
of
the
phases
all
of
the
steps,
actions,
feelings,
pain,
points
and
opportunities
of
this
journey
as
they
complete
that
scenario
and
what
are
the
benefits?
So
first,
we
help-
and
these
are,
I
think,
more
at
least
a
bit
tailored
to
gitlab-
is
that
we
solidify
the
notion
that
we're
designing
a
one
platform
experience,
so
it
helps
instill
the
cross-stage
mindset
in
all
stakeholders
encouraging
them
to
always
look
out
for
cross-stage
moments.
A
And
finally,
with
all
of
this,
it
provides
stakeholders
with
the
insights
they
need
to
influence
the
prioritization
of
cross-stage
moments,
because
usually
what
the
prioritization
happens
happens
in
each
group
or
stage
is
that
it's
just
focused
on
what
they're
trying
to
achieve
not
what
we
are
all
trying
to
achieve.
And
so,
if
we
visualize
all
of
this-
and
we
see
the
cross-stage
moments,
product
managers
and
everyone
else
can
influence
the
prioritization
of
those
moments
and
not
separate
individual
and
sometimes
opposite
directions
of
each
stage
or
group.
A
It
took
them
a
long,
a
long
time
to
to
reach
that,
as
you
might
imagine,
but
so
to
get
to
that
research
based
user
journey
map,
which
is
something
that
is
solid
and
we
can
rely
on
to
you,
know,
make
decisions
for
the
first
iteration.
Let's
take
some
baby
steps
and
focus
on
what
are
our
current
hypothesis?
A
What
is
our
existing
understanding
within
the
stage
groups?
So
it
doesn't
need
to
be
validated
and
we
just
merge
the
multiple
existing
team
views.
We
help
create
a
research
plan
based
on
the
gaps
that
emerge
from
this
hypothesis
map
and
try
to
make
a
first
step
towards
a
higher
fidelity
research
based
map
and
that's
what
we
did
so.
This
is,
on
the
right
hand,
side.
You
see
a
one
of
the
outputs
from
the
the
exercises
that
we
did
and
there
were
basically
four
steps.
Big
steps
to
this.
A
The
first
one
is
that
we
selected
a
shared
persona
and
job
to
be
done
for
the
whole
create
stage,
and
we
said
that
the
persona
and
the
job
to
be
done
need
to
touch
on
all
groups,
code,
review,
editor
and
source
code.
We
did
not
include
giddily
here
and
we
expected
that
the
persona
would
only
use
some
features
from
certain
groups
to
complete
their
job.
We
wouldn't
expect
them
to
use
all
features
and
the
job
to
be
done
doesn't
have
to
be
validated
because
again,
we
are
not
necessarily
relying
on
research.
A
Second,
we
have
13
stable
counterparts,
so
product
designers,
product
managers,
engineering
managers,
ux
researcher
and
technical
writer-
contributes
to
the
user
journey
map
and
we
did
a
mix
of
sync
and
async
work
with
me.
Acting
as
a
facilitator
across
three
time
zone
groups,
it
was
challenging
but
a
lot
of
fun,
and
I
can
say
that
between
the
first
and
the
third
and
last
group
I
was
iterating
my
way
there
and
improvising
and
improving
the
process
within
the
workshop.
A
So
what
are
were
the
results
you
can
check
all
of
them
at
the
link
at
the
top.
That
says,
learn
more
and
I'll
also
put
the
links
down
in
the
description
in
youtube,
two
observations
and
to
understand
these.
Let's
just
first
look
at
one
example
of
one
of
the
map
stats,
one
of
the
group
one
of
the
groups
created.
So
this
is
one
of
the
examples
and
there
are
different
rows
here
within
this
structure,
so
we
have
phases
at
the
top
and
I'll
get
to
them
in
a
bit.
A
You
know
levels
or
swim
lanes
in
the
user
journey
map,
so
steps
which
are
solution,
agnostic
steps
of
what
your
user
is
trying
to
accomplish
actions,
detailed
actions
of
what
they're
doing
feelings,
pain,
points
and
opportunities.
You
know
potential
improvements
or
enhancements
to
the
experience
and
as
columns
we
have
this
one
just
called
before
has
a
phase.
A
But
just
to
give
you
a
quick
sense,
they
are
basically
like
a
checklist
that,
when
you're
filling
out
a
an
experience
map
you
think
of
each
of
these
stages
and
what
is
the
user
going
through?
In
this
case,
we
had
the
first
one
define
which
is
to
determine
the
objective
and
plan
approach
to
complete
job.
We
have
others
locate,
prepare
confirm.
A
We
have
what
we
would
call
the
most
important
or
core
stage,
which
is
the
execution
where
the
user
is
actually
performing
the
job
as
planned,
and
then
we
have
others
like
monitor,
modify
and
the
last
one
concludes.
What
did
they
do
to
end
the
job
wrap
up
and
follow
up,
and
so
these
acted
as
a
checklist,
and
you
can
see
that
some
of
them
have
just
one
sticky
here,
for
example,
and
nothing
below
others
like
the
execute,
have
a
lot
of
them
so
now
back
to
the
results.
A
Then
we
have
the
job
to
be
done
and
understand
if
it
was
at
the
correct
altitude,
because
we
had
a
lot
of
questions.
We
had
a
lot
of
other
least
confidence
questions
in
general.
What
jobs
to
be
done
usually
take
place
in
before
and
after
phases?
What
happens
in
the
pre-execution
stages,
but
the
recommendations
were
we
really
need
to
validate
the
jobs
to
be
done
and
I'll
talk
about
that
in
a
bit
and
after
the
jobs
we
done
are
validated.
A
A
And
the
second
thing
which
may
lead
to
more
discussion
outside
of
this
ux
showcase
is
about
our
jobs
to
be
done.
They
are
usually
scoped
and
we
try
to
find
jobs
to
be
done
for
each
stage
group,
but
in
a
single
job
to
be
done.
We
realized
that
there
are
many
features
that
they
rely
on
across
different
stage
groups.