►
From YouTube: Settings UX - Create:Source Code
Description
As part of the overarching initiative to improve the GitLab Settings experience, we will collect existing user feedback and proposals in order to drive user experience and SUS score improvements for settings. This is a conversation with Create:Source Code
More on https://gitlab.com/groups/gitlab-org/-/epics/3535
A
B
A
B
B
So
all
of
those
are
our
small
things
and
they're
very
concerned,
I'm
very
I'm
very
comfortable
knowing
that
you
are
leading
this,
so
I'm
aware
that
you're
probably
going
to
fix
all
those
things
or
at
least
put
them
in
the
right
place.
What
I'm
more
concerned
about
that,
maybe
I
can
talk
more
about,
is
the
architecture
of
the
settings.
B
I
think
that's
might
be
the
biggest
problem
which
which
can
impact
the
success
of
using
a
pattern
like
the
expandable
sections
like
if
people
can't
navigate
well
and
find
their
way
around
having
expandable
sections
are
not
doesn't
make
any
difference,
because
people
are
still
lost.
People
still
need
to
read
all
of
the
labels.
B
So
in
that
regard,
although
it's
something
that
I've
known
for
some
time
also
also
as
a
user
of
gitlab
in
the
recent
category
category
with
scorecard
card
research,
two
big
themes
related
to
settings
and
the
navigation-
and
I
think
you
might
be
aware
of
them-
one
of
them
is,
I
think,
global
and
it
affects
all
settings.
Is
configuring
settings
in
the
features
themselves
versus
at
the
project
level
and
more
outside
of
the
features?
B
B
A
B
Approvals
in
general
and
gates
that
you
put
in
place
in
checks
and
balances
to
make
sure
that
things
are
reviewed,
audited,
approved
and
so
on,
and
all
of
these
things
come
back
to
merge
requests
because
merge
requests
are
the
door
where
through,
where
all
of
the
changes
happen
right.
If
you
want
to
make
a
change
to
something,
it
goes
through,
merge
requests
from
there
all
of
these
different
settings
about
approvals
about
pipelines
flow
through
there.
So
there
are
a
lot
of
related
settings
and
it's
difficult
to
find
your
way
around
them.
B
But
to
me
the
most
difficult
ones
is
definitely
definitely
to
find
just
the
merge
request.
Settings
like
where
can
I
find
I
mean
you
go
and
you
see
repository
settings.
So
is
it
in
repository
because
that's
where
I
store
my
code,
but
no
it's
in
general
and
merge
requests
have
nothing
general
about
them.
Merge
requests
are
one
of
the
most
important
features
of
gitlab,
right
after
repository
of
course,
and
maybe
in
parallel
with
pipelines
right
and
we
don't
have
a
heading
for
it.
So
it's
very
difficult
to
find
it
once
you
do.
B
You
already
know
it's
there.
Of
course,
but
then,
if,
when
you
want
to
set
things
related
to
the
merge
requests,
but
also
related
to
the
repository,
that's
when
things
start
getting
a
little
murkier.
So
that's
what
I
would
say
like
the
two
themes,
sections
in
the
features.
That's
not
just
not
features
in
the
project
settings
as
we
have
today
or
in
both
places,
and
then
the
second
one
is
like
merge
requests
having
their
own
section
and
also.
B
A
B
A
I
have
some
people
saying
that
it
would
be
nice
to
have
more
entry
points
on
the
feature
itself
for
settings
other
than
you
know
the
whole
information
architecture
and
restructuring
how
you
either
navigate
to
settings,
but
also
how
things
are
displayed
on
the
page,
and
I
just
wanted
to
give
you
an
update
that
the
your
team,
actually
they
create
your
state,
create
mistaking
over
settings
and
michael
lee
he's
invited
to
this
call.
He
okay,
he
declined
yeah.
I
think
he's
a
different
time
zone,
so
he's
going.
A
B
But
in
the
in
the
user's
journey
settings
it's
one
of
those
things
that
you
set
once
and
forgets,
or
you
don't
go
there
that
often
and
for
us,
we're
much
more
concerned
and
occupied
with
improvements
to
these
experiences,
people
that
spend
a
lot
of
time
like
their
whole
day
in
merch
requests
or
the
repositories
so
for
us
right
now,
fortunately
slash.
Unfortunately,
it's
not
a
priority
for
source
code
specifically,
and
I
I
hope
that
someone
can
help
us
basically.
A
Yeah,
I'm
not
sure,
specifically,
I'm
not
sure
if
you
saw
I'm
gonna
link
you
to
this
one
actually
added
here
to
the
agenda,
these
two
items:
settings
ux,
learning
and
recommendations.
So
this
is
a
huge
summary
of
all
my
my
findings
and
the
conversations
I
had
with
the
designers,
so
lack
of
standardized
ui
elements
and
patterns
and
the
first
step
here.
It's
exactly
what
you
mentioned:
mix
of
radio
buttons
and
toggles
how
to
save
and
a
save
button.
A
A
A
A
B
One
thing
I
wanted
to
share
with
you
regarding
the
like
setting
things
in
the
future
themselves
or
not.
Is
I
added
an
example?
I
will
clarify
it.
So
it's
easier
for
you
to
find
the
cursor
and
it's
called
the
link
code
owner's
file
and
affected
files
to
code
owner
settings,
and
this
is
basically
came
out
of
the
research
because
we
noticed.
B
Itself,
but
that's
another
thing,
but
what
happened
was
that
if
people
I
can
show
you
this
in
live.
So
if,
let's
imagine,
I
want
to
go
here
to
the
code
owners
file
of
the
gitlab
project
right,
I'm
here
and
the
most
important
feature
related
to
code
owners
is
enforcing
all
of
these
people
that
are
described
here
to
approve
a
merge
request.
If
something
changes
is
one
of
these,
these
paths
right.
So
it's
like
changes,
yeah
or
mike
gang.
We
need
them
to
approve.
B
We
want
to
require
approval,
we
don't
have
any
way
of
you
to
navigate
there.
So
one
of
the
recommendations
that
I
drafted
was
what,
if
we
linked
the
code
owners
file
and
maybe
even
the
affected
files
like
when
when
you
go
into,
for
example,
this
file
in
the
in
the
repository,
we
have
a
button
somewhere
that
says
like
navigate
to
the
settings
to
enforce.
You
know
the
the
approvals
or
something
like
that.
So.
A
A
A
Especially
when
you
work
with
personas,
they
are
not
so
technical
in
release
management.
We
have
that
a
lot.
We
have
the
release
managers
they're
just
you
know,
dealing
with
the
ui
every
day
and
then
you
have
devops
engineers
that
are
actually
doing
release
management.
So
they
do
everything
on
the
api.
B
Yeah,
what
I'm,
what
I'm
describing
was
actual
user
behavior.
So
people
it
was
just
not
one
person
we
tested
with
six
people-
and
I
know
that's
that's
not
a
lot,
but
from
those
six
people.
I
think
I
don't
have
the
the
right
numbers,
but
four
or
five
people
went
directly
into
the
file
and
tried
to
find
their
way
around
them
right.
So
this
is,
I
mean
for
this
feature.
It
could
work,
maybe
for
other
features.
B
B
One
other
thing
that
I
don't
know
if
it's
someone
brought
this
up
and
how
it's
related
to
settings,
but
I
think
it
is
in
a
way
is-
is,
for
example,
the
user
preferences
and
again
this
is
an
example
that
I
think
could
be
also
applied
to
the
project.
Settings
admin,
settings
and
so
on
is,
for
example,
we
have
this.
B
The
setting
here
that
says,
show
white
space
changes
in
dips
and
we
also
have
that
in
the
merge
requests
inside
this
cog
drop
down,
where
you
can
basically
what's
in
here,
and
what
you
change
here
only
affects
you.
So
this
is
these:
are
the
user
preferences
inside
merge
requests
but
we're
kind
of
unsure
where
we
should
place
these,
so
this
shows
changes
actually
it's
broken,
because
if
there's
a
bug
between
us
synchronizing
this
checkbox
and
the
checkbox
here,
so
that's
also
another
problem.
B
So
should
we
duplicate
this
or
not,
and
I
think
what
I'm
saying
here
could
also
be
this
thought
process
could
also
be
applied
to
settings
in
general
and
one
other
thing
just
to
give
you
a
clear
example
of
what
we're
doing
now
in
this
milestone.
We
have
this
setting
and
this
user
preference.
I
don't
know
if
you've
ever
used
it,
but
it
allows
you
to
just
see
one
time
when
you're
reviewing
changes
in
the
merge
request.
B
So,
instead
of
seeing
all
the
changes,
stacked
and
the
files,
you
only
see
one
file
at
a
time,
and
this
is
really
good
for
large
merge
requests,
but
right
now
this
is
buried
here
and
people
have
to
know
it
exists.
They
have
to
come
into
preference
and
they
have
to
find
this
and
click
it.
So
we're
going
to
display
it
here
right.
B
So
this
is
why
the
issue
is
scheduled
for
this
milestone
and
we
have
the
idea
to
just
add
this
checkbox
that
does
this
here,
but
because
of
the
complexity,
the
technical
complexity,
thinking
about
removing
what
we
have
here
and
just
having
the
preference
here,
because
we
already
have
a
lot
of
other
things
here
and
technically.
This
could
be
easier,
but
with
all
of
this,
and
as
you
can
see,
there
are
a
lot
of
inconsistencies
and
there's
not.
B
B
A
They
want
to
move
things,
move
their
features
to
become
a
first
class
citizen,
and
that
means
that
the
settings
need
to
move
out
from.
You
know
that
one
hidden
checkbox
option
in
a
random
settings
page
to
become
closer
to
the
feature
or
more
highlighted
in
in
the
settings
page
in
the
navigation,
etc,
and
on
that
note,
valerie
put
together
a
where.
B
A
B
A
These
all
will
evolve,
of
course,
yeah.
This
is
going
to
require
engineering,
but
I
think
one
of
the
first
things
that
we
can
just
tackle
is
defining.
How
do
we
want
this
to
work
from
a
user
point
of
view,
doing
exactly
what
you,
what
you
just
say,
bringing
the
the
the
insights?
You
know
the
findings.
A
B
B
We
we're
doing
that
because
people
change
those
preferences,
often
right
it
depends
and
people
don't
want
to
leave
their
flow
to
say,
hey.
I
want
to
see
these
merge
requests
side
by
side
or
in
line.
I
don't
know
if
you
you,
if
you
also
do
this
often
like
sometimes
change
the
the
view
type,
but
but
a
lot
of
people
do
this.
B
So
we've
reckoned,
although
we
don't
have
proper
research
on
it
and
knowing
from
others
usage,
we
know
that
they
change
those
preferences
while
they're
working
right
and
that's
different
from
the
setting
and
forgetting
about
the
settings
so
and
another
thing
that
I
don't
know
if
someone
has
mentioned
already,
is
this
other
layer
about
who
is
affected
by
the
settings?
So
I
think
probably
someone
has
already
mentioned
the
cascading
effects
of
the
settings
like
in
system
and
then
project.
So
that
is
also
that
complexity
that
we're
adding
right
now
to
the
product.
B
A
A
A
So
I
would
say,
have
a
look
at
these
issues
because
they
have
a
lot
of
answers
and
like
permissions,
for
example
the
personas
everyone
is
everyone
that
has
permission
to
either
change
something
in
the
group
or
project
but
their
own
settings
and
having
an.
I
have
that
problem
in
release
management.
Right
now
is
to
giving
users
contextualization
on
why
things
work
in
a
certain
way,
even
though
they
cannot
edit
that
specific
settings,
it's
something
that
we
can
get
better.
A
You
know
in
many
different
areas
right
now,
for
example,
you
do
set
up
a
deploy
freeze
and
then
your
application
doesn't
deploy
on
weekends.
Why
there's
nothing
that
tells
you!
You
know
that
this
is
happening,
so
it
might
not
be
something
specific
to
yeah
letting
people
do
a
setting
task,
but
giving
them
the
context
of
why
things
work.
The
way
they
do
with
git
lab
is
definitely
necessary
and.
B
B
B
A
A
B
A
A
You
know
with
you,
so
I
think
that's
that's
the
type
of
collaboration
that
I'm
I'm
looking
for
at
this
point,
because
it's
a
big
effort
and
if
we
look
at
information
architecture
only,
I
don't
think
you
know
we're
gonna
solve
this
problems
that
you
just
mentioned
about
the
contextual
access,
and
these
are
the
decisions
that
I
feel
that,
yes,
we
need
research.
Yes,
we
need
the
broader.
You
know
a
dri,
maybe
helping
make
some
of
these
decisions.
A
A
B
This
was
great
and
thank
you
so
much
for
all
the
work
here
and
I
also
appreciate
a
lot.
I
don't
know
if
anyone
has
mentioned
already,
but
I
appreciate
the
fact
that
you
created
a
video
like
an
in-depth
version
of
the
learnings
and
recommendations.
I
think
that's
a
really
good
way
of
communicating
these
things.
It's
another
way
of
communicating
and
it's
it's
very
helpful.
So
thank
you
for
that.