►
From YouTube: Settings UX - Learnings and recommendations
Description
Learnings and recommendations from conversations about Settings with our team of designers
- https://gitlab.com/gitlab-org/gitlab-design/-/issues/1363
- https://gitlab.com/groups/gitlab-org/-/epics/3535
A
Hi,
I'm
hayano
pedissimo,
I'm
a
senior
product
designer
for
the
release
management
group
here
at
gitlab,
and
today
I
want
to
talk
to
you
a
little
bit
about
the
state
of
user
experience
for
settings
at
gitlab.
What
we
learned
from
our
design
stakeholders
and
discuss
some
of
the
opportunities
to
address
the
pain
points
of
our
users
as
well
as
of
our
design.
Team
settings
have
been
a
persistent
issue
reported
by
our
customers
over
the
last
couple
of
years.
We
know
that
the
target
audience
for
setting
is
very
broad.
A
A
When
we
look
back
at
existing
user
research
in
sites,
we
find
multiple
references
to
issues
and
features
improvements
that
relate
to
settings.
A
very
good
example
is
this
admin
project
setting
survey
conducted
by
kathleen
around
a
year
ago
in
the
past
mate
also
did
a
great
job
validating
the
redesign
of
the
settings
pages.
A
Our
plan
was
divided
in
five
steps:
the
first
one
by
evaluating
the
existing
ux
issues
related
to
settings
and
defining
low-hanging
fruits,
doing
some
discovery
by
speaking
with
individual
stage
groups,
to
figure
what
were
the
visual
items
and
upcoming
settings
requirements
and
then
identify
the
arising
counterparts.
So
we
reach
out
to
design
teams
and
identify
people
that
can
help
us
and
share
responsibility
with
them.
A
And
next
we
want
to
set
up
some
meetings
and
define
some
goals
and
the
overall
vision
for
settings.
In
the
first
step,
the
evaluation
we
came
across
some
very
well
defined
teams
or
areas
to
focus
on
settings.
The
first
one
is
discoverability
of
settings.
This
is
mainly
related
to
the
navigation
and
the
ability
to
find
settings
items
using
the
search
bar.
A
There
is
also
the
global
versus
feature
settings
mix
where
users
don't
know
where
they
should
look
for
settings,
so
the
switch
of
navigational
flow
makes
it
difficult
for
many
to
fully
enable
and
configure
a
certain
feature.
They
need
to
jump
from
one
section
of
settings
to
another
to
a
feature
page
and
so
on.
There's
also
an
issue
with
the
options
overload,
so
more
roles
and
personas
that
user
product
means
that
number
of
settings
and
different
features
will
increase
and
also
ui
consistency.
So
the
patterns
that
we
use
today
are
inconsistent
across
the
product.
A
Our
first
step,
when
evaluating
a
sateen's
ux
issue,
was
to
spot
some
of
the
lohini
fruits
that
could
potentially
serve
as
a
backlog
of
quick
wins.
So
I
mapped
out
issues
and
assigned
them
to
team
epics,
so
the
first
one
was
one
related
to
bugs.
So
those
are
issues
that
I
consider
ready
for
development.
A
They
are
issues
that
report
undesirable
and
correct
behavior,
so
these
don't
really
require
any
validation.
We
know
how
they
should
work
and
we
just
need
to
fix
them.
Features
are
things
that
yeah
they're
feature
requests.
They
might
require
validation
and,
most
of
the
time
they
need
to
be
assigned
to
a
specific
stage
group.
So
they
belong
to
someone.
A
They
belong
to
settings
in
a
specific
context
and
the
third
one
is
settings
re-architecture
or
redesign.
So
those
are
bigger
changes
involved,
involving
ui
and
also
ux
enhancements.
They
touch
multiple
pages
and
they
touch
things
that
scatter
across
the
product.
Those
might
require
validation
in
the
box
of
epic.
I
identify
43
improvements
that
we
believe
are
shovel
ready,
and
then
I
refine
this
list
with
12
items
that
I
believe
were
the
super
super
low-hanging
fruits
that
designers
could
tackle.
These
involve
mostly
uf
ux
that
bugs
and
white
polish.
A
A
lesson
learned
here
is
that
simply
listing
this
problem
and
pinging
people
was
not
enough.
The
main
challenge
is
that
since
settings,
it
still
under
group
not
owned.
These
cross
vertical
issues
were
very
difficult
to
prioritize,
so
the
bystander
effect
persisted
only
five
issues
from
this
list
received
some
update
or
some
attention
from
product,
but
none
of
them
were
prioritized
or
scheduled.
A
I
also
talked
to
katherine
ux
researcher
for
create
who
shared
some
of
her
hands.
First
experience:
when
conducting
research
for
settings,
you
can
watch
all
the
recordings
in
the
conversations
on
the
filter.
The
inside
share
bar
teams
of
designers
were
not
so
different
from
the
actionable
insights
collected
from
the
navigation
system.
Usability
questionnaire
that
katherine
tackled
just
recently.
A
During
these
interviews,
we
had
a
chance
to
touch
base
on
some
of
the
topics
of
interest
per
stage
group.
The
main
challenge
for
designers
when
thinking
of
settings
was
first
defining
a
target
audience.
We
know.
As
I
said,
the
settings
has
a
broader
target
audience,
for
example,
in
release
orchestration.
A
We
have
many
jobs
to
be
done
that
tackle
and
they
cater
to
a
mix
of
personas.
We
want
to
give
customers,
for
example,
the
ability
to
see
and
manage
apply
freezes.
We
need
to
consider
that
some
of
these
tasks
are
performed
by
release
managers
that
are
not
really
dev
oriented,
but
we
also
have
devops
engineers
responsible
for
release
management
tasks.
So
we
want
the
ui
experience
for
settings
to
be
as
seamless
as
the
api
experience
without
adding
any
conflict
to
all
these
different
personas.
A
Some
of
the
challenge
mentioned
were
related
to
the
lack
of
standardized
ui
elements
in
patterns
which
leads
to
inconsistent
designs
that
we
know
today,
for
example,
there's
a
mix
of
toggles
and
radio
buttons
in
multiple
places
in
the
ui.
Also
in
some
areas
of
settings
you
save
an
item
by
clicking
the
save
button,
while
in
the
same
page
you
have
a
different
area
of
the
the
form
that
works
with
autosave,
so
we
need
to
get
better
at
defining
these
patterns
and
also
applying
them
correctly
in
the
product.
A
Also,
the
poor
visual
aspect
and
interaction
design
was
a
recurring
issue.
One
of
the
main
issues
relates
to
the
expand
and
collapse
areas
of
settings
which
makes
it
difficult
to
access
certain
parts
of
the
product.
The
ui
text
was
also
mentioned.
Designers
say
that
it
can
be
very
verbose
and
not
so
helpful.
A
A
A
next
super
interesting
item
was
contextual
settings.
The
cost
of
context
shifting
for
settings
means
that
users
are
spending
extra
time
to
figure
out
where
to
find
the
correct
options
in
order
to
complete
their
tasks.
The
lack
of
context
is,
in
this
case,
an
anti-pattern.
This
relates
to
navigation
as
well.
Defining
context
when
it
comes
to
gitlab
can
be
a
huge
task,
but
discussing
how
contextual
settings
can
be
made
available
to
our
users
in
particular
situations
or
product
areas
can
help
shape
the
overall
interactions
of
such
a
complex
system.
A
Our
designers
agree
that
contextual
settings
are
going
to
be
very
important
in
the
future
and
that
we
want
to
build
relevant
customizers
experience
potentially
based
on
data.
So
some
of
the
recurring
challenges
relate
to
settings
at
the
group
level
that
cascade
to
a
project.
So
how
do
we
give
users
context
of?
What's
at
the
group
level
in
general?
Settings
are
hard
to
find
and
we
can
solve
that
by
bringing
settings
closer
to
the
team
they
affect,
for
example,
by
adding
entry
points
to
settings
in
the
feature
page,
you
verify
as
well.
A
Users
have
to
go
to
settings
to
install
a
runner.
The
instructions
give
you
an
url
for
an
instance
registration,
token
and
so
on,
and
you
need
this
specific
information
to
register
a
runner,
so
you
always
have
to
go
to
settings.
The
problem
is
that
part
of
this
process
is
in
a
separate
page
and
people
forget
that
the
registration
happens
many
times
in
a
different
product
area,
because
they
just
simply
don't
check
settings
information
architecture
is
another
super
broad
topic
that
mainly
focuses
on
navigation
today.
A
We
know
that
similar
to
navigation
setting
has
been
a
consistent
issue
in
gitlab.
Navigation
affects
the
understanding
of
the
product
and
how
users
are
able
to
complete
their
tasks.
The
reasoning
setting
in
general
deals
with
both
detail
and
non-detailed
focus
tasks.
That
means
that
when
it
comes
to
navigating
and
working
with,
gitlab
users
tend
to
manage
options
specific
to
the
test
they
want
to
complete,
but
also
looking
into
broader
general
settings.
A
We
need
to
understand
how
users
categorize
information
about
settings
and
also
where
they
expect
to
find
settings
in
gitlab.
Our
research
team
has
a
very
interesting
issue
that
covers
the
information
architecture
topic
and
that
which
overlaps
with
settings
ux.
We
also
bring
storms
some
ideas
for
how
we
can
make
it
easier
for
users
to
find
settings.
Information
in
our
docs
gitlab
is
a
very
technical
product,
but
we
cannot
expect
people
to
just
know
how
things
work
out
of
the
box.
A
A
Still
when
you
check
the
box,
you
need
time
to
figure
where
things
are,
so
we
can
do
a
couple
of
things
every
time
it's
about
sets
in
the
in
the
docs.
We
can
highlight
that
information
and
while
much
of
the
the
instructions
already
exist
in
the
ui
of
the
product,
we
can
get
better
at
helping
the
users
that
are
trying
to
complete
complex
tasks.
A
We
also
learned
that
designers
are
super
proud
of
some
of
the
work
related
to
settings
of
delivery
in
the
past
package
worked
on
container
registry
cloud
for
text,
leaving
a
very
human
and
approachable
ux
in
enablement.
Geosettings
ux
was
updated
just
a
few
months
ago
in
manage.
We
were
able
to
improve
a
couple
of
setting
screens
on
the
project
and
group
level.
Updating
section
labels
and
descriptions
that
help
with
usability
investigation
is
happening
to
define
whether
or
not
we
should
consider
adding
a
settings
area
specifically
for
secure.
A
We
also
learned
what
our
designers
are
going
to
be
working
next
today,
the
different
stage
groups
are
going
to
be
focused
on
settings
at
the
group
level
since
there's
a
very
strong
desire
to
bring
configuration
to
a
higher
level
across
the
product.
Release
management
package
verify
and
create
have
been
working
on.
This
team.
A
It's
an
interesting
item
tackled
by
growth
that
work
on
making
it
easier
to
get
an
overview
settings
related
to
the
instance
license
upgrade
to
a
higher
plane
and
etc.
Finally,
some
of
the
opportunities
for
pajamas
our
design
system.
We
can
provide
more
guidance
and
reuse
designers
want
the
out-of-the-box
ability
to
design
with
settings
by
reusing
white
elements,
layouts
as
well
make
use
of
documentation
and
settings
best
practice,
so
we're
going
to
open
a
couple
of
issues
around
documenting
how
settings
should
be
designed
and
that
will
be
available
in
pajamas.
A
We
also
want
to
define
guidelines
around
information
architecture,
for
example,
how
to
organize
information
settings.
How
not
to
do
it
and
provide
some
good
examples.
We
want
to
empower
designers
to
contribute
to
settings,
so
we
want
to
facilitate
the
conversation
between
stage
groups
in
a
workshop
like
what
growth
did
around
the
first
time
experience
in
gitlab,
and
we
want
to
collaborate
with
the
grow
team
since
now
they
own
navigation
as
a
category.
We
need
your
help
to
keep
this
initiative
moving
forward.
A
So
if
you
would
like
to
contribute,
please
look
into
the
main
settings,
ux
epic,
and
see
if
one
of
the
issues
that
are
listed
there
belong
to
your
stage
group
or
that
could
be
tackled
in
the
upcoming
milestone.
If
you're
a
designer,
you
can
work
with
your
product
manager
to
try
to
prioritize
these
issues
and
then
we
can
continue.
A
The
discussion
also
feel
free
to
drop
some
of
your
thoughts
and
some
of
your
upcoming
items
in
the
same
epic
and
join
a
conversation
in
the
f
settings,
slack
channel
and
finally,
collaborate
with
other
stage
groups
if
you're
designing
something
that
revolves
settings
at
the
group
level.
Please
share
this
experience.
If
you're
doing
investigation
and
validating
things
with
our
users,
let
us
know
what
works
and
what
doesn't
this
will
help
us
shape
the
vision
for
settings.