►
From YouTube: 2022-11-30 Product Analytics PM:UX Sync
Description
Weekly sync where the Product Analytics team discusses the latest UX developments, questions and ideas. In this week's call we talk about the MVC onboarding flow designs.
A
B
B
Open
question
we
had
previously
was
deciding
how
many
and
what
screens
we
wanted
for
product
analytics,
because
that
would
dictate
whether
we
needed
to
do
something
different
with
the
left.
Sidebar
versus
do
like
a
tabular
approach
or
something
else
so
I
was
wanting
to
discuss
today.
Do
we
know
what
all
the
screens
we're
going
to
need
for
both
the
internal
preview
and
have
some
idea
on
the
customer
preview
are
going
to
be
that
way.
B
C
So
you
know
we
can
go
at
the
top
of
their
approach,
but
that
seems
like
kind
of
like
a
short-term
solution
that
will
confuse
well,
especially
when
we
get
out
to
users
that'll,
only
confuse
it
further.
I
guess
sure.
My
recollection
of
this
is
like
we
were
trying
to
like
consider
like
if
other
groups
could
rename
their
sections
or
their
their
menu
groups
so
that
we
could
have
our
own
well.
B
So
I've
had
some
conversations
on
slack
and
it
seems
like
this
is
going
to
be
one
of
those
coordination
exercises.
That's
going
to
take
a
lot
of
time
just
to
get
people
on
the
same
page.
If
we
want
to
do
a
big
rearrangement,
which
is
fine,
we
can
do
that,
but
I
want
to
separate.
You
know
here's
the
big
project
we
have
to
do
versus.
We
need
to
have
something
in
the
left
sidebar,
so
you
can
actually
get
to
what
we
have
I.
B
B
D
D
And
I
hope
I'm
no
longer
robotic
because
identify
that
I
was
robotic.
That's
right,
yeah
is
the
instrumentation
settings
where
we
list
out
how
to
what
how
to
get
instrumentation
going
on
your
product
right
now.
We're
gonna
we're
planning
on
having
that
as
a
page
which
gets
linked
for
a
button
in
the
main
header
on
the
map
dashboards
listing.
But
at
some
point
we
may
want
to
keep
that
but
move
it
into
a
left-hand
menu
item
as
well.
So
that's
very
other
page
I
can
think
of
in
terms
of
additional
pages.
D
C
You're,
fine
I
guess
sorry
I
wish
I
should
have
read
the
issue,
but
I
don't
know
just
yeah
I'll.
It
just
seems
like
there's
a
lot
of
stuff
in
the
analytics
menu
group
right
now
that
needs
to
go
into
its
own
areas
like
Ci
CD
can
go
into
this.
We
would
literally
have
a
menu
group
or
citd
insights
could
probably
go
to
like
the
overview
or
like
the
top
level.
Like
the
first
menu
group
item.
I,
don't
remember
what
it's
called
right
now
like
it
seems.
C
C
Yeah
I
guess
once
we
have
a
list
of
screens
like
what
are
our
next
steps,
because
I
I
would
I
don't
know
if
it
makes
sense
for
us
to
just
like
be
like
hey,
we
need
to
do
that.
Coordinated
effort,
just
spread
everything
out
and
just
introduce
a
product
analytics
menu
group
at
this
point
which
I
think
we
already
have
right.
Don't
we
already
have
that.
B
And
we
can
take
some
time
if
we
want
to
think
about
this
list
of
four.
If
there's
any
others,
full
name
is
to
re-engage
with
the
some
of
the
ux
folks
on
the
issue,
because
the
feedback
was.
This
is
a
little
too
nebulous
to
be
actionable
right
now,
because
it's
currently
formed
in
terms
of
you
know
we're
going
to
have
several
screens.
But
it's
not
an
explicit
list
of.
B
In
terms
of
that
next
step,
I
was
going
to
plan
to
re-engage
with
the
people
on
this
issue.
About
that
specific
topic
and
and
Dennis
to
your
point,
I
do
agree
that
we're
likely
going
to
need
our
own
left
sidebar
option
with
more
of
these
screens
I'm
thinking
through
how
we
can
approach
this
iteratively,
though,
so
that
we're
not
going
to
block
our
whole.
Our
whole
capability
release
on
the
outcome
of
this
discussion,
because
I'm
expecting
this
will
probably
be
a
few
months,
especially
longer
with
the
holidays
and
everything
coming
up
versus.
B
C
D
D
Sorry,
not
a
new
Sub
menu
when
you,
when
you're
in
a
project
under
project
information,
you
could
have
it
if
you
wanted,
because
it
is
relatable
to
that
in
some
way,
repository,
probably
a
no-go
issues
no-go
so
I
mean
you've,
overgun
analytics
or
projected
the
project
information
tab.
That's
the
only
two
I
could
think
of.
C
Yeah,
okay,
so
I
just
added
what
I
think
is
probably
coming
up
in
the
next
possible
year,
like
I,
don't
I,
don't
think
fitting
onto
an
existing
menu
group
makes
sense.
I
get
that
ux
research
that
compounds
their
work
but
I
feel
like.
We
also
complicate
that
you
that
confusion
for
users
by
inserting
ourselves
into
project
or
analytics
I,
would
rather-
and
you
know,
our
timing
for
customer
facing
stuff-
is
still
undetermined.
So
I
would.
Rather
we
push
try
to
push
forward
with
hey
we're
going
to
have
a
product
analytics
menu
group.
C
So,
like
we
have,
time
is
I,
guess
more
or
less
what
I'm
trying
to
say.
At
the
same
time,
we've
already
got
what
eight
and
then
eventually
more
like
we
look
at
pricing
like
we've,
got
data
debugging,
a
b
testing,
cohorts
and
event
messaging
like
there's
going
to
be
a
lot
more,
so
I
think
the
right
thing
to
do
is
just
to
keep
pushing
forward
with
like
getting
our
own
menu
group
item
and
then
coordinating
the
efforts
to
separate
the
analytics
thing.
That's
my
feeling
on
it,
because.
B
C
Feel
like
if
we
go
sorry,
but
my
final
thought
on
that
is
like
if
we
go
under
analytics
and
then
we
go
customer
facing
and
we're
like,
hey
check
this
out
and
then
all
of
a
sudden
we
disappear
and
like
where.
Where
do
we?
Where,
where
do
our
features,
get
access
now,
I
would
rather
avoid
that
sorry
on
go
for.
A
It
yeah
I
just
wanted
to
add
a
big
plus
one
I
mean
it
makes
sense,
we're
going
to
be
behind
a
feature
flag
like
if
it's
not
enabled
No
One's
Gonna
See
It,
it's
going
to
be
an
awful
feature
flag
that
we're
selling
customers
not
to
enable
so
the
cost
is
pretty
low.
You
know
it's
a
it's
a
it's
a
cheap
like
thing
to
do.
C
I
I
would
say
so
I
I
get
that
it's
going
under
analytics
is
is
more
of
the
boring
solution.
Maybe
I
don't
know
I,
don't
I,
wouldn't
I,
wouldn't
even
agree
with
that.
It
is
the
one
with
least
effort,
but
it's
it's
just
like
this
has
always
been
a
sticking
point
in
terms
of
ux
debt
and
we're
just
only
adding
to
it
and
I.
Don't
see
us
until
we
do
I,
don't
know
it
just
seems
like
one
of
those
things
we
have
to
do
to
to
get
us
out
of
this
problem.
C
Otherwise
we're
going
to
keep
talking
about
this
for,
like
the
next
few
years,
with
all
these
other
groups
and
then
they're
going
to
add
their
own
features.
On
top
of
it,
and
it's
just
gonna
get
worse
like
I,
don't
I,
don't
think
I,
don't
think
it's
the
right
thing
to
do.
I,
don't
think
it's
the
most
iterative
thing,
but
I
think
we
can
iterate
towards
it,
but.
B
D
D
D
Sidebar
option
is
going
to
be
behind
the
default
feature
for
a
flag
off
we're
not
going
to
be
recommending
it
to
anyone
for
many
months
to
come,
etc,
etc,
etc,
as
yeah
I
agree
is
going
under
analytics
is
the
least
the
path
of
least
resistance,
we're
going
to
get
less
pushback
by
doing
it.
That
way,
but
I
agree
with
everyone
else's
point
state.
It
is
the
probably
the
most
least
ideal
way
of
doing
it.
If
we
can
get
the
left
side
bar
in
I
am
more
for
that,
especially
from
user
experience.
Point
of
view.
C
B
B
If
we
have
any
other
ideas
for
what
will
be
needed
from
a
screen
perspective,
let's
get
try
and
get
those
added
in
the
next
week,
or
so
so
that
we
can
put
a
timeline
on
this
as
well
as
a
proposal
on
how
did
those
screens,
where
did
they
live
either
on
this
left?
Sidebar
option
A
settings
page
whatever.
Basically,
so
we
have
a
proposal
to
review
with
foundations
where
we
can
go
from.
B
B
C
C
We
expect
to
represent
it
in
the
menu
is
which
effectively
just
two
levels
of
list
items
right
so
and
I
can
see
these
eventually
breaking
up
into
their
own
categories
as
well,
but
that's
a
different
conversation
and
I'll.
Why
don't
we
move
this
into
an
issue
as
well,
so
I'll
create
one
right
now,
yeah.
A
A
C
D
C
A
But
I'm
what
I'm
more
like
getting
at
is
I
wonder
if
foundations
it
wouldn't
be
easier
sell
if
we
gave
them
the
pages
that
we
know
we're
going
to
to
add
like
for
sure.
So
we
gave
them
like
a
list
of
three
or
four.
Then
it
looks
I
guess
more
like
they
would
maybe
be
more
comfortable
if
we're
more
comfortable
with
what
we're
suggesting.
If
that
makes
sense
like
we'll
give
comments.
C
Those
will
probably
exist
in
their
own
like
menu
item,
but
at
least
right
now,
I
just
want
to
kind
of
list
a
bunch
of
stuff
that
could
potentially
be
their
own
page
items
or
their
own
menu
items
so
that,
like
I,
don't
know
it's
just
say
like
I
guess
overestimating
how
much
we
can
have
so
that
we
don't
feel
as
boxed
in
when
we
do
have
other
features
that
should
exist
on
their
own.
If
that
makes
sense.
D
The
yeah,
the
argument,
the
reason
we
won
this
list
is
to
show
that
we
need
a
left
side
menu
item,
not
necessarily
that
the
what
goes
into
the
left
hand,
side
menu
item
matters
necessarily
they
just
need
to.
We
just
need
to
prove
that
what
that
we
will
need
sub
pages
to
go
on
here
and
I
kind
of
get
where
they're
coming
from
in
terms
of
menu.
D
One
of
the
biggest
complaints
we've
had
at
gitlab
from
a
UI
score
perspective
is
just
complexity,
and
you
know
navigation
being
difficult
and
things
not
building
in
places.
People
expect
them
to
be
so
having
this
gatekeeping
around
that
left-hand
menu
makes
sense
from
historical
perspective,
to
try
and
help
One
Stop
more
of
that
happening
and
to
work
towards
reducing
that
over
time.
So
I
don't
see
us
having
any
difficulty
once
we've
listed
everything
out,
but
I
can
see
why
they
really
want
this
described
to
them.
D
C
The
same
time
I
want
to
simplify,
but
we
are,
quite
literally
adding
a
whole
host
of
different
features
to
a
product
to
the
product
that
don't
yet
exist.
So
I
feel
like
in
our
case.
It
makes
sense
for
us
to
exist
more
than
just
as
a
small
menu
item
and
yeah.
We
could
iterate
as
from
there,
but
we're
gonna
we're
gonna
come
back.
If
we,
if
we
go
into
analytics,
we
will
come
back
to
this
conversation
in
a
few
milestones.
C
C
B
C
B
Wanted
to
talk
about
another
topic
about
widgets
and
new
visualizations
for
the
future.
We
have
a
lot
of
different
widgets
available
to
us
from
e-charts,
and
not
all
of
those
are
going
to
be
useful
to
us,
but
many
of
them
will
be
I
wanted
to
start
talking
from
a
ux
perspective
and
a
requirements
perspective.
What
do
we
need
to
have
put
together
before
we
pass
that
over
to
engineering
either
for
breakdown
or
implementation?
D
A
D
Thank
you
oh,
which
we've
currently
got
area.
We've
got
area,
area
bar
column,
scattered
gauge
or
Gorge
I,
don't
know
heat
Maps
line
chart,
obviously
single
stat
and
sparkline
and
stacked
column.
Those
are
the
ones
I
can
think
of
I,
don't
think,
there's
any
others
so,
rather
than
the
full
library
of
GE
charts.
D
If
we
want
to
go
down
and
start
implementing
those,
then
we
need
to
go
through
the
gitlab
UI
first,
so
we've
first
got
to
generate,
create
those
and
get
labyrite
then
come
up
with
the
common
design
language
for
that
chart.
That
makes
sense
from
a
user
ux
perspective,
from
an
accessibility,
perspective,
etc,
etc.
That
lines
up
with
the
rest
of
the
charts
and
their
designs
to
then
actually
make
use
of
it
on
our
as
a
widget
visualization
got.
D
D
B
Okay,
yeah,
no
that's
helpful.
I
will
I'll
do
some
more
digging
around
in
this
link
that
you
shared
young
thanks
for
sharing
that,
because
definitely
we're
going
to
have
a
couple
of
useful
visualization
options
at
first,
but
there's
lots
of
visualization
options
that
people
like
and
we're
going
to
get
requests
for.
A
I
just
took
a
quick
look,
and
this
is
a
very
uneducated
opinion,
but
it
looks
like
a
lot
of
the
pajamas
designs
are
pretty
much
just
taken
straight
from
e-charts.
So
it's
more
like
we
have
a
curated
list
of
charts
that
we
give
the
thumbs
up
for,
but
it's
not
like.
We
need
to
redesign
anything
or
you
know
restyle
it
much.
C
D
It
the
the
stumbling
block,
is
around
the
accessibility
from
a
color
point
of
view,
especially
when
you've
got
multiple
like
series,
accounting
for
the
accessible
colors
for
blind
people,
Etc
and
other
things
like
that.
So
yes
yeah.
We
do
more
or
less
rap,
but
we
then
have
to
go
through
a
process
of
approve
of
accessibility
review
to
then
get
that
chart
in
so
from
an
engineering
point
of
view.
It's
not
that
complicated.
Necessarily
we've
got
opening
examples
from
a
ulx
point
of
view.
It
again
not
that
complicated.
C
Right,
so
that's
something
we
so
like
Sam's
been
working
on
an
issue
template
for
creating
these,
these
widgets
and
so
I
think
part
of
the
process
and
getting
it
through
the
gitlab
UI
or
the
pajamas
review
is
we'll
we'll
have
to
note
that
accessibility,
color
palette.
That
said,
given
that
we
already
have
visualizations
in
the
pajamas
Library,
do
we
already
have
a
palette
defined
that
we
can
evaluate
new
visualizations
against,
so
that
we
make
sure
that
they're
already
using
that?
C
C
D
Got
our
whole
color
palette
in
figma,
there's
a
link
to
it
in
the
pajamas
data
visualization
charts
at
the
bottom
of
the
page,
to
the
link
that
yarn
shared,
which
opens
up
to
figment
and
there's
a
whole
color
section
which
breaks
down
all
the
color
palette
that
we
can
use
and
how
that
works
in
dark
and
light
mode.
Etc
and
sequencing.
D
B
Because
it'll
be
great,
if
we
can
just
pick
up
what
we've
already
done
in
pajamas
and
looking
at
this
I
mean
it
seems
like
most
of
the
ones
I
had
my
eye
on
are
already
here,
with
the
exception
of
bubble,
charts
and
Sankey
diagrams,
but
those
are
definitely
not
p1s
compared
to
some
of
the
other
things
that
are
here,
which
we
can
do.
First.
D
The
only
other
thing
I
can
think
of
is
we
might
get
pushed
back
to
explain
why
we
need
that
visualization,
because
they
might
that
I
can
see
the
case
where
we
get.
We
start
having
too
many
visualizations
that
we're
supporting,
if
that
makes
sense,
and
it
gets
very
confusing,
so
we
should
have
a
genuine
reason
why
us
specific
set
of
data
works
best
from
a
you
know.
From
a
understanding
perspective,
when
someone
looks
at
that
data,
why
is
it
easier
to
understand
in
this
way
than
using
something
we
already
have?