►
From YouTube: [REC] UX Key Review (Public Stream) 2021-08-17
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everybody,
let's
see
all
right,
hi
everybody
welcome
to
the
ux
key
review
for
august.
Just
a
reminder:
please
don't
mention
any
customers
and
then
also
a
reminder
to
everyone
not
to
present.
A
I
think
we
just
go
ahead
and
jump
to
number
four
here,
which
was
an
update
from
me
from
the
last
key
review
around
sid's
question.
Around
navigation.
Y'all
can
read
it
for
yourself,
that's
it.
It
looks
like
you
have
a
comment.
B
A
Yeah,
so
it
does,
it
takes
what
is
currently
in
the
sub
navigation
and
moves
it
into
the
main
content
area.
Now,
where
we
felt
like
this
was
a
good
intersection
with
your
request
is
that
it
does
get
settings
and
analytics
available
within
the
the
the
product
area
to
which
it's
related
and
also
we'll
we'll
still
have
a
separate
settings
section,
because
what
we've
heard
in
research
is
users
are
interested
in
finding
settings
both
ways.
B
It's
not
necessarily
against
it.
I
don't
I
don't
know
what
is
better
for
users,
but
I
don't.
I
just
don't
see
how
the
two
are
related.
It
basically
means
hey
we're
gonna,
remove
one
level
from
the
left
menu
and
add
that
on
top
okay,
the
left
menu
stays
more
constant,
that's
great
and
then
the
the
page,
I'm
looking
at,
gets
more
cluttered.
So
it's
like
could
be
good
could
be
bad,
but
it's
I
don't.
I
think
it's
changing
something.
Fundamentally,
my
the
proposal
I
made
said
hey.
B
A
I
will
give
you
information,
but
we
are
still
exploring
this,
so
please
don't
think
my
information
means
we
know
100
either,
and
you
may
have
more
questions
as
I
give
you
more
information
as
well.
So
one
of
the
primary
complaints
we
hear
in
user
research
is
that
the
left
nav
is
too
cluttered
because
it's
so
cluttered
people
can't
find
things,
and
so
the
idea
being
if
we
can
make
that
simpler
and
move
those
submenu
items
over
and
then
also
order
them.
A
What
we
are
also
seeing
from
data
is
that
usually
two
to
three
of
the
sub
nav
items
get
90
or
95
of
the
traffic,
and
so
we
would
order
those
first
and
less
important
things
could
fall
to
the
end,
making
them
still
accessible,
but
just
not
so
in
your
face,
because
that's
the
feedback
that
we're
getting
is
yeah
you're,
giving
me
everything
you're,
giving
it
to
me
all
the
time.
I
don't.
I
don't
need
it
all
the
time
that
way
there
is.
A
This
may
or
may
not
address
part
of
what
you're
thinking
about
right
now
in
the
longer
term
exploration.
What
that
also
allows
us
to
do
is
move
into
a
model
potentially
which
we
need
to
do
user
research
on
this,
because
these
are.
These
are
big
changes
where
we
group
things
by
how
users
are
thinking
about
the
category,
so
you
can
see
we
can
group
things
into
build.
A
A
B
B
So
if
you
look
at
our
planning
tools
like
super
high
adoption,
like
eighty
percent,
if
you
look
at
create
super
high
adoption,
eighty
percent,
if
you
look
at
verify
super
high
adoption
like
eighty
percent,
if
you
look
at
release
like
drops
by
half,
we
look
at
everything
else
like
below
20,
and
I
couldn't.
I
couldn't
tell
that
by
kind
of
what
I
see
in
the
menu
in
gitlab
like
it
is
not
reflected.
B
So
if
people
are
complaining
about
the
clutter,
oh
it's,
I
would
love
for
us
to
make
sure
that
we
optimize
gitlab
for
the
average
user.
Now
that's
going
to
make
it
harder
for
some
of
these
new
categories
for
some
of
these
new
stages
to
succeed,
and
I
want
them
to
succeed.
So
that's
not
I'm
not
jumping
my
joy,
but
if
you
look
at
our
main,
like
repository
super
heavy
usage
issues,
super
heavy
usage
merger,
super
heavy
usages
requirements,
requirements
and
merge
requests.
The
difference
in
usage
is
probably
five
orders
of
magnitude.
B
B
Ci
cd,
great
ton
of
usage,
makes
sense,
security
and
compliance.
Okay,
well
big
revenue
driver.
So
maybe
there's
an
argument.
There
deployments
whoa
whoa
where
we're
going.
We
should
that's
kind
of
part
of
ci
cd.
Would
the
would
the
product
manager
of
deployments
want
it
here?
Yes,
is
it
in
our
future?
Yes,
am
I
pushing
the
team
every
day,
like
hey,
make
sure
that
release
appeals
to
operators?
Yes,.
B
B
A
And
that's
where
we
move
if
we
move
build
and
that's
where,
when
you
enter
the
product,
this
would
be
your
default
view.
You
would
see
repositories,
issues,
boards,
merge,
requests
and
ci
cd,
which
are
our
highest
usage
items
and
then
other
things
become
less
pronounced
and
you
can
get
a
sense
of
what's
in
them,
but
you
don't
have
to
see
everything
that's
in
them,
unless
you
want
to,
in
which
case
you
can
expand
it.
Does
that
start
to
address
what
you're
thinking
about.
B
I
think
I
think
we're
on
the
same
page.
I
don't
I
don't
like
this
implementation,
but
I
think
we
have
the
same
goal
like
hey.
Let's
not,
let's
make
sure
that
the
stuff
that's
relevant
to
people
is
there
and
we
got
this
super
hard
problem
where
we're
catering
to
three
four
different,
very
different
audiences,
like
devsec,
ops
and
biz.
B
So
that's
that's
super
hard
and
I
don't
expect
to
solve
it
in
this
call.
But
I'd
love
us
to
to
do
smaller
iterations.
This
is
not
the
first
time
I
mentioned
requirements
as
as
having
a
very
different
usage
profile
and
the
rest,
and
we
spent
months
and
and
nothing
nothing
changed.
B
So
I
think
we
we
need
to
iterate
more,
and
I
love
that
I
had
that
that
that
concept
it
has
the
right
idea,
but
we
can
do
stuff
today,
where
we
say:
hey
we're
just
going
to
combine
the
deployments
and
infrastructure
because
it's
pretty
similar
and
it
would
have
about
as
many
submenus.
Now
I
don't
know,
that's
the
right
quote.
They
do
know
that
putting
requirements
under
a
submenu
could
clean
up
a
little
bit
of
clutter
and
considering
the
usage
it
will
be.
B
A
Yeah
one
of
the
things
that
we're
finding
is
even
tiny
iterations
are
apparently
a
really
large
technical,
lift.
So
there's
an
example
of
that
in
the
agenda.
B
I
read
through
that,
but
I
think
that's
that's
really
worthwhile
work
and
it's
hard
and
so
be
it.
I
think
if
I
phrase
it,
let's
make
sure
I
understood
it
right.
It's
like
hey.
We
wanted
all
the
settings
relevant
to
mertocrats,
want
to
bundle
them
and
it's
like
that's
super
hard
to
do
because
they're
all
over
the
place.
Well,
that's
good
that
we're
we're
trying
to
do
that
and
I'll
be
patient,
and
I
think
that's
okay,
I
think,
like
I
don't
know,
indenting
requirements
below
the
most
relevant
main
menu
like
that.
A
A
We
are
really
trying
to
hone
in
on
what
is
it
that
our
users
want
from
this,
because
this
is
a
big
pain
point
that
we're
hearing
about.
So
we
can
make
small
iterative
changes
like
the
fixing
the
merge
requests
problem,
but
we
think
that
overall,
larger
changes
are
needed
and
so,
for
example,
moving
settings
and
analytics
as
sub
items.
That,
in
and
of
itself
is
a
huge
change.
So,
if
we're
talking
about
these
big
changes
that
we're
trying
to
track
towards,
we
want
to
make
sure
that
we
are.
A
We've
got
a
good
long-term
vision
that
we're
shooting
at
now
the
last
wireframe
that
I
just
showed.
We
need
to
get
that
through
user
research.
We
don't
know
yet.
Just
like
you,
you
said
you
don't
know
whether
or
not
that's
the
right
forward
direction.
We
would
need
to
do
a
lot
of
user
research
on
this
navigation
is
not
something
that
we
can
take
lightly.
B
Or
look,
I
think,
big
navigation
changes
require
big,
a
lot
of
research
and
in
the
heart
I'm
not
I've.
Seen
a
few,
the
bundling,
I
see
the
moving
et
cetera.
B
B
I
think
we
have
to
be
more
strict
of
of
the
amount
of
users
and
when
I
first
mentioned
requirements
like
months
ago,
it
was
like
yeah,
we
did
user
research
for
the
users
who
used
requirements.
They
thought
it
should
be
in
the
top
menu.
Yes,
yes,
I
betcha,
but
we
should
incorporate
how
many
users
something
has,
and
if
our
average
user
is
telling
us
it's
decluttered,
that
is
a
way
to
get
there
and
yes,
it
will
be
at
an
inconvenience
for
those
requirements,
users,
it's
a
couple
of
hundred.
B
I
can
personally
apologize
to
each
and
every
one
of
them.
If
that's
needed,
we
gotta
optimize
for
the
average
user
experience
because
we
got
to
get
so.
A
Agreed
we
do.
What
I
want
to
do
is
take
this.
Thank
you
for
sharing
I'm
going
to
share
this
recording
with
marcel
he's,
going
to
put
together
a
recording
about
what
we
know
from
user
research.
Let
me
get
him
to
respond
just
because
he's
much
closer
to
the
things
that
we've
learned,
but
but
he
can
base
it
on
this
conversation.
Also
that
we've
had
right
here,
so
he
can.
He
can
make
sure
that
he's
considering
your
points
for
requirements
using
it
as
an
example.
C
D
Yeah
we
have
a
region
for
navigation
in
pajamas,
so
adding
guidance
for
product
teams
to
be
able
to
reference
just
to
determine
whether
or
not
it
makes
sense
to
add
a
high
level
navigation
item.
I
anticipate
some
pushback
from
product
because,
like
you
said,
everyone
wants
to
get
their
product
area
out
there
and
the
more
visible
it
is
the
more
likely
it'll
be
adopted,
but
we
do
need
some
guidelines
in
place
so
that
we
can
reduce
the
clutter
so
we're
working
on
that
foundations.
E
Is
about
where
we
have?
We
have
to
sort
of
advocate
standardizations,
and
so
that's
a
long-term
people
fix,
but
even
right
now
like
if
we
create
an
issue
and
say,
let's
move
requirements
out,
let's
just
see
if
the
plan
team
can
look
at
it
and
remove
it,
that's
if
one
out
of
ten
items
get
out
of
the
left
nav,
that's
a
10
reduction
in
clutter.
In
my
opinion,.
B
That's
awesome
thanks
anub,
and
I
think
it's
got
to
be
very
clear.
This
is
not
about
the
individual
product
manager
is
not
going
to
decide
on
the
global
navigation
that
has
to
happen
at
the
global
level
and
product
has-
and
in
fact
I
think,
I'm
not
sure,
but
I
think
ux
kind
of
decides
on
that.
Maybe
somebody
else.
But
yes,
if,
if
I
was
doing
something
like
I
would
every
product
manager,
if
they're,
if
they're
good
at
their
job,
should
advocate
that
it
should
be
in
the
main
menu.
B
But
that
doesn't
mean
we
have
tens
and
tons
of
product
managers.
So
it's
not
up
to
them,
and
I
was
exaggerating
a
little
bit
about
the
five
orders
of
magnitude
or
four,
but
it's
three
orders
of
magnitude.
So
this
is
the
number
of
requirements
interactions
that
we
record.
It
was
117
in
july,
and
this
is
what
we
see
for
the
the
menu
item.
Above
it
merge
requests.
It
was
1.3
million
in
july.
E
And
just
to
just
to
clarify
right,
I
think
we
are
painting
a
broader
brush.
If
we
have
user
informed
research,
you
will
not
see
product
managers
push
back
to
right
because
they
also
want
us
to
solve
for
the
same
problem.
Yes,
they
want
to.
They
want
to
have
a
growth
hack,
so
they
might
advocate
for
having
their
thing
in
the
menu
for
the
early
days.
So
they
can
get
some
feedback,
but
that's
totally
different
than
all
pms
should
understand.
If
they
don't
make
sure
that
they
do
that
they
can't
grow.
E
A
You
said
something
interesting
that
my
team
has
discussed,
but
we
wouldn't
we
weren't
sure
how
much
openness
there
would
be
to
it
based
on
our
company
culture,
but
around
ux,
owning
what's
in
the
nav,
where
we've
been
hesitant
to
put
up
firm
guardrails
is
that
I
know
we
try
really
hard
not
to
block
teams,
but
at
the
same
time,
what
you're
getting
at
is
navigation
is
really
really
important.
Is
it
the
crux
of
our
user
experience?
B
Top
left
nest
being
under
ux
makes
sense
to
me,
okay,
but
it's
there's
a
extreme
amount
of
difference
between
navigation
and
top
left
nav
menu.
There's
there's
like
this
is
one
percent,
and
this
is
like
that.
There's
every
piece
of
functionality
has
to
end
up
in
our
navigation.
So,
let's
make
sure
we
focus
on
the
right
thing,
but
that
ux
decides
what
goes
in.
The
left
makes
sense
like
in
fact,
if
you're
not
cleaning
this
up,
I'm
gonna
clean
it
up
because
it
has
taken
too
long
and
it's
it's
hurting
our
users.
B
E
The
other
thing
is,
we
are
forming
a
foundations
team
and
there
will
be
a
pm
in
the
foundations
team
as
well,
so
that
once
I
think
that
the
home
for
top
left
nav
decisions
is
the
foundation's
team
and
I
wouldn't
and
for
now
I
think,
that's
fine
make
the
change
have
ui
on
the
left
now.
But
I
think
once
the
pm
for
the
foundations
team
is
there,
then
that
team
needs
to
own
it
yeah
and
it's
top
left.
B
Sorry
top
is
a
confusing
word
main
main
left,
math
name.
A
A
new
we'll
have
to
work
with
you
on
this.
I
think
my
team
can't
spin
up
an
mr
around
this
and
then
there's
also
some
design
work
to
be
done
around.
A
A
A
B
Yeah,
so
the
the
score
kind
of
went
sideways
went
a
little
bit
better,
but
basically
at
a
much
lower
level
than
it
it
it
used
to
be
or
a
lower
level
than
it
used
to
be.
I
thought
that
so
getlab.com
has
the
uptime
has
not
been
fantastic,
but
but
the
speed
has
much
much
improved
and
I
thought
that
was
hurting
ourselves
as
well.
So
as
we
got
a
lot
better
at
that,
I
expect
hope
for
us
to
pick
up
a
bit.
B
A
No,
I
mean
we
were
hoping
for
the
same
thing,
so
I
don't
think
it
was
like
a
weird
thing
to
hope
for
so
we
wanted
to
that
probably
played
somewhat
into
the
stabilization
that
we
saw,
but
there's
no
way
for
us
to
know
with
certainty.
A
What
we
think
may
be
happening
is
part
of
the
reason
why
we've
seen
this
downward
trend
is
not
necessarily
because
the
usability
of
our
product
has
actually
gotten
worse.
It's
because
we
have
so
many
more
new
users
in
the
product
and
new
users
struggle
so
much
more
with
the
usability
of
our
product
than
more
mature
users.
Adam
did
a
ton
of
research
around
this,
including
a
qualitative
study
to
follow
up
on
the
sus
adam.
Do
you
want
to
speak
to
this
a
little
bit.
C
Yeah,
what
we
found
was
really
around
that
last
question:
question
10
in
the
sus,
where
it's
about
learning
git
lab
and
that
has
consistently
been
a
score
within
that
one
question:
that's
been
dragging
us
down
for
the
interruption.
I've
seen.
A
A
Yeah,
adam
adam
will
have
to
go
back
and
dig
in
and
take
a
look
at
that.
I
think
we've
looked
at
it
before,
but
I
don't.
I
don't
want
to
tell
you
for
sure,
but
we're
kind
of
at
the
same
place.
You
are
sid,
which
is
we're
making
changes
based
on
the
feedback
that
we're
getting
we're,
hoping
and
expecting
things
to
start
ticking
up
and
they're.
Just
not
yet
we're
heartened
that
at
least
they're
not
going
down
anymore,
but
I
also
can't
tell
you
that
next
quarter,
it
won't
go
down
again
right.