►
From YouTube: Settings UX - Monitor:APM
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 Verify:Testing & Runner
More on https://gitlab.com/groups/gitlab-org/-/epics/3535
A
Awesome
so
again,
thank
you
for
meeting
with
me
today,
nadia
and,
as
you
know,
we're
here
to
talk
about
settings
today
and
it's
just
an
informal
conversation
and
meeting
with
designers
to
instead
of
collecting
information
in
an
issue
to
just
understand
a
little
bit
about
where
they
are
right
now,
which
settings,
design,
work
and
discuss
a
little
bit
of
opportunities
so
that
we
can
find
a
common
ground
for
improvements
in
settings
and
I
think
you've
already
seen.
But
I'm
just
gonna
drop
you
in
the.
B
A
That
we
have
this
epic,
that
lists
existing
issues
bugs
and
future
requests
for
settings,
and
the
goal
of
this
initiative
is
to
improve
the
overall
settings
experience,
but
we
also
want
to
collect
a
specific
feedback
and
specific
user
insights
that
we
might
have
across
gitlab.
That
will
drive
the
system.
The
usability
for
settings.
A
Yeah-
and
I
just
wanted
to
kind
of
hear
from
you,
if
you
had
like
any
settings
design
work
that
you
were,
you
know
that
you
do
had.
B
Yeah
I
can,
I
can
set
the
stage
and
share
a
little
bit
about
the
citrix,
this
centric
settings
that
we
have
in
metrics
wow
a
new
word.
We
just
came
up
with
a
new
word.
All
right,
I'll,
share
my
screen
and
show
you
what's
happening.
B
Okay,
can
you
see
the
metrics
dashboard
yeah?
Okay,
it's
still
loading,
but
so
for
metrics
dashboards.
We
have
two
types
of
settings
which
are
kind
of
different,
but
I
think
they're
still
settings.
So
there
are
some
things
that
you
can
configure
to
change
the
way
your
metrics
dashboard
works
like
as
a
product
like
you
can
choose
to
show
time
in
utc
or
in
your
local
time
zone,
for
example,
and
these
things
admins
can
set
for
the
project.
B
B
First
of
all,
there
will
be
many
more
settings
for
the
metrics
dashboard,
so
that
already
is
a
bit
concerning
in
the
context
of
this
specific
pattern
that
we're
using
here
so
like.
If,
if
we
have
like
a
whole
page
of
settings,
does
it
still
make
sense
to
have
it
in
this
layout?
Is
it
really
the
best
option
here,
maybe
not,
and
then
of
course,
the
good
old
question
of.
B
Why
are
these
settings
so
far
away
from
the
product?
So,
as
you
might
have
noticed,
we
kind
of
sneakily
implemented
this
little
settings
button
in
the
ui,
which
is
our
mvc
way
of
bringing
the
settings
closer
to
the
actual
product.
So
that
way
at
least
the
user
can
have
a
shortcut
like
this
to
go
to
that
page
now.
So
these
are
the
settings
that
you
use
to
configure
some
of
those
like
yeah,
some
of
the
admin
settings
for
the
dashboard
as
a
product.
B
Then
there
are
all
kinds
of
configuration
settings
for
prometheus,
which
you
need
in
order
to
enable
metrics,
so
enabling
metrics
requires
you
to
either
install
prometheus
on
a
cluster
in
gitlab,
or
you
can
have
your
own
prometheus
instance
running.
But
basically
you
need
to
configure
prometheus
and
that
right
now
lives
in
settings
integrations
and
it's
again
it's
really
scattered,
but
it's
all
part
of
configuring
metrics
and
it's
not
something
that
you
would
configure
only
once
and
never
touch
again.
B
Oh,
and
I
noticed
that
we
changed
this
little
indicator
to
a
check
mark.
That
is
much
better
than
the
dots
that
we
used
to
have
so
yeah.
It's
not
something
that
you
will
just
enable
once
and
forget
about
it.
It's
something
that
you
will
keep
coming
back
to.
B
You
might
be
juggling
many
different
data
sources
here,
so
you
might
have
two
different
prometheus
instances
running
on
two
different
kubernetes
clusters
and
you
might
also
have
a
manual
configuration
and
now
we
also
have
an
issue
open
to
allow
users
to
have
multiple
manual
configurations,
which
is
really
the
external
prometheus
instance
that
you're
running
somewhere
else
and
you're
just
connecting
it
to
gitlab.
B
So,
basically,
when
as
a
metrics
user,
when
using
dashboard,
you
have
to
every
once
in
a
while
go
to
the
prometheus
page,
and
then
you
also
need
to
go
to
metrics
settings
and
all
of
these
things
are
scattered
all
over.
So
the
challenges
that
we're
facing-
and
we
haven't
really
done
that
much
work
around
it.
To
be
honest,
like
this,
we
just
put
this
button
the
settings
button
in
the
dashboard
as
a
quick
fix
for
now,
while
gitlab
as
a
whole
is
kind
of
figuring
out
what
to
do
with
the
settings.
B
But
then
there's
this
bigger
problem
of
how
do
we
treat
configuration
versus
settings
and
how
do
you
make
it
easy
for
the
user
to
complete
all
of
this,
if
not
in
one
place,
but
then
in
a
way
that
is
very
well
connected
and
is
intuitive
and
then
also
and
will
be
the
case.
I
think
for
many
of
our
many
parts
of
our
product,
especially,
is
the
case
in
ops.
B
For
example,
we
could
move
prometheus
into
metric
settings,
for
example,
but
it's
not
so
easy
because
we're
not
the
only
ones
who
need
prometheus.
So
if
you
talk
to
monitor
health
they're
working
on
alerting
capabilities-
and
they
also
use
prometheus,
for
example-
so
definitely
we
don't
want
to
just
hide
it
in
metric
settings.
So
there
needs
to
be
some
way
to
kind
of
connect
it
all
together,
and
I
will
find
an
issue
for
this
I'll
just
have
to
like
go
digging
for
it,
but
I'll
link
it
in
our
agenda.
B
There
is
an
issue
where
maybe
oh
you've
probably
seen
but
there's
an
issue
where
we've
been
exploring
a
new
navigation
for
ops
for
operations
and
one
of
the
things
that
we've
been
considering
was
having
having
a
link
to
configuration
for
each
section.
So,
like
operations
configuration
so
now,
instead
of
having
to
go
to
settings
integrations
prometheus,
for
example,
would
live
under
operations.
Configuration.
B
It
it's
like
it
was
just
an
idea,
but
just
so
you
can't
understand
the
direction
that
that
we've
been
thinking
yeah,
like
whatever
we
can
do
to
bring
configuration
and
settings
closer
to
the
actual
relevant
product.
I
think
the
better
it
would
be-
and
it
looks
like
our
research
is
also
showing
this
but
yeah.
We
we
haven't
done
a
lot
of
work
around
this.
Yet
okay,.
A
That
was
going
to
be
my
next
question.
If
you
have
done
any
validation
that
touched
settings
and
if
you
had
any
specific
user
insights
that
we
could
use
to
solve
this
problem
of
discoverability
and
also
this
mix
and
switch
between
global
settings
and
settings
in
context
with
the
features
and
specific
pages.
B
Yeah,
so
I
will,
I
settings
came
up
once
or
twice
in
I
don't
remember:
either
problem
validation
or
solution,
validation
or
both
I'll
need
to
go
through
some
of
our
research
issues
and
look
at
the
insights
that
I've
documented.
B
If
I
can
find
something,
I
will
let
you
know
so
I'll.
Do
that
and
also
I
will
find
this
issue
for
operations
navigation
structure,
because
there
we
also
had
some
discussions
like
relevant
discussions
around
settings.
That's.
A
Awesome
that
would
be
super
cool,
because
my
immediate
goal
here
is
to
find
the
commonalities
between
the
the.
A
Designers
mentioned
in
specific
areas,
because
when
we
looked
into
the
previous
research
that
catherine
conducted
a
year
ago
and
also
the
recent
interviews
for
the
for
navigation,
there's
also
a
topic
on
settings,
the
teams,
they
are
still
the
same
from
issues
we
had.
You
know
discovered
like
a
year
ago.
It's
the
discoverability
of
settings.
It's
the
general
settings
versus
feature
settings,
it's
the
switch
of
the
phone.
A
What
you
mentioned
options
overload
when
you
land
somewhere,
and
then
you
need
context
from
documentation
to
understand
what
she's
setting
up
and
also
inconsistency
in
the
ui
and
I've
talked
to.
I
don't
know
I
think,
five
six
designers
so
far
and
it's
the
same
teams.
Everyone
has
the
same
issues
with
settings
in
their
own
stage
groups.
So
if
you
can
find
those
issues
later
on,
that'll
be
super
cool
and
then
you
feel
free
to
either
add
here
to
the
agenda
or
to
the
to
the
epic.
A
You
can
open
a
trend
there,
okay
and
then
anything
exciting
anything
that
you
worked
in
settings
before,
gitlab,
that
it
makes
you
proud,
or
that
you
think
it
was
a
it's
a
good
pattern
that
we
can
reuse
and
learnings.
B
Well,
I
haven't
really
done
any
work,
probably
around
settings
aside
from
those
discussions
that
I've
I
mentioned,
but
I
have
to
say
I'm
pretty
proud
of
putting
that
settings
button
on
the
matrix
dashboard
because
it
made
it.
It
was
such
a
tiny
fix
and
it
made
it
so
much
easier
and
it
was
important
for
us
to
make
it
also
more
discoverable,
as
we
started
introducing
some
like
customizations
for
the
dashboard
yeah
and
just
in
general.
B
I
I
think
it's
important
that,
while
we're
looking
at
these
bigger
things
are
addressing
kind
of
the
core
of
the
problem,
you
know
real
solutions
to
the
problem.
I
think
there's
also
something
to
be
said
about
some
little
things
that
we
can
do
like
each
stage
can
do
to
try
and
see
what
mvcs
are
possible
to
make
it
easier
for
their
users
to
access
settings,
because,
while
we're
fixing
the
problem,
I
imagine
it
can
take
quite
some
time.
Obviously,
it's
a
really
big
change
like
making
a
change
like
this.
B
It's
not
so
easy.
You
need
to
do
lots
of
research
and
test
different
different
options,
and
you
know
it
has
to
be
really
carefully
considered.
But
then
there
are
things
that
we
can
do
individually
like
as
different
stages,
some
things
that
are
maybe
less
invasive
and
less
risky.
A
I
agree
with
you
and
I'm
gonna
share
my
screen
here.
So
when
I
was
organizing
the
main
epic
here
for
settings,
I
broke
it
down
into
mainly
three
buckets
so
bugs
features
and
re-architecture
or
redesign
redesigned
before.
But
people
were
a
bit
scared
with
that
term,
so
bugs
are
pretty
much
upset,
ui
polish
or
things
that
should
work,
that
they
don't
work
right
now
that
anyone
anyone
could
just
go
ahead
and
fix
them.
B
A
Don't
need
to
tell
to
create
a
proposal
then
features
it's
like
I
don't
know,
search
for
settings,
you
know
imagination
and
some
some
cases
etc
and
then
re-architecturally
design
it
in
this
bigger
conversation
to
remove
settings
from
you
know,
general
settings
to
feature
features
centered.
A
How
do
we
look
into
the
shortcuts
for
settings?
How
do
we
communicate
to
users
that
in
their
flow
once
they
finish
the
prometheus
configuration,
for
example?
They
need
to
go
somewhere
else,
probably
tell
them
you
are.
We
need
to
go
so
I
created
this
three
main
epics
here
and
I
think
the
one
you
mentioned
right
now.
It's
really
about
this
one,
the
bugs
which
are
I'm
calling
them
the
low
hanging
fruits.
A
These
are
the
quick
winners
that
they
are
not
assigned
to
any
stage
group
because
settings
to
this
point
it's
not
owned
by
anyone
but
then
again
yeah.
I
think
it's
really
a
conversation
that
we
need
to
have
at
rpms
and
make
a
push
to
just
the
same
thing
same
way,
we're
doing
with
the
pajamas
components
or
that
we
did
with
the
white
college
effort
a
couple
of
months
ago
do
with
settings
so
that
we
can
fix
the
inconsistencies
and
then,
in
the
meantime,
in
parallel
have
a
conversation
about.
A
How
do
you
want
to
you
know,
tackle
the
big
plan
of
understanding
so
feel
free
to
look
into
this.
This
epic,
now
that
you're
moving
to
me
I'll,
have
to
no
one
is
going
to
replace
you
right
in
one.
B
So
emilia
amelia
will
be
taking
over
all
apm
stuff.
So
basically,
everything
in
pm
is
now
owned
by
health,
or
rather
they
are.
They
are
the
monitor
now,
there's
no
more
apm
but
feel
free
to
also
ping
me,
because
I've
been
working
on
metrix
dashboards
for
the
past
half
year
at
least
exclusively
and
amelia
hasn't
really
done
much
work
on
it,
she's
been
focusing
on
incidents
and
alerting
so
yeah,
probably
still,
I
know
the
most
but
she'll
catch
up
soon.
So
then
she
will
be
our
contact
awesome.
Just
because
you.
A
Know
then
I'll
try
to
schedule
a
call
with
her
as
well.
So
I
think
that's
about
it.
So
if
you're,
I'm
gonna
just
drop
it
here,
but
also
at
the
agenda
box.
What.
A
Yeah
be
sure
to
have
a
look
and
add
any
issues
that
you
might
have
and
do
you
have
a
kind
of
sidebar
here?
Do
you
have
any
expectations
for
sightings
in
nci
cd?
You
can
verify
because
you're
not
sure
if
you
had
a
chance
to
think
about
that
so
far,
but
any
experience
there
that
you
might
think
this
is
interesting,
or
this
is
painful.
B
Honestly,
this
change
was
so
sudden
and
so
quick,
I'm
still
kind
of
shocked,
but
not
not
necessarily
in
a
bad
way.
It
was
just
very
unexpected,
but,
like
I'm,
super
excited
to
be
joining
ci.
Obviously
it's
a
very
it's
very
exciting
part
of
the
product
to
contribute
to,
and
also
it's
a
whole
different
set
of
challenges
compared
to
what
I've
been
working
on
with
metrics,
because
metrics
are
still
quite
early.
B
You
know
it's
still
a
baby
in
in
their
in
their
life
cycle,
so
the
challenges
that
we've
been
you
know
mostly
we've
been
introducing
new
features
and
really
focusing
on
mvcs
and
kind
of
on
the
breadth
of
the
functionality
that
we're
providing
and
it
looks
like
in
ci.
The
the
problems
are
getting
much
more
sophisticated
and
complex,
which
I
I
expect
it
to
be
a
challenge,
but
also
a
very
exciting
challenge
to
to
attack
those
kinds
of
ux
problems.
That's
awesome.
A
A
A
Right
now,
and
that
we
can
have
a
conversation,
because
another
point
I'll
quickly
want
to
touch
on
is
pajamas
and
the
lack
of
guidelines
on
general
patterns,
for
example,
on
the
the
expand
collapse
navigate
on
settings
is
very
specific
to
the
settings
page
right
and
I
have
some
conversations
with
other
designers
where
they
say
that
they
would
like
to
have
more
more
guidance
from
pajamas,
as
in
ui,
not
ui
components,
but
views
for
okay.
A
This
is
how
settings
look
like,
so
this
is
how
we
could
extend,
or
continue
in
a
smart
group
or
in
our
context,
but
also
written
guidelines
about
how
it
works
and
how
it
should
be
replicated.
A
B
Yeah,
it's
it's
hard
to
say
off
the
top
of
my
head,
but
I'll
keep
that
in
mind
I'll
keep
thinking
about
it.
I
think
what
you
mentioned.
B
Definitely
it's
it's
a
big
problem,
so
lack
of
such
guidelines
leads
to
a
lot
of
inconsistency,
because
all
the
different
stages
are
free
to
interpret
the
guidelines
that
we
do
have,
and
it
just
keeps
diverging
like
no
matter
how
much
we
try
to
stay
in
touch,
for
example
in
in
metrics
we're
building
dashboards,
and
then
we
also
have
github
analytics
and
there
they
also
have
dashboards
and
they
are
so
different
and
the
way
like
it
really
diverged,
even
even
though
they're
so
related.
B
So
you
think
that
it
would
be
easier
to
you
know,
keep
it
more
consistent,
but
yeah,
I
think,
having
those
kinds
of
higher
level
guidelines
would
really
help
with
that
and
goes
beyond
settings
of
course.
But
it's
just
a
very
good
example.
In
this
case,
yeah.
A
A
So
it's
definitely
a
challenge
to
make
the
decisions
based
on
and
also
for
settings
make
the
decisions
based
on
what
the
product
currently
has,
which
could
be
either
a
new
feature
that
was
validated
you
know
got
to
went
through
the
whole
validation
process
or
legacy.
So
sometimes
it's
difficult
to
see
and
to
determine
if
I'm
replicating
an
outdated
pattern,
and
it
doesn't
really
shouldn't
really
exist
anymore
in
the
product.
B
A
Or
the
topics
that
I've
heard
from
other
designers
that
it
would
be
nice
to
know
that
okay,
this
is
how
you
set
up
something
in
the
class
or
this
is
how
you
set
up
functionality
in
both
the
ci
file
plus
the
ui
right.
I'm
not
sure
if
you
have
this
in
monitor,
but
in
ci
cd
there's
a
lot
of
things
that
we
configure
on
the
ymo
and
then
you
go
to
the
settings
that
is
hitting
somewhere
to
actually
turn
the
feature
on.
B
Yeah
we,
we
have
a
very
similar
situation
in
metrics,
but
we
haven't
quite
reached
the
point
where
we
diverged
from
the
yaml
file.
Still
like
pretty
much.
Everything
is
done
in
a
yaml
file,
so
I
I
foresee
the
same
problem
for
sure
it's
just
due
to
our
maturity
level.
We
haven't
quite
reached
the
critical
point,
but
I
think
we
will
be
having
the
same
problem
with
metrics.
B
Well,
it's
it's
good,
it's
good,
because
it
means
you're,
not
the
only
one
who's
concerned
about
it.
The
more
the
more
parts
of
github
are
concerned
about
it,
the
higher
the
chance
we
will
actually
follow
it.
That's.
A
Awesome
cool,
so
I
don't
have
any
on
what
are
asked
any
questions.
Anything
else
that
you
think
might
be
interesting
could
be
added
to
the
conversation.
B
No
not
at
this
point,
but
I
added
a
task
for
myself
to
go
through
the
issues
again
and
go
through
the
research
inside,
so
whatever
I
can
find.
I
will
make
sure
to
what
is
the
best
way
to
link
it
here
or
just
send
your
links
to
slack.
A
A
Awesome
because
I
spoke
with
katherine
last
friday
and
she
pointed
me
to
a
lot
of
researching
sites
on
like
broad
settings
or
research,
but
it's
like
this
in
context
with
the
stage
group.
It's
something
that
I
haven't
really
seen
yet.
A
I
know
the
things
that
I've
done
in
the
past,
but
it
would
be
nice
to
in
a
couple
of
weeks
or
days
any
days
just
group,
these
insights,
to
see
how
they
replicate
and
that
we
don't
really
have
to
redo
a
lot
of
research
on
this
topic,
because
we
know
the
problem
exists.
Right.
We've
seen
that
we
are
users,
so
we
know
that
there
is
a
room
for
improvement
here.
So
my
goal
is
to
find
these
commonalities
and
then
put
them
in
separate
buckets
yeah
make
sense
yeah.
Then
we
can
decide.