►
Description
Daniel Fosco, Sr. Product Designer on Research Group presents results for solution validation on the "Manual Allow Deny Action on Pipeline Jobs" issue
Main Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/35412
Research Issue: https://gitlab.com/gitlab-org/ux-research/-/issues/1411#solution-validation-summary (internal)
Dovetail Project: https://dovetailapp.com/projects/ed93c357-fc8b-44ba-b1c3-0304ba2aa65b/insights (internal)
A
A
We
built
a
prototype
for
this
issue
and
we
asked
users
to
conduct
two
tasks
on
this
prototype.
The
first
one
was
to
find
the
entry
point
where
they
could
deny
a
deploy
that
was
requested
by
a
developer
on
their
team,
and
the
second
was
to
actually
deny
the
deploy
on
the
pipeline
graph.
So
we
would
give
users
some
context
on
the
situation
they
were
supposed
to
deny
a
deploy,
because
their
production
environment
is
growing
through
some
instability.
A
The
first
screen
they
will
land
would
be
the
merge
request
page.
This
is
just
a
prototype,
and
this
is
the
entry
point
right,
the
pipeline
widget,
and
so
they
were
supposed
to
either
click
here
or
here
to
go
to
the
pipeline
graph,
where,
if
they
scroll
all
the
way
to
the
side
on
this
prototype,
they
can
see
a
deploy
job
that
is
marked
in
orange
and
has
this
little
thumbs
up,
they
can
click.
This,
give
a
comment
or
not
and
then
deploy
the
drop.
A
There
were
a
couple
of
questions
around
it,
but
essentially
we
wanted
to
understand
if
they
could
find
the
entry
point
from
this
feature
from
the
merge
request
page
and
once
they
got
here
if
they
could
easily
find
the
place
where
they
can
deny
or
approve
the
deploy
job.
In
this
case,
the
scenario
was
to
deny
so
going
very
quickly
over
the
insights
we
found.
This
is
an
aggregate
of
the
trends
and
and
comments
from
most
of
the
users.
So
these
this
represent
an
average
of
what
our
user
said.
A
Most
of
them
actually
didn't
mention
the
merge
request,
but
they
said
they
would
expect
to
find
this
request
for
approval
in
some
sort
of
notification
area,
so
either
their
gitlab
to
do's.
Someone
mentioned
their
inbox,
so
some
sort
of
area
that
connect
that
get
aggregates
all
of
these
requests
for
for
deploy
after
they
responded
to
this,
they
were
given
the
link
to
the
prototype
that
sent
to
the
merge
request
page
and
for
most
of
the
users.
Finding
the
entry
point
on
the
merge
request
was
really
difficult.
A
They
would
scroll
up
and
down
look
for
several
minutes.
Some
of
them
were
not
able
to
find
it
most
were,
but
some
were
not
so
for.
For
me,
it
shows
that
the
merge
request
page
is
already
very
information
heavy.
So
even
though
the
pipeline
widget
should
reflect
the
state
of
the
deploy,
because
it
is
a
part
of
the
pipeline,
it's
not
necessarily
the
best
entry
point
for
deploy
approvals
approvals.
A
That
is
also
compounded
by
the
fact
that,
even
though
the
term
we
used
in
the
ui
is
always
allow
or
deny
the
deploy,
rather
than
approve
or
reject
lots
of
users
confuse
the
merge
request
approval
with
the
action
to
approve
the
deploy
right.
So
if
we
go
back
to
the
prototype
really
quickly,
you
can
see
the
merge
requests
already
merged,
so
some
of
them
were
confused
by
this.
It's
already
already
merged.
A
So
what
am
I
supposed
to
approve
a
little
bit
of
confusion
around
that
happened,
but
the
good
news
is
that,
once
once
users
got
through
the
entry
point,
most
of
them
found
the
deploy
job
very
easily.
They
would
just
scroll
all
the
way
to
the
end
like
yeah.
Here
it
is,
they
would
click.
It
comment
deny
it.
It
was
super
quick.
You
could
barely
catch
it
on
video,
so
this
part
of
the
interaction
worked
really
well
with
the
users
that
we
tested
with.
A
They
also
understood
how
users
will
be
notified
of
this.
We
have
this
little
notice
here
saying
participants
will
be
notified.
Also
here
it's
a
bit
small,
but
it
says
participants
in
the
merge
request
linked
above
will
be
notified,
so
that
was
clear
enough
for
them.
Also,
the
outcomes
from
allowing
or
denying
and
deploy
were
clear
right.
A
One
of
the
final
questions
was:
what
state
would
you
expect
this
job
to
go
through
if
you
denied
it
or
if
you
allowed
it,
and
most
users
understood
pretty
well
that
if
well,
if
I
allow
the
deploy
to
go
through,
it
will
be
deployed,
it
will
run,
it
will
go
forward.
If
I
deny
it,
it
will
be
cancelled
or
it
will
be
instant
buy.
So
essentially
the
logic
behind
the
approval
or
the
deny
was
very
clear
for
our
users.