►
Description
- RICE framework: https://about.gitlab.com/handbook/product/product-processes/#using-the-rice-framework
- Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/299195
A
Today,
I'm
going
to
share
with
you
an
approach
that
I
recently
took
in
an
issue
to
break
down
the
design
into
actionable
steps
in
hopes
that
it
might
help
some
of
you
on
breaking
down
designs.
So
in
this
issue
I
was
exploring
how
we
could
design
a
structured
framework
for
the
merge
request,
merge,
widget
and
yeah.
I
had
all
of
this
in
figma
with
many
different
states
and
and
different
proposals.
A
For
example,
here
I
had
just
the
structure
with
what
can
be
inside
the
title,
what
kind
of
actions
and
what
the
style
would
be,
where
the
merge
options
would
land
and
the
merge
button
where
alerts
would
be
positioned.
So
this
is
just
the
abstract
component
and
then
how
the
component
was
was
shown
in
in
with
a
practical
example,
and
it
also
had
other
ideas
like
showing
how
many
merch
checks
have
failed
and
if
you
click
this
button
view
merge
checks
what
it
would
show.
A
A
So
there
were
a
lot
of
different
aspects
here
in
this
big
exploration
of
the
merge
widget,
and
it
also
led
me
to
create
separate
threads
for
feedback
in
the
issue
itself
and
separating
things
in
the
beginning
between
must-haves
nice
to
haves
and
could
haves
things
that
I
knew
that
I
had
some
confidence
on
and
that
I
knew
that
if
we
implemented
them,
they
could
have
a
very
big
positive
impact
on
usage.
Some
other
things
like
the
visual
design
and
the
text.
I
wasn't
sure
so.
A
I
considered
them
nice
to
haves
in
the
beginning
and
then
could
have
things
that
I
knew
would
take
longer
to
implement
or
we
needed
more
research
or
we
needed
involvement
from
other
groups.
So
it
was
not
a
high
priority
right
now
for
me
to
work
on
and
and
yeah
and
here
below,
I
had
some
threads
just
one
for
viewing
and
expanding
the
merge
checks
and
seeing
all
of
them
or
not,
one
of
them,
just
a
thread
just
focused
on
visual
design
with
jeremy,
as
I
mentioned
earlier,
commenting
here
and
leaving
some
feedback
on
explorations.
A
Yeah
there
were
threads
about
other
concepts
and
other
parts
of
the
design
so
trying
to
break
down
the
discussion
into
more
manageable
pieces.
But
in
the
end
I
realized
like
we
need
to
move
forward
with
this.
We
can't
be
here
forever
discussing
all
of
these
aspects,
so
I
went
back
to
one
of
our
product
management.
A
If
you're
not
familiar
with
it
very
quickly,
it's
trying
to
attribute
score
on
an
idea,
a
project,
an
initiative
whatever
it
is
to
try
to
prioritize
it
with
other
similar
things
in
terms
of
reach,
impact,
confidence
and
effort.
So
that's
why
it's
called
rise
r.
I
c
e
reach
impact,
confidence
and
effort,
and
I
took
this
framework
and
I
thought
well.
Why
don't
I
try
to
apply
this
to
this
very
big
idea
with
all
of
these
concepts
here
in
figma?
A
How
can
I
break
this
down
and
try
to
think
more
objectively
about
the
priorities
of
each
of
the
aspects
in
this
design?
So
that's
what
I
did.
I
first
listed
them
and
did
a
breakdown
of
in
my
mind.
What
were
the
independent
concepts
things
that
we
could
do
independently
from
one
another
that
wouldn't
have
a
lot
of
effect
on
each
other
in
terms
of
implementation,
and
then
I
tried
to
think
about
the
reach,
the
impact,
the
confidence
and
the
effort.
A
So,
for
example,
this
first
item
that
I
then
created
an
issue
for
it
to
restructure
the
merge
request,
widget,
which
would
be
to
reorder
the
merge
options
in
action
to
move
an
alert
to
another
location,
to
have
a
new
placement
for
the
errors,
so
just
the
structure
itself
and
the
interaction
design.
I
believed
that
these
changes
I
had,
as
I
wrote
here
with
a
c1,
that
I
had
very
high
level
of
confidence
on
this,
because
compared
to
everything
else
and
compared
especially
to
what
we
have
today.
A
A
It
also
wouldn't
be
a
medium
impact,
it
would
be
high,
but
it
would
only
have
impact
on
a
certain
type
of
users
and
those
would
be
just
specific
users
of
the
merge
request.
So
that's
why,
in
the
reach,
I
scored
it
as
with
a
six
impacts,
a
large
percentage
50
to
80
percent,
of
what
I
thought
were
the
users
of
merge
requests.
So,
in
this
specific
case,
the
merge
widget
is
only
visible
to
users
that
can
merge,
or
I
mean
it's
more
used
by
the
users
that
can
merge.
Anyone
can
see
this
widget.
A
It
would
have
a
very
big
impact,
so
it
would
impact
the
vast
majority
of
all
the
users
of
merger
requests,
because
everyone
would
see
the
links,
the
headings
and
the
text,
it's
not
something
that
they
can
opt
into
and
use.
The
button
doesn't
use
the
options,
it's
something
that
everyone
sees
when
they
use
a
merge
request.
A
A
So
that's
why
I
gave
it
a
low
confidence
and
in
terms
of
effort,
I
would
also
think
that
all
of
this
would
probably
take
a
month
to
to
work
on,
maybe
less
I
don't
know,
but
in
the
end
this
formula
gave
me
a
score
of
five.
So
these
are
two
examples
and
in
the
end
I
focused
on
just
the
top
ones
that
scored
the
highest
restructured.
The
merge
request,
widget,
sorry,
the
merge
request,
merge,
widget
with
12
and
then
the
ui
text.
Improvements
as
12,
because
I
mean
changing
text
is
very
easy.
A
We
had
high
confidence
that
the
current
text
that
we
have
is
just
not
consistent
and
not
easy
to
read
and
actually
leads
to
people
filing
bugs
and
issues,
because
they
don't
understand
what
they
need
to
do
or
what
the
current
situation
is.
That
is
blocking
the
merge.
So
that's
why
it's
scored
very
high
and
yeah.
This
is
just
the
experiment
that
I
made
with
breaking
this
down
this
bigger
design
using
the
right
score
method,
yeah,
I'm
open
to
your
thoughts
and
feedback.
A
Let
me
know
what
you
think,
and
I
hope
this
helps
you
or
at
least
inspires
you
to
think
in
similar
ways
of
how
we
can
break
things
down
in
a
more
objective
way,
trying
to
separate
our
own
biases,
because
we've
we're
we're
deep
in
figma
we're
deep
in
the
design
discussions,
and
sometimes
we
think
oh
this.
This
is
very
important
or
this
is
not
so
important.