►
Description
A summary of the “Category Maturity Scorecard” research done in FY21-Q2 for the “Create:Source Code:Code Review” product category of GitLab. Pedro Moreira da Silva (Staff Product Designer, Create:Source Code), walks through the main insights and themes of the research, with practical examples in the product.
1. Intro to Category Maturity and Scorecards: 00:25
2. Overview of insights and recommendations: 02:13
3. Theme — Navigation and settings: 03:15
4. Theme — Cluttered merge request UI: 07:11
5. Theme — Non-intuitive Code Owner features: 09:38
Links:
- GitLab Product Maturity: https://about.gitlab.com/direction/maturity/
- Category Maturity Scorecards: https://about.gitlab.com/handbook/engineering/ux/category-maturity-scorecards/
- Scorecard recommendations: https://gitlab.com/gitlab-org/gitlab-design/-/issues/1374
- Insights summary: https://dovetailapp.com/projects/ac5e32e9-616d-4ddd-a1bb-1eb49084fe4e/insights/present/21dd7c03-009c-4c69-a856-4dd4aa2e0565
- All insights: https://dovetailapp.com/projects/ac5e32e9-616d-4ddd-a1bb-1eb49084fe4e/insights/present
- Code Owners docs: https://docs.gitlab.com/ee/user/project/code_owners.html
- Merge Request Approvals docs: https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html
- Protected Branches docs: https://docs.gitlab.com/ee/user/project/protected_branches.html
A
So
what
is
the
maturity
of
a
category
in
gitlab,
so
the
product
is
divided
into
several
stages:
manage
plan
create
and
so
on
and
inside
of
each
stage.
There
are
a
number
of
different
categories
where
all
the
different
functionalities
or
features
fit
into
in
this
case,
I'm
working
in
the
create
stage-
and
I
work
works
quickly
with
two
of
these
categories:
code
review
and
source
code
management
and
we
decided
to
validate
the
lovable
maturity
of
code
review.
You
see
here
with
this
little
heart
icon
and
each
each
category
has
its
own
maturity
level.
A
We
have
a
page
dedicated
to
this
and
you
can
look
through
it
if
you
want
on
your
own
time,
but
in
essence
this
is
a
summative
evaluation,
where
we
take
external
users
of
kit
lab
and
run
them
through
a
series
of
scenarios
and
evaluate
their
performance
against
the
product
and
against
the
features
and
workflows
that,
in
this
case,
the
code
review
category
supports,
and
that
would
give
us
a
final
maturity
score
to
update
this.
This
maturity
page.
A
I'd
like
to
to
focus
today
on
the
three
big
themes
that
came
out
of
the
research.
So
this
is
the
inside
summary
card
which
I'll
also
link
to
the
description,
and
there
are
three
main
themes.
The
first
one
is
navigation
and
settings.
The
second
one
is
the
merge
request,
ui
and
the
third
one
is
the
code
owner
features
specifically
the
code
owner
approvals
feature.
So,
let's
start
first
by
navigation
and
settings
being
overwhelming
and
confusing.
A
They
usually
click
through
all
of
these
different
or
many
of
these
different
items
in
the
navigation
and
just
didn't
know
where
to
go,
because
there
was
just
so
many
options,
and
so
this
is,
if
we
look
at
hicks
law,
the
the
time
that
users
spent
looking
at
different
options
increases
with
the
number
of
those
options.
So
they
kind
of
froze
and
didn't
know
where
to
to
go.
A
A
Set
the
preferences
or
change
settings
in
the
features
themselves.
Another
thing
is
related
to
this:
is
the
settings
themselves
specifically
the
placement
of
merge,
request,
approval
settings
and
also
how
do
repository
and
merge
requests
policy
settings
are
related
and
how
do
you
navigate
to
them?
And
what
does
this
mean
in
practice?
So
today,
when
you
go
to
settings
general
in
the
project
level,
you
see
all
of
these
different
things
like
naming
topics
and
avatar
visibility,
projects,
users,
permissions
and
then
you
have
the
merge
request.
A
Settings
which
is
one
of
the
interesting
features
of
kit
lab,
doesn't
have
its
own
dedicated
section.
It's
inside
general
and
users
need
to
go
here
and
scroll
down
through
this
and
find
the
merge
request
approvals.
So
this
is
was
a
pain
point
and
many
users
took
more
time
than
we
expected
to
find
this.
So
there's
a
possibility
would
be
to
elevate.
All
of
these
merge
request
related
settings
into
their
own
section.
A
The
other
thing
is
the
relationship
between
these
settings.
The
merge,
requests
and
merge
request
approvals
with
another
area
of
the
settings,
which
is
the
repository
and
the
repository
and
the
merge
requests
have
a
lot
in
common
and
they
interact
throughout
the
devops
life
cycle
and
specifically
here
one
of
the
most
important
settings
that
changes
the
merge
request.
A
Behavior
a
lot
is
the
protected
branches
and
also
protected
tags,
but
usually
people
set
up
the
protected
branches
and
people
failed
to
see
the
relationship
and
to
find
these
settings
because
they're
so
far,
apart
they're
in
completely
different
areas
of
the
settings
and
in
in
one
of
these
scenarios,
we
asked
users
to
find
this
setting
this
little
toggle
button
here
that
says
code
owner
approval,
so
that
you
would
enforce
code
owner
approvals
for
a
specific
branch.
But
I'll
talk
about
this
in
a
minute.
A
The
second
theme
is
the
merge
request,
ui
being
cluttered,
so
what
does
this
mean
in
practice
in,
in
general,
with
users
found
the
merge
request
review
page
to
clutter?
So
this
is
this
page
that
you
see
here
this
tab
and
they
just
found
it
too
clear
to
to
find
and
then
perform
the
basic
tasks
in
a
code
review
scenario,
two
specific
things
here:
one
of
them
was
they
found
it
hard
to
find
the
approve
button,
so
they
navigated,
even
across
the
tabs,
in
the
merge
request.
A
So
it's
this
new
button
that
we
have
here
same
mark
as
drafts
or
mark
is
ready.
This
was
a
direct
recommendation
and
something
that
we've
already
fixed
in
the
the
milestone
that
came
right
after
this
research.
So
this
is
one
of
the
things
that
we
have
already
improved
and
we
hope
that
this
is
much
more
visible
way
for
people
to
signal
that
the
merge
request
is
still
in
progress.
A
The
third
theme
is
the
co-owner
features
not
being
intuitive,
and
there
are
a
lot
of
actionable
insights
here.
Some
of
them
came
as
a
result
of
analyzing
and
looking
at
users
behavior
and
not
necessarily
the
the
things
that
they
that
they
failed
to
do
in
the
scenarios
so
or
succeeded
in
the
scenarios.
So
again
we
see
here
the
improving
of
the
organization,
repository
much
request,
policy
settings
and
cross-linking
the
approvals
and
protected
branches
settings,
which
is
what
I
was
just
showing
you
before.
A
So
we
have
in
the
general
settings
the
merge
request
approvals,
but
then,
if
you
want
to
set
another
kind
of
approval,
the
code
owner
approvals
that
are
linked
to
the
file
paths
and
people
that
are
responsible
for
specific
files
in
the
repository,
those
settings
are
not
here
at
all.
We
have
this
little
information
alert
saying
that
the
required
approval
from
code
owner
setting
was
moved
to
protected
branches,
but
in
our
experience
in
the
research
all
of
the
users
either
didn't
read
this
or
if
they
read,
they
just
closed
it
immediately.
A
So
it
didn't
make
any
use
of
having
this
alert
here
and
we
have
those
settings
in
the
settings.
Repository
section
for
protected
branches
and
those
are
completely
separate,
as
you
can
see,
from
the
regular
approvals
and
it's
this
little
toggle
that
you
need
to
click
here
to
enable
this
amazing
functionality
something
more
specific
about
the
code.
A
Owners
was
just
the
understanding
of
what
the
coderness
file
does,
and
we
noticed
that
when
we
asked
users
to
find
this
setting
to
enable
the
code
on
approvals,
most
of
them
went
to
the
code
owner's
file
or
to
a
file
that
was
managed
by
the
code
owners
and
they
tried
to
find
why.
While
looking
at
this
code
owner's
file,
that
has
the
file
paths
and
the
people
that
are
responsible
for
the
file
paths,
the
code
owners,
they
try
to
look
for
buttons
or
settings
here.
A
That
would
allow
them
to
enable
the
approvals
right,
because
this
is
very
similar
to
the
experience
of
the
merge
request
approvals.
If
you
want
to
set
a
merge,
merge
request,
approval
rule,
you
can
create
one
and
once
it's
created,
you
can
then
change
the
number
of
approvals
required
for
this
rule
right
and
you
can
even
make
it
optional
by
setting
this
number
to
to
zero,
and
so
users
try
to
do
the
same
thing
in
the
code
owners
file
looking
at
how
they
can
require
what
they
just
edited
right.
A
A
So
this
scenario
of
enabling
the
setting
the
code
owner
approval
was
very
likely
the
longest
scenario
where
users
spend
their
time
in
the
research
and
while
trying
to
find
this,
some
of
them
even
went
and
searched
the
web
for
some
documentation.
Some
help
some
guidance
to
help
them
find
their
way
and
a
lot
of
them
ended
up
on
this
page.
The
code
owners
page
or
the
merge
request
approvals,
documentation
page
and
in
these
documentation
pages
it
was
very
difficult
for
them
to
find
anything
useful.
A
They
spent
a
lot
of
time
reading
through
this
trying
to
look
at
the
headings.
Some
of
them
even
found
the
sentencing
approvals
by
code
owners.
They
read
through
all
of
this,
but
they
didn't
understand
how
they
would
be
able
to
find
the
right
setting
right
and
the
same
thing
in
the
merge
request
approvals.
They
went
through
all
of
this.
A
They
found
this
merge
requests,
sorry,
the
code
owners
as
illegible,
approvers
heading,
and
here
it
says,
if
you
add
a
code
owner's
repository,
the
owners
will
become
eligible
approvers
and
then
so
so
it
doesn't
say
if
it's
enabled,
if
it's
not
enabled-
and
the
key
here
is
just
this
little
link
at
the
bottom.
That
actually
makes
this
feature
much
more
powerful
and
it
says,
alternatively,
you
can
require
coder
approvals
for
protected
branches
and
the
same
thing
exists
in
the
code
owner's
documentation
page.
A
If
you
look
very
closely
it's
this
one,
as
required,
approvers
for
protected
branches
and
and
this
little
link-
and
this
little
point
here-
unlocks
the
whole
purpose
or
or
most
of
the
powerful
the
power
of
this
feature.
And
if
you
click
here,
you
would
then
go
into
this
page
where
it
explains
to
you
how
you
can
require
the
code
owner
approval
so
yeah.
This
was
a
very
quick
overview
of
the
three
main
themes
that
came
out
of
the
code
review,
category
materials
scorecard
and
yeah.