►
From YouTube: UX Showcase: Merge Request Pipelines
Description
Rayana shares UX work on Merge Request Pipelines in GitLab Release
A
All
right,
cool
hi,
everyone,
I'm
Hana
product
designer
on
the
release
team
and
today
I'm,
going
to
share
with
you
some
usability
test
test
findings
from
our
detach
pipeline
or
merge,
request
pipeline
specification
and
also
what
we
learn
from
what
users
think
and
also
how
they
use
the
product
and
some
clarifications
that
we
got
from
them
during
this
process,
so
yeah
quickly,
intro
I
think,
like
last
week,
I
also
presenting
some
deliverables
for
the
progressive
delivery
group.
A
So
we
both
share
responsibility
on
progressive
delivery
and
release
management
on
progress
early
for
your
top
priorities,
I,
really
on
speeding
automation
and
our
vision
is
to
help
teams
accelerate
the
delivery
so
yeah.
So
this
feature
specifically
falls
under
continuous
delivery,
which
currently
is
complete
and
our
next
maturity
level
is
so
that's
super
cool.
So
before
I
start
some
background
story
right
everything
starts
with
the
merge
request
and
with
this
feature
it
wasn't
so
different.
A
In
11.9,
eleven,
eight
eleven
nine
we
introduced
merge,
request
pipelines
and
introduced
this
new
concept
of
a
detached
pipeline,
different
from
attachment
lines
that
run
on
the
merge
ref
these
ones
it's
quite
complex.
This
is
the
current
definition
they
occur
when
there
are
no
merge
requests
and
or
where
a
might
request
is
working
progress
and
if
there
is
no
configuration,
linear
seed
lab
see
idml
file.
So
when
this
configuration
is
done,
the
users
will
see,
in
their
pipelines,
view
a
detached
label
and
also
in
the
jobs
view
to
indicate
that
this
pipeline
is
different
right.
A
A
So
I
could
not
find
all
the
comments,
but
it's
like
people
were
really
confused
about
what
the
attached
pipelines
were,
how
to
use
them,
and
they
were
really
thinking
that,
mostly
that
the
detached
pipelines
that
we
had
in
internet
land,
where
the
same
as
get
detached
heads,
which
is
something
completely
different
and
that
was
causing
a
lot
a
lot
of
frustration
internally
and
but
my
favorite
comment,
of
course,
is
this
one
that
everyone
is
confused
about.
No
one
really
understood
this
feature
so
blowing
in
fruits.
Quick
means
we
thought.
Okay,
let's
improve.
A
There
is
something
around
this
label.
Let's
add
a
tool
tip
write,
something
formative
to
say:
okay,
these
pipeline
is
detached
because,
but
this
was
really
a
small
like
quick,
queen
alone,
intro
solution
to
drive
awareness
to
the
label,
but
it
doesn't
really.
It
didn't
really
tell
us
why
people
were
not
understanding
this
problem.
It
didn't
fix
it.
A
It
was
just
no
at
otech
and
then
we
started
the
investigation
to
see
out
of
you
know
with
these
things
in
context
and
out
of
context
with
that,
with
the
merge
request,
what
why
are
people
so
confused
about
it,
and
especially
once
we
release
more
strains
and
we
have
pipelines
from
merging
classified
files
with
merge
results.
There
was
a
lot
more
confusion.
I'm
not
gonna,
go
into
details,
but
pretty
much
people
had
no
idea.
A
So
to
start
any
understanding,
I
quickly
ran
usability
questionnaire
internally,
I
mean
not
15
replies,
I,
think
in
in
day
or
less
and
yes,
our
assumptions
were
right.
People
were
really
confused
about
it.
Only
one
or
15
participants
have
used
attach
pipeline
before
those
are
all
get
like
internal
consumers
of
it
levers
or
they
have
never
seen
it
or
they
did
know
what
to
do
with
it.
A
And
when
we
ask
what
do
they
understand
about
it,
they
have
very
different
different
answers,
so
some
of
them
say
that
it
runs
in
a
different
project
that
users
cannot
really
pipeline.
Or
you
know
it's
a
detached
head
and
that's
really
bad
for
your
project.
So
then
we
jump
to
there's
ability
testing
so
with
an
amazing
help
from
Laurie
would
put
together.
A
Discussion
guide
and
work
walked
over
the
business
decisions,
so
we
wanted
to
make
the
best
approach
to
inform
users
when
to
use
pipeline
for
merge
requests
or
detach
pipelines.
In
this
case,
and
our
most
words,
you
understand
why
the
users
think
this
label
is
confusing,
learn
what
they
don't
understand
about
it,
not
only
about
the
label
per
se.
But
what
can
we
prove
in
our
documentation
and
learn
how
they
expect
to
be
informed
about
this
type
of
pipelines?
And
you
can
check
later
the
issues
and
the
research
epic?
That
has
everything
documented.
A
So,
for
this
second
step,
we
interviewed
six
participants
from
all
around
the
world.
They
were
all
big
like
users,
two
of
them
were
again
internal
customers
or
certificate
blabbers,
and
they
all
have
some
experience
with
pipelines.
They
if
they
haven't
really
us
my
clients
in
their
daily
jobs.
They
were
not
familiar
with
the
topic
and
then
we
started
by
showing
them.
Are
you
wide
of
the
label
and
ask
ok
this
thing
out
of
context?
What
do
you
understand
of
it
and
then
showing
in
on
the
pipeline's?
A
The
merge
request,
the
pipeline's
page,
and
the
second
step
was
to
ask
them
to
find
information
as
set
up
by
transformers
requesting
a
test
project,
so
that
was
quite
fun.
Only
one
user
finish
the
configuration
successfully,
all
the
other
users
were
super
lost,
with
the
naming
and
with
where
to
find
information
and
where
the
configuration
should
be
in
the
project.
A
So
some
of
our
findings,
the
main
one,
was
around,
of
course,
what
they
know
about
this
functionality
and
what
we
learned
was
that
users
really
struggle
to
understand
this
feature,
and
not
only
that,
but
they
were
not
familiar
when
it
comes
out
right.
It's
really
the
naming
not
only
on
the
page,
but
how
we
call
it
on
the
documentation,
how
I
call
it
internally
and
three
participants
have
the
impression
that
the
attached
label
was
related
to
the
gets
attached
headsets
and
all
of
them
were
really
unsure.
A
It
was
not
clear
for
them
why
this
word
was
children.
Why
did
we
go
with
the
attach?
Because
this
term
is
super
confusing?
Or
you
know
it
doesn't
give
enough
context
and
from
me
away
from
whoever
even
confused
and
thought
that
this
had
some
connection
with
the
grounders?
It
was
really
really
interesting
to
see
them,
trying
to
figure
out
what
this
maple
meant.
And
another
thing
was
that
super
interesting
is
that
they
interpret
line
views.
A
They
really
try
to
read
each
UI
element
to
kind
of
guess
what
the
detach
type
alignment
so
another
findings
that
we
can
improve.
The
clues
that
we
add
to
the
interface
to
make
easier
for
users
to
find
the
correct
information
so
that
they
don't
have
to
go
to
Google
and
then
search
for
this
feature
to
then
come
back.
Does
it
generate
a
lot
of
frustration?
So
d-pad
heads?
It's
not
the
same
as
the
attached
pipelines
on
Midland.
So
that's
the
second
thing
and
the
another
big
finding
was
around
configuring
pipeline
200
requests.
A
So
the
way
we
do
now
is
that
if
you
don't
settings
and
you
configure
pipelines
for
merge
results,
you
still
need
to
go
to
epilepsy.
I,
add
some
configurations,
so
some
participants
expected
to
do
all
the
configuration
in
one
place
so
on
settings
or
about
from
this
configuration
that
you'd,
like
CI
files,
I'll
having
to
go
to
the
file
and
manually,
add
a
line
and
and
the
fact
that
in
mail
merge,
requests
pipelines
enable
merge,
training
was
confusing
to
them.
A
So
the
most
critical
part
was
really
that
you
need
to
go
to
two
places
to
see.
If
your
configuration
is
correct
and
yes
it'll
be
super
awesome,
Murphy
heat
lab
CI
file
could
validate
when
one
configuration
in
the
setting
is
selected.
If
the
applied
CI
file
has
has
the
correct,
correct
data
and
some
small
findings,
but
still
super
relevant,
when
we
asked
how
they
distinguish
pipelines,
they
run
a
merchant
class
versus
on
merge
results.
They
were
confused
and
didn't
really
know
the
difference,
and
there
were
significant
improvements
that
we
can
do
in
our
documentation.
A
Right
now,
there
are
at
least
three
different
pages.
So
if
you
go
Google,
there's
three
different
results
for
very
similar
topics,
so
we
nice,
if
we
could
put
bring
some
of
this
content
together
or
at
least
make
the
right
references
on
the
docks
and
also
sorting
in
the
pipeline
pages.
People
say
that
all
you
cannot
search
for
anything.
So
how
can
I
even
just
select
my
details
for
a
regular
pipelines
in
my
field,
but
of
course
we
had
positive
feedback.
A
Our
participants
say
that
they
really
rely
on
the
game
plan
document
ation
to
understand
the
functionalities
and
that
our
thoughts
are
awesome,
that
the
team
is
really
open
to
make
improvements
and
that
in
general
the
docks
are
reliable,
that
the
keep
lab
CI
linking
it's
also
super
helpful
and
in
general,
that
need
like
I,
said
it's
awesome.
That
was
a
great
feedback
they
gave
us
next.
Steps
is
to
suggest
improvements,
of
course,
for
the
naming
of
this
label
or
this
type
of
white
wine.
A
I'm
revisit
for
ducks,
as
I
mentioned,
make
sure
that
the
documentation
is
consistent
and
that
things
are
clear
for
both
pipelines
for
merchants
Alzheimer's
requests
and
set
the
expectation
both
on
the
UI
and
the
docs
to
when
a
detached
pipeline
happens
and
allow
users
to
access
information
in
UI,
rather
to
leave
gitlab
to
find
the
right
information
and
improve
or
simplify
the
process
of
configure
this
this
feature.
Now
we
do
it
in
two
places.
A
So
can
we
standardize
these
and
bring
to
one
single
location
and
that's
related
to
the
previous
point,
make
possible
to
validate
the
club
CI
file
once
you
have
something
configuring
the
settings,
because
right
now,
what
happens?
Is
that
it's
in
your
merge
request
when
you
have
each
lab
CI?
Sorry,
when
you
have
a
only
merge
request,
which
is
the
liability
to
add
to
the
file
to
make
use
of
this
this
functionality,
you
don't
really
know
where
you
have
to
go
and
configure
you
just
say
there
is
an
error.
A
So
that's
a
lot
of
small
things
that
we
need
to
connect
to
improve
this
functionality
and
that's
pretty
much
it
so
again.
I'd
like
to
thank
Lori.
She
was
super
awesome
with
all
the
mentoring
help
throughout
this
process.
And/Or
it
Nathan
our
engineering,
team
and
Ian-
also
he's
not
here
today,
but
he
really
helped
me
got
a
review
this
document
and
also
mindful
everyone
that
helped
me
in
this
process.
Yeah.
Thank
you.
It
was
great.