►
From YouTube: UX Showcase: Lovable merge button
Description
Pedro Moreira da Silva, Staff Product Designer (Create:Code Review), explains his work on the merge widget.
Epic: https://gitlab.com/groups/gitlab-org/-/epics/1381
Map states of MR merge widget/button: https://gitlab.com/gitlab-org/gitlab/-/issues/299193
Competitive analysis of code review merge checks UX: https://gitlab.com/gitlab-org/gitlab/-/issues/300767
Design framework for MR merge button: https://gitlab.com/gitlab-org/gitlab/-/issues/299195
Create better doc format for MR merge widget map: https://gitlab.com/gitlab-org/gitlab/-/issues/300549
Merge Request Widget Research Synthesis and JTBD Outline: https://gitlab.com/gitlab-org/ux-research/-/issues/1099
A
A
But
you
have
this
button
green
button,
merge
that
allows
you
to
accept
a
merge
request
with
all
of
its
changes
and
integrate
those
changes
into
the
target
branch
of
the
repository,
and
it's
not
the
best
experience
we're
already
in
this
milestone
and
the
previous
milestone.
We
are
already
fixing
some
minor
visual
issues
and
alignments
and
sizes,
and
things
like
that.
A
So
there
are
lots
of
different
cases
and
to
start
I
want
to
also
share
the
work
that
katherine
will
be
working
on
in.
I
think
this
milestone,
if
well,
without
trying
putting
too
much
pressure
on
her
this
milestone
or
in
the
near
future,
which
will
be
about
synthesizing
all
of
the
research
that
we
have
around.
A
But
right
now,
I'm
just
focusing
on
this
milestone
on
this
widget,
which
is
one
of
the
most
important
ones
in
trying
to
understand
what
are
the
little
things
that
we
can
do
now.
That
will
have
a
huge
impact,
given
the
constraints,
the
technical
constraints,
the
ux
constraints
of
what
we
have
to
work
on
today.
So
the
first
thing
that
I
did
was
map
all
of
the
states
that
control
this
merge,
widget
and
button
the
actions
and
the
information,
and
that
I
also
captured
the
all
of
the
different
states
with
what
is
shown.
A
What
are
the
texts?
What
are
the
buttons
everything
all
of
the
images
are
here
of
all
the
different
states,
and
it
was
a
scary
task
and
the
the
way
I
I
did.
It
was
just
looking
at
all
of
the
files
that
we
have
in
the
code
base
jumping
through
all
of
them
and
then
testing
it
out
in
the
jdk
using
git
bots,
so
not
to
marcel
there,
and-
and
this
is
the
result
so
and
that's
why
this
is
collapsed,
because
it's
a
huge
description
of
all
of
the
states
in
all
of
the.
A
If
statements
and
what
can
happen,
what
can
happen,
what
are
the
buttons
that
are
shown?
What
are
the
messages?
What
happens
when
there's
a
success
when
there's
a
failure-
and
you
can
see
all
of
this
and
all
of
these
different
messages
and
buttons
are
displayed
and
are
all
conditionally
displayed
on
this
little
area?
So
there's
a
lot
going
on
here
and
without
understanding
this
first,
it
would
have
been
impossible
to
make
any
progress.
So
this
is
almost
completed,
I'm
just
waiting
for
validation
from
someone
from
continuous
integration
engineering
to
validate
what
I
found.
A
I've
also
had
vitica
looking
over
this,
and
she
was
amazing
in
her
help
and
one
of
the
things
that
we
I'd
like
to
do
in
the
future,
and
I've
asked
her
help
for
that,
but
again,
no
pressure.
We
still
don't
know
when
we're
going
to
do
it
is
to
convert
what
I've
had
described
here
and
this
outline
into
a
more
visual
experience,
perhaps
something
that
is
more
consumable
and
maintainable
going
forward.
So
this
is
one
of
the
ideas
and
inspiration
from
how
slack
has
diagrams
their
notification
flow.
A
So
to
answer
the
question:
should
we
send
a
notification?
They
go
through
all
of
these
different
states
and
questions
to
reach
the
end
goal?
Yes
or
no,
so
we
might
do
something
similar
to
that.
We
already
have
an
issue
open
to
create
a
better
documentation.
Format
for
this
mapping
and
vitica
has
already
shared
a
great
ideas.
Here
I
haven't
commented,
the
vitica
don't
worry.
I
will
because
I
have
to
digest
this
as
well.
A
So
thank
you
for
that
and
and
yeah
that's
the
what
we're
going
to
do
forwards
right
now
in
this
milestone.
As
I
said,
I'm
almost
done
completing
the
mapping
just
waiting
for
validation
and,
at
the
same
time,
what
I've
been
doing
now
is
competitive
analysis
of
what
I
try
to
abstract
this.
A
little
bit
to
also
other
tools
is
basically
the
analysis
of
the
code
review.
Merge
checks,
the
ux
in
other
tools.
A
So
basically,
how
does
github
communicate
all
of
the
checks
and
all
of
the
actions
and
information
that
enable
or
disable
or
make
visible
or
make
it
invisible
the
merge
action
in
their
pull
requests
and
then
the
same
thing
I'll
be
doing
for
other
competitors.
Like
garrett's
fabricator,
azure,
devops
and
and
a
couple
of
others,
and
with
this
information,
I'm
going
to
try
to
start
a
design
framework
for
merge,
request
widgets
in
general.
A
But
right
now,
as
I
said,
we'll
be
focused
on
the
merge
button
and
I
laid
down
some
design
principles
here
and
I'm
still
not
sure
how
this
is
going
to
look
in
the
end.
But
what
I'm
thinking
is
that,
with
the
information
that
we
have
today
and
again,
all
of
the
constraints
that
this
will
mostly
be
more
surface
level
now
in
trying
to
organize
the
disorganization
that
we
have
today.
A
So
there
are
very
clear
things
that
we
can
do
today
to
make
this
better,
and
I
mean,
as
we've
all
as
we
all
know,
and
we've
been
here
working
with
merge
requests
and
using
them
every
day.
The
merge
request.
Widgets
are
basically
a
fire
that
it
has
been
burning
for
a
very
very
long
time
and
we
have
to
do
something
about
it.
And
I
want
also
to
give
a
shout
out
to
kai
my
product
manager
for
allowing
me
to
do
this
and
not
scheduling
a
lot
of
things.
A
For
me,
during
this
milestone
and
also
he's
taking
over
some
of
my
ux
reviews
and
merge
requests,
we
still
have
to
see
how
that
pans
out
in
the
next
release
and
how
many
bugs
come
up
now.
But
it's
it's.
It's
amazing
and
I'm
really
happy
that
he's
able
to
do
that
and
yeah.
That's
that's
a
little
bit
of
of
what
I've
been
working
on.
A
B
A
A
Because
what
we
want
to
do
with
what
the
work
I'm
doing
here
and
then
what
katherine
is
going
to
research
is
to
then
come
up
with
a
great
formula
for
to
solve
all
of
those
problems
and
to
answer
the
questions
of
other
designers
like
yourself
that
hey,
I
want
to
add
this
new
check
to
merge
requests,
and
this
is
the
value,
and
this
is
what
we're
expecting.
How
do
I
do
it
and
how
important
that
would
be
so
yeah?
It's
it's
not
the
best
answer,
but
it's
what
we
can
do
right
now.
So.
B
C
Yeah,
I
apologize
that
this
might
be
a
bit
orthogonal
to
your
presentation,
but
it's
something
I've
been
meaning
to
ask
you
for
a
while.
So
it
was
like
top
of
mind
all
of
a
sudden
are
there
things
like
rmr
experience
is
mainly
in
the
browser,
or
we
give
a
little
url
when
you
make
a
commit
right
like
you,
can
copy
and
paste
or
click
on
the
url
url
in
your
terminal
to
go
to
the
new
merge
request
in
the
git
lab
ui.
A
Yeah
great
question:
yeah
we
as
marcel
is,
is
also
sharing.
We
have
part
of
the
code
review
group.
We
also
have
the
responsibility
of
working
on
the
gitlab
extension
for
vs
code,
and
we
have
an
epic
that
I
linked
there
to
review.
Merge
requests
inside
of
vs
code,
so
you
wouldn't
have
to
leave
and
come
to
gitlab.
A
We
think
that
so
one
thing
that
we
already
do
today
is
showing,
besides
showing
the
diffs,
is
allowing
you
to
navigate
between
merge
requests
inside
of
vs
code,
which
is
already
amazing,
and
what
we're
doing
now
we're
in
the
early
stages
of
allowing
you
to
comment
inside
of
vs
code,
and
this
is
uncharted
territory
for
us
and
we're
still
figuring
this
out,
and
we
also
don't
have
like
there's.
We've
done
problem
validation
around
this
and
and
it's
clearly
a
problem
we
need
to
solve
and
we
need
to
meet
developers
where
they
are
so.
D
A
A
So
it
was
a
it
was
a
very
honest
conversation
and
and
then
yeah
I
asked
them
very
directly
like
would
you
be
open
to
review,
merge
requests
from
me
like
not
all
of
them,
but
the
ones
that
are
most
straightforward
and
he
was
very
happy
to
do
that
and
like
as
as
mike
nichols
knows
like
you
worked
with
kai
as
well
and
he's
very
hands-on
with
this
kind
of
thing,
and
I
and
I
want
product
managers
to
do
that
more.
I
want
them
to
do
more
research.
A
A
I
didn't
I
I
didn't
know
it
was
so
much
work
and
it
is
unfortunately
it's
it's
a
lot
of
work
and
it's
work
that
we
have
to
do
but
yeah
it's
we've
paused
during
this
milestone,
and
I
hope
we
can
continue
our
regular
work
in
the
next
milestone.
But
yeah
it's
it's.
It's
basically
a
very
honest
communication.
I
think
that's
the
only
solution,
yeah.
E
Can
I
I
want
to
interject
that
what
an
amazing
approach
and
collaboration
between
you
and
kai,
because
you
kind
of
did
like
you,
got
the
best
of
both
worlds?
You
got
your
team
working
on
these
debt,
fixes
that
we
have
a
hard
time
prioritizing
anyway,
and
then
you
are
able
to
pull
up
and
do
the
strategy
piece.
So.
A
Thanks
yeah,
no,
it's
the
the
part
about
the
bugs
and
prioritizing
them.
It
was
a
lot
of
complaining
from
my
part,
every
single
milestone
and
having
those
prioritization
sessions
that
I
still
intend
to
document
is.
It
was
just
complaining
and
complaining.
We
have
these
bugs.
We
have
these
bugs.
We
have
these
bugs.
We
have
this
and
yeah,
and-
and
I
mean
everyone
feels
it
fills
those
bugs
as
well
so.