►
Description
Related GitLab issue: https://gitlab.com/gitlab-org/gitlab/-/issues/254822
A
One
thing
that
I
see
a
lot
of
times
in
our
ux
showcases
is
like
this
complete
story.
I
just
wanted
to
jump
in
and
show
something
that's
not
complete
yet,
and
we're
still
iterating
through
an
idea
towards
a
solution,
something
that
I've
been
trying
to
adjust
to.
As
I
work
more
with
my
product
manager
is
how
issues
end
up
in
workflow
design.
A
So
a
few
months
ago,
matt,
my
product
manager
opened
up
an
issue
with
the
intent
of
adding
a
widget
to
a
dashboard,
a
very
solution,
heavy
driven
idea
and
all
gray
ideas
usually
come
from
some
sort
of
solution,
which
is
totally
fine.
But
one
thing
I've
been
trying
to
encourage
myself
to
do
more,
is
get
into
the
problem.
Validation
step
help
refine
the
problems
that
we
have
a
better
defined
outcome
for
what
we
want
to
achieve
through
design
and
solution
validation.
A
A
It
was
essentially
saying
like
hey:
let's
just
do
this
thing:
to
increase
our
monthly
active
users
by
adding
a
widget
to
the
dashboard
at
face
value
like
yeah,
pretty
pretty
easy
I'll,
just
design
this
like
screen
with
a
couple
statistics
and
then
we'll
be
good
to
go
right,
and
that
was
kind
enough
to
add
a
few
mockups
which
I
love.
When
product
managers
share
their
ideas
visually,
it
helps
communicate
what
they're
thinking
and
so
his
like
initial
idea
was
like
hey.
A
Let's
just
add
this
thing
to
the
dashboard
which,
if
you
compare
that
to
what
the
admin
area
looks
like
now,
it
probably
would
appear
probably
something
more
towards
the
bottom,
so
that
led
me
to
thinking
okay
well,
why?
Why
are
we
trying
to
do
this
thing,
and
I
could
see
that
the
intent
was
to
drive
this
increase
around
our
gmau,
the
grouply,
the
group
monthly,
active
users,
which
is
great
a
great
good
goal
for
us
to
go
after,
but
I
didn't
really
understand
how
this
was
solving
for
that
problem.
A
So,
as
I
was
talking
through
it
with
matt,
I'm
just
trying
to
ask
more
about
like.
Why
are
we
doing
this?
What's
the
value
in
it
and
trying
to
understand
where
he's
coming
from,
because
he
might
be
hearing
things
from
our
customers
or
from
different
individuals
that
match
our
persona,
primarily
cameron,
the
compliance
manager
that
I
don't
actually
have
the
context
of.
A
So
what
he
was
leading
me
down.
The
path
of
understanding
is
that
we
have
this
credential
inventory
section
or
admin
dashboard
and
we're
not
seeing
a
lot
of
attraction
in
terms
of
users
just
driving
to
it.
As
like
a
main
component
for
their
workflow,
and
so
as
I
was
asking
these
questions,
I
was
trying
to
hint
about
like
yeah.
A
A
You
know,
information
to
the
credentials
inventory
itself
and
provide
those
counters
there
or
even
introduce
this
widget
in
the
compliance
dashboard.
We
don't
exactly
know
what
solution
is
the
best
one
just
yet,
so
what
we
were
trying
to
do
was
to
go
back
and
focus
on
what
is
the
problem?
We're
truly
trying
to
solve
at
this
point
so
that
we
can
go
and
find
some
way
to
validate
that
to
better
inform
our
design
decisions?
A
A
I
primarily
brought
in
things
like
the
jobs
to
be
done
statements.
I
tried
to
refine
the
proposal
in
a
way
that
focused
more
on
the
outcome,
and
so
then
what
we're
left
with
are
a
couple
things:
we've
outlined,
how
we're
going
to
try
and
solve
a
problem
for
both
the
customer,
but
also
solve
like
for
a
business
outcome
for
gitlab.
So
we
want
to
see
that
increase
in
monthly
users,
but
we
also
want
to
help
make
cameron's
job
easier
so
that
there's
incentives
to
actually
use
whatever
change
we're
implementing
to
the
product.
A
It's
it's
kind
of
obvious
that
there's
a
lot
of
additions
to
gitlab,
which
creates
a
lot
of
noise,
and
I
don't
want
to
just
continue
adding
to
gitlab
frivolously.
I
want
to
try
and
make
it
more
intentional.
So
now
we
have
a
much
more
refined
problem.
We
have
mapped
it
to
some
job
that
we
think
matches
cameras
expectations,
and
then
we
have
a
few
ideas
for
solutions
that
we
could
use
to
help
better
inform
how
these
might
solve
the
problem
that
we're
trying
to
solve.
A
So
we
took
some
of
those
screenshots
from
the
ideas
that
we
had
and
we
can
take
those
into
design
and
diverge
a
bit
on
solutions
to
figure
out
what
makes
the
most
sense
and
then,
to
kind
of
summarize
that,
all
together,
it
gives
us
the
opportunity
to
also
better
define
the
outcomes
we'd
like
to
see
so
in
terms
of
measurements.
How
do
we
know
we're
successful?
A
B
I
have
a
comment.
Actually
I
have
a
few
comments.
So
let
me
start
by
saying:
hey.
I
love
that
you
just
talked
to
your
issue.
That's
great
heck!
Yes,
you
got
me
really
excited
what
a
fabulous
example
of
taking
things
back
to
the
problem
which,
to
your
point,
it's
it's
so
instinctive
when
you
see
a
solution
just
to
go.
Oh
okay,
I've
got
a
request
for
a
solution,
and
here
we
go
and
we're
just
gonna
go.
You
didn't
do
that.
B
You
really
thought
this
through,
and
I
love
that
you're
thinking
about
the
complexity
of
our
product,
because
that
is
one
of
the
biggest
customer
pain
points
that
we
hear
about.
We
should
all
be
thinking
about.
How
can
we
support
users
needs
without
adding
cruft
and
clutter.
So
my
comments
are
just
a
big.
B
A
C
And
it's
backing
up
what
krista
was
saying.
I
totally
agree
and
I
think
it's
a
great
reminder
on
how
important
it
is
for
us,
as
ux
people,
to
be
constantly
aware
of
the.
Why
and
ensuring
that
we're
we're
asking
that
we're
making
sure
that
we're
solving
the
problem.
I
I'm
curious.
What
was
your
pm's
reaction
to
your
you
know,
follow-ups
and
your
whys.
A
Yeah
and
I
think
matt's
openness
to
conversation
is
reinforced
and
I
really
have
appreciated
his
willingness
to
continue
refining
things
and
not
even
just
take
what
I
say
at
face
value,
because
I
think
that
leads
to
some
of
the
best
ideas
he's
very
great
about
reinforcing
that.
He
like
really
appreciates
my
thought
partnership
and
he
continues
to
help
push
things.
So
even
after
I
made
a
revision,
you
know
matt
made
another
revision,
and
so
we
just
continued
building
on
each
other's
ideas.
So
it
was.
C
D
Yeah,
I'm
just
this
is
great
by
the
way.
So
do
you
have
any
suggestions
for
a
designer
wanting
to
try
this
out
for
the
first
time
with
air
pm?
Like
did
you
have
initial
conversations
with
your
pm
before
you
tried
this,
or
did
you
just
go
straight
into
the
tool
and
and
give
it
a
try
and
then
second,
my
second
question
is
kind
of
an
add-on
to
that
of.
Is
there
anything
that
designers
should
watch
out
for
anything
that
you
ran
into
that
they
might
run
into
that?
A
Yeah,
okay,
so
two-parter.
How
did
I
know
like?
I
was
ready
to
have
this
conversation,
I
guess
or
trying
to
approach
it
in
this
way
and
then
the
second
part
being
like
anything
to
look
out
for
so
with
the
first
one.
I've
always
tried
to
keep
a
pretty
open
perspective
in
terms
of
how
I
approach
my
conversations
with
product
management.
That's
both
before
I
came
to
git
lab
and
since
I've
come
here
and
it
starts
by,
I
went
through
the
the
dib
training
recently.
A
A
I
was
trying
to
ask
more
thoughtful
questions
and
our
threat
of
like
what
are
we
trying
to
achieve
here
through
these
specific
metrics,
and
I
could
better
understand
what
he
was
going
for,
so
that
when
I
brought
forth
a
way
to
revise
the
proposal,
it
didn't
just
feel
like
I
was
trying
to
dominate
the
conversation.
Instead,
I
was
looking
for
input
on
how
to
improve
to
reach
a
better
outcome.
A
Now
with
that
said,
I
think
it's
worthwhile
to
understand
like
what
is
your
relationship
with
your
product
manager
and
how
do
they
like
to
receive
feedback
matt's,
pretty
shameless
and
saying
like
he
has
short
toes,
is
the
way
he
keeps
describing
it.
He
loves
to
have
this
type
of
dialogue
all
the
way
across
our
validation
and
build
track.
A
So
I
felt
pretty
comfortable
approaching
an
issue
that
I
saw
come
up
as
a
priority
in
one
of
our
previous
milestones,
but
if
you're
trying
to
figure
out
what
works
well
for
you,
you
know,
I
think,
just
continuing
to
have
frequent
conversations
with
product
managers
and
understanding
how
their
dynamics
are
and
how
they
like
to
receive.
Feedback
is
worth
considering
when
you're
trying
to
provide
feedback.
Asynchronously.