►
Description
Within this timezone group, various domain counterparts (Engineering Managers, Product Designers, Product Managers, Technical Writer, and/or UX Researcher) contribute to a User Journey Map (UJM) that spans the whole Create stage.
More information:
- Epic: https://gitlab.com/groups/gitlab-org/-/epics/6964
- Issue: https://gitlab.com/gitlab-org/create-stage/-/issues/12945
A
A
No
one
has
filled
it
out.
Yet
let
me
know
if
you
don't
have
access.
You
can
interrupt
me,
but
I
think
everyone
should-
and
you
also
have
this
issue
that
you're
assigned
to
and
today
we're
going
through
this
synchronous
session.
So
what
we're
going
to
do
is
look
primarily
at
this
top
part.
That
is
the
steps
brainstorm
and
looking
at
the
different
stages
that
we
have
here
so
at
the
top.
A
So
it's
just
a
reminder
of
okay,
when
this
persona
is
going
through
this
job
at
this
stage
of
confirming,
is
there
anything
that
they
usually
need
to
do?
What
is
this?
This
are.
What
are
the
steps
here,
and
maybe
they
need
to
do
something?
Maybe
they
don't
you?
We
don't
have
to
fill
all
of
these
stickies,
but
it's
just
a
checklist,
a
reminder
to
reflect
on
them
and
in
terms
of
what
I
mean
by
solution
agnostic.
I
give
you
an
example
here
in
the
map
which
has
these
stickies
here
next
to
each
title.
A
So,
for
example,
this
one
says
determine
what
songs
to
listen
in
the
moment
right.
So
if
it
was
a
if
we
were
looking
at
a
a
job
or
a
problem
to
solve
that
is
around
listening
to
music,
this
could
be
one
of
the
steps
and
it's
solution
agnostic.
It
could
be
any
solution
to
listening
to
music,
but
then
in
the
actions
we
have,
for
example,
view
explore
tab
right.
That
is
very
specific.
A
That's
a
action
as
a
very
specific
step
of
something
that
the
user
is
doing
and
it
can
be
inside
of
the
product
or
it
can
be
outside
of
it
right.
It
can
be
other
touch
points,
other
tools
talking
to
someone
whatever
it
is,
and
but
this
this
comes
later.
It
was
just
to
give
an
example
of
the
difference
between
a
step
and
an
action.
A
So
the
persona
is
sasha
our
software
developer
and
they
spend
the
majority
of
their
time
focused
on
completing
plan
development
tasks
with
roughly
30
to
40
percent
of
time,
taken
by
meetings
planning
for
the
next
print
and
fixing
bugs
or
customer
requests
as
they
arise.
They
work
off
of
jira
tickets
and
have
a
regular
stand
up
with
my
team,
interesting
that
they
mentioned
working
off
dual
tickets
and
the
job
to
be
done
is
quite
broad,
so
the
situation
when
product
improvements
are
identified.
A
I
want
to
propose
changes
that
address
them.
That
is
the
job,
and
the
outcome
is
so
that
I
can
help
build
a
better
product
right
and
in
the
first
session
that
I
did
two
days
ago,
it
wasn't
clear
what
was
the
end
right.
So
when
did
we
get
to
this
stage
of
concluding
ending
the
job
for
sasha?
Is
it
just
proposing
the
changes
or
shepherding
these
those
changes
that
they
have
proposed
until
they
are
merged
right,
and
I
think
I'll?
A
If
they
run
out,
I
don't
think
they
will,
but
if
they
run
out,
you
can
select
one
of
them
and
copy
paste
or
press
command
d,
and
it
will
duplicate
asiki
right
next
to
it
and
if
possible,
try
to
write
using
this
structure
so
verb
object:
an
optional,
contextual
clarifier.
In
this
example,
we
see
that
the
verb
is
determined.
The
object
is
what
songs
to
listen
and
then
the
optional
contextual
clarifier
is
to
listen
in
the
moment.
Yeah.
A
I'm
sorry
so
try
to
write
it
that
way
and
try
to
be
as
succinct
as
possible,
but
it's
it's!
Okay!
If
you
write
it
in
a
different
way,
we
will
look
into
that
separately
and
the
interesting
part
is
that
we're
going
to
do
this
initially
by
not
seeing
what
others
are.
Writing
so
mural
has
this
pride
of
the
private
mode
that
I
will
activate
and
during
the
10
minutes
that
we
will
all
try
to
fill
out
as
much
as
we
can
of
these
stages
and
steps.
A
B
A
A
Overwriting
someone
else's
content,
but
but
yeah
so
focus
on
quantity,
not
quality,
so
try
to
write
as
much
as
you
can.
Even
if
it's
you
know
not
very
reasonable,
it
doesn't
matter
write
everything,
and
it's
just
has
to
be
based
on
your
assumptions.
What
you
think
hypothesis,
it
doesn't
have
to
be
validated
or
right,
or
it
doesn't
have
to
be
something
that
you
have
witnessed
for
sure,
so
so
yeah,
let's
get
this
started,
have
fun
just
contribute
as
much
as
possible.
A
Again
it
doesn't
have
to
be
right
and
the
part
about
getting
this
right
is
my
job.
It's
not
your
job.
Your
job
right
now
is
just
to
output
things
like
a
survey
right
like
if
you're
filling
out
someone
something
to
get
your
opinion.
Okay,
so
I'll,
activate
private
mode
and
I'll
start.
The
timer
for
10
minutes
with
the
airplane
sounds.
So
let's
do
this
good
luck.
A
A
B
A
They
go
wow
good
job,
good
job,
that's
that's!
I
mean
there
are
a
lot
of
empty
stickies,
but
don't
worry
about
those
I
created
those.
You
know
just
that.
It
was
easy
for
everyone
to
just
add
things,
but
there
are
a
lot
of
steps
here
and
it's.
What
is
you
know.
Amazing
here,
is
that
the
steps
are
solution.
Agnostic
things
that
the
user
is
trying
to
accomplish
is
not
necessarily
the
detailed
actions
of
you
know.
Click
button
open
drop
down,
write
this
right
that
so
this
is.
This
is
really
good.
A
So
what
I'm
going
to
do
is
just
give
everyone
five
minutes
now
to
review
all
of
the
stickies
that
you
see
here,
because
you
were
not
seeing
your
colleague
stikis.
I
will
give
five
minutes
for
everyone
to
just
take
a
quick
look
at
everything
see
if
your
colleague
stikis
inspire
you
somehow
to
write
other
things
that
you
that
you
remember
so
five
minutes.
I
hope
that's
that's
enough,
and
now
the
timer
will
have
a
cuckoo
sound.
A
Eric,
okay,
great
so
I'll,
stop
the
timer.
That
was
enough,
then
good.
I
hope
it
was
good
to
see
your
colleagues
stickers
and
and
what
they
wrote
so
right
now
and
don't
worry
so
far.
I've
been
the
only
one
talking
it's
been
kind
of
a
silent
activity,
but
that's
okay.
You've
contributed
a
lot
and
right
now
we're
going
to
have
another
silent
step.
A
But
after
that
we
will
open
the
discussion
and
it
will
be
more
a
free
form
about
what
we
what
we
have
here-
okay,
so
so
right
now,
let
me
share
my
screen.
What
we're
all
going
to
do
collaboratively
is
now
that
we're
seeing
all
of
the
stickies
and
all
these
different
ideas
is
to
cluster
them.
So
look
for
patterns
and
similar
steps
that
could
be
duplicated
or
that
are
very
tightly
related
and
could
be
consolidated
somehow,
and
so
we
can
do
this
all
together.
A
I
will
help
as
well,
and
you
can
just
drag
some
of
the
stickies
to
this
blank
area
below
and
start
grouping
them.
As
you
see
fit
and
just
you
know,
place
them
together,
close
to
one
another,
try
to
pick
areas
or
stickies
that
your
colleagues
are
not
picking
as
well.
So
you
know,
go
left,
go
right
and
by
the
end
of
five
minutes
we
should
all
have
the
stickies
organized
any
questions.
A
A
Good
question
mike:
no,
you
don't
need
to
stay
within
the
the
those
lanes
you
can,
you
know,
drag
them
left
right,
because
that's
completely
right,
you
know
some
people
might
have
written
something
very
similar
in
a
stage
next
to
it.
It
and
it
doesn't
at
the
end
of
the
day,
to
be
honest,
doesn't
really
matter
if
it's
the
correct
stage
it
just
matters
that
there's
a
some
kind
of
you
know
order
to
it
left
to
right
in
terms
of
timing
but
yeah.
A
A
What
we
don't
agree
on
and
what
we
thought
was
interesting,
or
even
things
that
maybe
feel
a
little
bit
like
outside
of
this
or
that
is
it
sasha
who
who's
responsible
for
this
step,
or
is
it
someone
else?
So,
let's
first
look
here
at
the
before
column
and
we
have
read
existing
backlog
and
access
to
the
work
backlog.
B
B
Right
for
me,
it's
kind
of
hard
to
know
like
are
we
only
thinking
about
things
that
sasha
is
doing
or
because
that's
from
the
point
of
identifying
a
problem
to
concluding
sasha's,
not
the
only
one
involved,
so
I
was
just
kind
of
as
I
was
going
through
this.
I
was
trying
to
find
that
balance
of
what
what's
sasha's
responsibility
and
what's
if
we
don't
include
any
of
sasha
or
anything,
that's
not
sasha's.
B
A
Yeah,
I
think
so
yeah.
I
think
we
should
write
things
and
then
have
these
steps
from
sasha's
perspective.
So
if
it's
something
that
she
is
waiting
on
and,
for
example,
I'm
waiting
for
reviewers
feedback
right,
that's
that's
a
step
in
itself
right,
I
could
be
doing
other
things,
but
for
this
particular
particular
improvement,
there's
a
step
where
I'm
waiting
or
there's
a
step
where
I'm
engaging
with
them.
A
Whereas
there's
a
step
where
I'm
waiting
for
my
pm
to
prioritize
this
right
or
or
my
engineering
manager
or
waiting
for
the
maintainer
to
to
merge
it
or
even
you
know,
waiting
for
user
feedback
whatever
it
is.
So
there's
also
those
waiting
phases
and
steps
and
collaborative
steps
where
I'm
working
with
someone
else.
A
Okay,
so
then
in
define
stage
determine
objective
and
plan
approach
to
complete
job.
We
have
create
a
proposal
for
the
work
which
I
think
it's
like
you
know,
a
plan
how
we
were
going
to
approach
it.
This
is
understanding
and
clarifying
to
make
sure
we
understand
the
requirements
and
what
we're
going
to
do.
A
C
C
I
was
thinking
through
this
like
sometimes
in
order
to
concretely
define
a
problem.
You
have
to
spend
time
like
doing
engineering
to
like
know
what
the
actual
problem
is,
and
so
I
sort
of
put
it
there.
I
it
could
go
probably
in
a
variety
of
places,
but
that
was
sort
of
my
thought
sometimes
like
yeah.
I
I
don't
know
if
we're
gonna
say
we're
gonna
create
a
proposal
like
you
sort
of.
Sometimes
you
need
that
that
spike
to
like
create
those
proposals.
A
Right
right,
I
think
so
I
would
say
that
you
know
this
one
clarifies
scope
of
problem
or
under
understand
problem
to
be
solved.
These
are
probably
too
broad
right
because
you
can.
There
are
many
things
that
you
can
do
to
understand.
There
are
many
things
you
can
do
to
clarify
it,
but
then
you
have
two
specific
or
three
specific
things
to
discuss
the
problem
with
your
team,
which
is
similar
to
collaborating
and
another
thing
you
can
do
is
separately.
A
You
can
work
on
a
spike
right
and
all
of
these
three
things
are
actually
could
be
considered
sub
steps
of
these
two,
which
are
you
know
the
the
outcome
so
yeah
I
mean
you
don't
have
to
to
worry
about
that.
I
can
just
organize
this
later,
but
it's,
I
think,
it's
interesting
for
us
to
think
about
all
the
things
that
one
can
do
for
a
specific
outcome.
A
A
B
A
A
A
Okay
yeah,
then
we
have
this
one.
I
think
it's
it's
kind
of
similar,
interestingly
here
in
the
prepare,
when
you're
creating
the
right
setup,
we
have,
you
know,
create
epics
and
breaking
down
the
work
which,
in
you
could
say,
could
come
before
this
part.
But
again
it
doesn't
it's
not
really
that
important
if
it
comes
right
before
or
after
we
can
work
through
that
later,
setting
up
development,
environment,
cloning,
the
project
and
making
sure
you
have
the
latest
version
creating
a
branch.
A
B
Yeah,
so
you
know
just
thinking
about
from
the
source
code
perspective
right,
that's
a
branching
is
a
as
a
tough
thing
and
sasha's
a
newer
developer
like.
Where
do
I?
How
do
I?
How
do
I
go
about
making
this
change?
Should
I
do
it
off
of
a
feature
branch?
Or
you
know,
branch
off
a
branch
of
a
branch
could
be
a
barrier
to
entry
to
getting
started
on
this
kind
of
thing.
So
knowing
where
to
make
the
change
basically
is.
B
I
yeah,
I
think
it
can
be
both.
You
know,
depending
on
what
triggered
this
change
to
be
right.
What
why
is
this
change
being
proposed?
It
could
be
you
know.
Hot
fix
right
has
to
go
in
a
certain
world
where
feature
stuff
kind
of
operates
over
there.
So
I
think
it
is
very
much
dependent
on
blood
trigger
the
change
that's
being
introduced.
A
A
B
A
B
A
C
B
C
C
B
A
C
A
Okay,
cool
got
it;
okay,
let's
quickly
see
here,
monitor,
should
be
fairly
simple.
You
know,
monitor
it
analyze
the
performance
of
the
code
check
that
changes
were
deployed,
which
can
also
be
the
case.
This
one
might
actually
come
after
right
when
you're
concluding
or
wrapping
up
or
even
after
everything
is
done.
You
know
just
to
make
sure
that
it
was
deployed,
because
in
a
way
that
sasha's
proposal
was
accepted
right,
so
I
don't
know
who
wrote
this
or
who
moved
it
here.
Do
you
agree
mover.
B
I
don't
remember:
if
that's
what
in
these
few
stages,
I
got
a
little
confused
because
there's
a
couple
different
verification
paths
or
monitor
paths,
there's
one
of
like
I
need
to
monitor
the
mr
or
the
change
itself
and
monitor
for
feedback
and
make
changes
until
I
get
my
get,
this
change
actually
deployed,
and
then
there's
also
the
phase
of
I
need
to
monitor
it
after
it's
been
deployed
and
make
sure
things
are
working
and
those
kind
of
got
conflated
with
together.
For
me
somehow.
A
B
B
A
Yeah
yeah,
I
think
everything
else
is
quite
quite
straightforward.
You
know
collaborating
with
reviewers
and
responding
to
your
feedback,
responding
to
failing
tests,
and
I
mean
this
will
likely
include
any
kind
of
test
failure
related
to
code,
quality
security
and
so
on.
So
all
checks,
basically
that
we
have
today
in
in
the
merge
request,
propose
a
change
to
the
production
database
under
concludes
verified
changes.
I
expected.
B
B
A
So
this
is
when
I,
the
changes
that
I'm
proposing
will
affect.
You
know,
for
example,
the
structure
of
the
database
or
I
in
this
case
it's
the
code
base.
Oh
okay,
sorry
I
was
misreading
it.
So
it's
the
code
base.
Okay,
yeah!
I
think
you
know
as
a
whole,
like
this
captures
everything
that
or
the
whole
job.
C
B
A
Exactly
yeah
and
the
interesting
part
is
that
a
lot
of
things
that
we
think
could
fit
as
part
of
this
job
can
actually
be
related
jobs.
You
know
in
in
the
and
those
come
especially
in
the
before
and
after
that.
Maybe
after
sasha
concludes
this
job.
Another
job
starts
right
or
before
it,
you
have
other
jobs.
That
only
happen
once
like
understanding
the
code
base
or
getting
familiar
or
getting
access
to
it
all
right.
So
we
have
these
dependencies
all
right,
so
any
other
thoughts
or
comments
or
questions
about.
A
A
What
I
would
like
for
everyone
to
do
is
to
there's
a
link
here
in
your
groups,
issue
with
a
link
to
the
epic
thread
where
I
would
like
for
you
to
share
your
thoughts
and
learnings
from
this
activity.
What
you
thought
was
interesting
or
not
what
went?
Well,
what
didn't
go
so
well.
There
are
some
inspirational
questions
there
in
the
epic
thread,
but
I
will
ping
you
there
in
any
case,
and
after
this
we
will
have
time
for
async
individual
work,
so
I'm
proposing
between
these
dates.
A
A
You
know
more
or
less
the
final
steps
so
to
speak,
and
those
will
serve
as
guidelines
for
you
to
fill
out
the
actions
here,
which
is
you
know,
just
the
detailed
actions
of
what
they're
actually
doing
in
the
tools,
so
on
what
they're,
feeling
positive
and
negative
thoughts
and
feelings,
pain,
points
and
opportunities.
And
again
this
is
all
based
on
your
assumptions.
A
It
doesn't
have
to
be
right
or
validated
and
for
the
action
specifically,
I
recommend
that
for
the
actions
and
everything
really
but
mostly
for
the
actions,
I
recommend
that
you
actually
try
to
rehearse
this
flow
and
go
through
this
journey
yourself,
using
whatever
tools
sasha
would
use-
and
I
I
I
mean
we
assume
mostly
git
lab
but
also
other
tools
and
go
through
that
flow
yourself
and
try
to
you
know
place
yourself
in
sasha's,
shoes
and
yeah.
It's
all
written
here
as
well.
A
A
A
Okay,
cool,
mostly
mostly
positive
maths,
is,
is
thinking
which
is
also
a
positive
thing.
It's
also
good
to
reflect
and
be
in
that
in
that
mood.
I
hope
that
continues
to
this
mood
continues
to
the
next
activity,
where
you
will
work
async.
I
hope
you
had
had
a
good
time
today.
It
was
you
know,
fun
to
do
this
kind
of
activity
and
not
just
be
commenting
on
gitlab
and
slack,
and
I
hope
to
to
see
you
next
time.