►
From YouTube: 2022-12-14 Product Analytics PM:UX Sync
Description
Weekly sync where we discuss the latest UX developments, questions and ideas in Product Analytics.
A
It
is
for
the
14th
of
December.
We
have
a
handful
of
Jenna
items,
so
I'll
kick
us
off.
The
first
one
is
to
review
the
sticky
item,
although
this
sticky
has
been
there
since
last
week
and
the
week
before
that,
so
wonder
if
there's
anything
ongoing,
that
we
still
need
to
check
out
or
because
most
of
this
I
think
is
covered
by
Rob's
points.
Lowering
the
agenda
where
you
know
there's
a
question
about
like
the
left
sidebar
and
if
there's
anything,
we
need
to
do
to
expedite
that
also
help.
A
Then
last
week's
action
items
Sam
I
believe
you
had
the
first
one
to
reply
back
on
the
sidebar
issue
with
the
menu
items
we
agreed
on
just
want
to
check.
If
there's
been
any
progress
or
any
questions
on
there.
A
And
then
I
think
Dennis
had
the
next
one
to
what
was
it
explore
in
the
naming,
Direction
and
requirements
of
the
query
designer
I'm
not
aware
of
any
updates
there?
If
someone
has.
A
Regarding
the
query,
designer
I
picked
him
to
understand
his
vision
and
how
that
will
fold
back
into
experience
like
we're
building
to
see
if
we
need
to
collaborate
more
And,
to
clarify
the
scope
quickly,
opening
up
that,
but
it
seems
like
we
can
all
just
read
this
and
post
articles
there.
If
we
have
any
on
the
query
designer
it
has
recently
been
named
to
the
widget
designer,
so
that's
been
something
that's
happening
in
the
Mr
review.
A
A
That
is
a
good
point.
I,
don't
know
if
we've
thought
about
the
ux
flow,
where
at
which
Step
or
when.
A
Yeah
there's
a
lot
of
things
we
haven't
thought
about
here
at
the
moment,
I
don't
even
know
if
the
title
is
part
of
what
you
enter
in
the
current
widget
designer
offer
version
and
I
don't
know
to
to
me
and
what
I
had
in
my
mind
just
quickly
talking
like
my
through
my
thoughts
is
that
you
would
make
a
visualization
then,
as
part
of
the
widget
you
would.
You
could
like
select
it
and
then
type
in
a
name
or
something
that
those
would
be
like
two
separates.
A
C
I
guess
if
the
idea
is
that
we
have
shareable
visualizations,
which
I
think
is
sort
of
the
concept
that's
been
going
for
having
one
visualization
which
gets
used
across
multiple
dashboards,
then
that
makes
sense
you
go
into
the
which
you
visualization
query,
whatever
designer
create
your
visualizations.
Save
those
then
go
into
your
individual
dashboards
and
go
right.
I
want
to
drag
that
here.
Give
this.
This
titles
have
this
date
range
across
the
dashboard,
Etc
and
work
off
that
basis.
A
That's
that's
pretty
much
what
I
had
in
mind.
There
was
some
sort
of
like
edit
mode
on
dashboards,
where
you
could
like
drag
a
drop
or
from
a
drop
down,
select
like
what,
which
visualization
should
this
widget
to
use
or
something
like
that,
but
yeah
that
that's
all
I
guess
a
ux
flow
that
we
still
need
to
explore
and
validate
and
right.
B
One
of
the
other
things
I
think
we
could
explore
is
when
you
do
the
the
edit
on
the
dashboard
right
now.
It
has
the
ad
widget
option
that
should
have
like
a
drop
down
of
widgets
that
are
visualizations
that
are
loadable,
so
that
would
be
a
way
to
kind
of
mirror
that
concept
of
visualizations
go
in
their
own
file,
but
it
makes
it
easier
to
manage
a
dashboard.
A
Right
unless
anyone
has
more
comments,
I
can
jump
onto
my
next
agenda.
Item
cool,
seeing
some
nodding
heads
I'll
quickly
share
my
screen
for
this
one
right.
Can
you
all
see
my
screen
I?
Think
some
other
heads
so
I
just
quickly
wanted
to
go
through
this
slide,
that
I
made
to
show
the
dashboard
regions
that
I'm
going
to
share
with
the
word
or
would
like
to
share
with
the
dashboard
version
group.
A
It's
the
call
that
I
have
right
after
this
one
so
and
also
for
a
comparison.
I
just
want
to
open
up
the
issue
where
there's
already
some
maps
design
out
so
I
just
wanted
to
hear
like
if
there's
any
feedback
or
anything
else
that
should
be
noted
on
this.
So
what
I
have
here
is
you
know
we're
following
like
the
standard
page
design.
If
we
have
breadcrumbs
the
dashboard
title,
then
we
have
filter
section
which
for
now
is
going
to
be
drop,
downs
which
have
not
yet
been
defined.
A
The
one
thing
that
we
know
for
sure
we
want
is
like
a
date
range
and
please
correct
me
if
I'm
wrong
and
like
any
of
this
and
then
below
that
where
we
differ
from
all
other
gitlab
dashboards,
is
that
we
have
this
customizable
dashboard
Zone,
and
that
inside
of
that
we
have
the
concepts
of
a
widget
and
a
visualization
and
where
the
widget
is
like
the
size.
A
B
C
Just
quickly
I
thought,
I'd
say
two
things
one.
We
should
we're
calling
this
problem
analytics,
but
this
is
also
going
to
be
used
by
optimize.
So
I
don't
know.
If
we
want
to
raise
that
eventually,
once
we
get
groups
once
they
get
groups
functioning,
then
they're
gonna
start
using
this
system
as
well.
C
The
second
Point,
it's
a
minor
one,
but
the
components
through
me
for
a
minute
when
I
only
read
the
right
hand,
side
and
then
I
understood
what
you
meant
was
I
read
the
left,
I,
don't
a
component
of
naming
is
hard,
but
components
is
I,
don't
know
what
else
to
call
them
I
or
how
to
differentiate
them
from
the
visualization
widget,
because
it
all
sounds
very
similar
anyway.
That
was
my
only
other
point.
C
A
Yeah
I'll
I'll
give
this
some
more
thoughts.
Hopefully
I
can
think
of
a
better
name
also
before
the
call,
and
also
us
the
work
in
group
four
for
feedback.
If,
if
they
don't
to
answer
your
original
question
about
optimize,
I,
think
what
Dennis
and
I
thought
here
was
just
to
specifically
share
what
product
analytics
as
a
group
is
working
on
and
what
we're
thinking.
A
The
working
group
is
aware.
That
optimize
is
looking
at
using
this
and
also
note
it
in
the
meeting,
but
they
also
have
some
different,
like
naming
conventions
or
nomenclature
for
some
of
the
stuff,
like
they're,
not
using
I,
think
widgets
they're
using
panels,
for
example,
so
there-
and
this
is
why
this
is
like
often
subjects
you
change
because,
like
this
is
at
the
stage
now
we're
trying
to
get
like
a
a
common
nomenclature
for
like
everything.
A
I
don't
know,
that's
that's
a
good
enough
one
dashboard
concept
and
I'll
and
I'll
note
in
the
meeting
that
this
is
to
be
used
by
multiple
groups,
specifically
optimized
cool
thanks.
So
much
for
the
feedback.
And
yes,
sorry
about
the
the
thing
for
sharing
that
yeah
yeah.
That
was
my
bad
yeah.
D
Yes,
I'm
sorry,
I
didn't
raise
my
hand
in
time,
so
I
have
a
I,
have
a
question
and
I'm
totally
okay.
If
the
answer
is
that
is
to
be
defined
but
I
I
wanted
you
guys
to
fill
me
in
we
regarding
the
filters,
because
we
in
the
in
the
green
rectangle
there
it's
a
it,
looks
like
Global
filters
for
all
of
the
for
all
of
the
widgets
that
we're
going
to
have,
but
the
filtering
right
now
deep
in
the
visualization
layer,
first
in
the
in
the
in
the
visualization
definition.
B
Intention
for
this
is
that
we'll
have
filtering
available
at
a
dashboard
level
like
this
and
that's
going
to
propagate
down
to
each
of
the
individual
widgets
one
of
the
common
workflows
people
do
when
they're
interacting
with
the
dashboard.
Is
they
want
to
analyze
the
data
set
and
have
it
have
their
filter
and
be
applied
to
every
single
visualization
in
that
single
dashboard?
It's
it's
really
tedious
to
have
to
do
the
filtering
for
each
individual
dashboard
one
at
a
time.
It's
also
a
place
where
users
get
confused.
B
B
So
we
want
this
dashboard
level
filter
to
say
you
can
set
the
filtering
mechanism
I'm
here
once
and
it
will
affect
all
the
different
widgets
that
live
on
that
dashboard.
For
you
automatically.
D
A
The
first
iteration
technically
like
this.
This
is
totally
doable
because
we're
taking
the
global
filter
and
then
passing
it
down
as
it
overwrites
to
all
the
visualizations.
The
complexity
starts
when
a
widget
also
has
an
override
on
a
dashboard,
but
that
is
for
future
iterations
and
once
again,
that's
a
whole
user
thing.
That
also
needs
to
be
explored.
Like
uxo
Rob
looks
like
yeah.
C
The
only
thing
I
was
going
to
say
is
that
in
the
schema
discussion
it
was
the
big
conversation
around
overrides
and
query
and
stuff.
The
general
feeling
that
I
that
came
out
of
that
conversation
is
that
the
most
likely
scenario
will
be
that
we
will
have
Global
filters
and
then
we'll
have
localized
filters,
but
they
might
not
overlap.
We
might
have
only
filters
that
can
be
applied
on
the
global
level,
but
not
on
the
local
level,
for
instance.
Date
date
might
make
no
sense.
C
It
might
not
make
any
sense
to
have
on
a
localized
widget
and
to
reduce
technical
complexity.
We
could
just
have
two
sets
of
filters,
one
that
can
be
applied
locally
and
one
that
can
be
applied
globally
and
ignore
the
whole
override
process.
There
might
be
some
shared
something
to
be
discussed
and
figured
out
in
decision
two
Dennis.
A
So
that
a
person,
let's
say
if,
if
we
have
a
customer's
or
a
customer
team
where
one
person
is
creating
visualizations,
another
one
is,
is
using
that
in
dashboards
that
they're
aware
that
the
person
creating
it
or
creating
the
visualization
is
where
that
the
user
of
the
visualization
can
override
that
date
range.
A
A
Cool
if.
B
You
want
to
poke
around
and
see
some
places
where
we
at
gitlab
use
it
I,
don't
know
if
you
have
psisense
access,
but
if
you
look
at
some
of
the
monthly
active
user
dashboards,
a
lot
of
those
respects
the
filter
settings
for
the
dashboard,
but
there
are
other
dashboards
like
I'm
thinking
of
the
compliance
dashboard
we
built
where
date
filters
are
ignored
for
other
widgets,
because
for
some
widgets
it
was
specifically
hard
coded
for
a
12-month
window.
So
date
filtering
doesn't
make
sense
there.
D
Actually,
thinking
about
that
about
how
how
those
license
does
and
yeah
yeah
I
like
rubber
idea
about
about
having
like
overrideable
filters
and
and
like
static
filters
that
are
onto
the
to
the
visualization,
that
might
be
a
good
idea,
but
yeah.
No!
No
thank
you.
Thank
you
for
for
the
context
and
for
taking
the
time
to
explain.
C
C
So
I
guess
I've
got
the
next
Point,
but
it's
more
or
less
going
to
be
me
saying
to
Sam
this
question:
is
there
anything
we
can
do
to
help
expediate
that
left
sidebar
discussion?
It
seems
to
be
going
into
the
sort
of
more
down
to
product
to
resolve
and
come
up
with
a
compromise,
but
is
there
anything
from
a
ux
or
an
engineering
since
you've
got
free
Engineers
technically
on
the
call
that
we
can
do
to
help
make
your
life
easier
in
that
discussion.
B
Yeah
I'll
be
candid
I'm,
getting
pretty
frustrated
with
this
discussion
since
we're
just
going
in
circles.
It
feels
like
at
this
point
I
feel
like
what
we
were
asked
to
provide
is
an
explicit
proposal
to
iterate
on.
We
did
that
and
now
we're
being
asked
to
give
another
proposal
that
optimize
agreed
with,
even
though
they
agreed
with
our
original
idea.
B
So
the
original
idea,
being
you
know,
we
have
product
analytics
and
gitlab
analytics
split
out,
so
I
I
need
to
reply
to
that
something
I
could
use
from
you
all
with
your
ux
hats
on.
B
If
there
is
another
proposal
idea
that
we
have
I'd
love
to
hear
that
to
try
and
push
this
over
the
line,
I'm
going
to
write
a
reply
to
to
Nick
and
Tori
to
hopefully
explain
this
is
something
we're
considering
blocking,
because
we
have
nowhere
to
put
our
stuff
right
now,
but
what
I
think
we
should
also
be
doing
in
parallel
is
figure
out.
Is
there
a
smaller
step?
We
can
do
with
one
of
the
existing
menus
if
we're
going
to
get
this
much
pushback
on
putting
an
actual
left
sidebar
item
in
I.
B
I
can
appreciate
that
we
need
somewhere
to
put
funnel
analysis
and
experimentation,
but
we
don't
have
those
today.
Those
don't
exist
yet
so
at
a
minimum.
What
we
need
is
somewhere
to
put
the
dashboard
screen,
the
configuration
screen
and
I
think
if
we
can
think
through.
Where
could
we
put
those
temporarily
before
we
can
get
the
sidebar
discussion
resolved?
B
That
would
help
us
unblock
ourselves
for
getting
something
out
there,
whether
that's
the
configuration
just
lives
at
the
instance
level
for
a
little
while
longer,
which
is
where
it
currently
is,
is
my
understanding
before
we
move
it
down
to
project
level
or
if
we
move
that
to
a
project
setting
specific
page
instead
or
if
we
put
the
dashboards
under
the
analytics
tab
temporarily
again,
I'd
be
open
to
that.
B
But
I
think
we
need
to
also
think
of
a
short-term
proposal,
for
where
do
we
put
this
stuff,
because
I
I
continue
to
get
the
sense?
This
discussion
is
going
to
go
on
for
several
more
weeks
before
we
can
get
everyone
aligned
after
a
few
different
phone
calls
and
I.
Don't
want
us
to
I.
Don't
want
us
to
slow
down
shipping
our
first
internal
release
on
this
discussion,
because
that,
wherever
we
put
things
for
the
first
time,
it's
not
going
to
be
the
last
time
that
we
get
to
visit
that
decision.
B
B
B
C
In
terms
of
settings,
we
can
leave
it
on
the
instance
level.
We
we
need
to
move
it
at
the
point
that
we
start
allowing
users
to
create
set
up
their
own
Stacks
rather
than
using
ours,
which
isn't
part
of
the
internal
preview.
But
it's
part
of
the
customer
preview
so
for
this
first
phase,
we're
okay,
just
leaving
it,
as
is,
regarding
the
other
things.
I
feel
like
we've.
C
C
I'd
be
okay
with
sticking
under
analytics,
but
it
would
mean
things
like
the
query.
Designer
wouldn't
would
need
to
be
a
separate
button,
not
his
own
page,
and
we
wouldn't
have
anywhere
for
funnels
or
anything
like
that.
Just
yet,
unless
we
had
some
internal
button
selection
somewhere
on
the
main
dashboards
list,.
B
Yeah,
no
I
can
appreciate
that
this
won't
scale
once
we
start
adding
funnels
experimentation
Etc,
but
we
need
to
have
some
way
to
get
there
before
we
move
to
that,
because
we're
going
to
have
the
dashboarding
functionality
completed
before
we
move
on
to
the
funnel
functionality
right.
So
we
don't
necessarily
want
to
gate
the
two
together.
C
In
that
case,
I
think
sticking
on
to
product
under
the
existing
analytics
heading
makes
the
most
sense
in
a
superficial
level.
It's
just
gonna
be
super
confusing
once
you
know,
but
once
customers
start
using
it
because
there
is
such
a
distinction
between
what
we're
doing
and
what
Optimizer
doing
sure.
Well.
B
Is
what
we
need
to
do
to
have
things
available
internally?
This
is
likely
not
where
it's
going
to
live
once
we
get
this
to
hey,
Mr,
Mrs
customer
we're
asking
you
to
pay
us
money
for
this.
This
will
be
the
some
the
first
iteration
that
we're
going
to
revisit.
Once
we
get
the
agreement
with
you
asked
about
what
the
the
proper
side
sidebar
solution
is.
D
Yeah
so
I
left
I
left
a
comment
there
on
that
discussion.
A
while
ago
when,
when
the
proposals
have
not
been
that
discussed,
I
mean
the
discussion
were
still
heated
for
putting
a
word
so
yeah.
My
my
idea
was:
let's
get
one
of
the
proposal
and
create
anymore
and
see
it
live
and
and
maybe
try
to
push
that
forward.
So
maybe
maybe
we
can
try
to
do
this
again
now
that
that
the
discussions
are
more
refined,
but
yeah
I
mean.
D
B
D
C
I
also,
don't
think
we
need
foundations,
approval
to
add
something
to
a
sub
menu
either,
so
we
can
add
it
to
analytics
as
long
as
is
it
Heim.
The
product
manager.
B
C
As
long
as
they're,
okay
with
us,
it's
a
question
of
section,
a
sub
item
from
them,
then
yeah,
let's
go
with.
Let's
go
with
that
leave
settings
where
it
is.
That
is
definitely
something
we're
going
to
have
to
make
sure
we've
tackled
before
we
hit
customer
preview
in
the
new
year.
B
Yeah
well,
okay,
so
that
that
sounds
like
we
have
a
plan
on
on
that
for
the
short
term,
a
related
but
different
question
about
the
settings.
Page
I
was
looking
through
the
left,
sidebar
menu,
and
do
we
have
settings
for
other
capabilities
here,
or
should
we
actually
think
about
moving
that
under
the
settings
page
I
only
was
able
to
find
configuration
for
security
and
compliance,
but
all
the
other
settings
are
under
settings
like
what
do
you
all
think?
C
If
I
recall
the
reason
security
and
compliers
got
moved
was
because
their
configuration
started
to
get
quite
complicated
and
it
didn't
necessarily
fit
into
just
a
section
like
if
you
actually
go
into
securing
compliance.
The
you'll
see
that
they've
got
all
of
these
for
security
testing
and
then
their
compliance
license
compliance
configurations
and
vulnerability.
So
it
starts
to
get
a
lot
more
and
there's
more
I
think
behind
flags
as
well.
So
you
know
there's
more
information
that
they're
providing
than
just
a
standard
setting
right
now.
Ours
could
fit
under
a
settings
area.
C
But
if
we
wanted
to
move
like
the
tracking
codes
configuration
set
up
and
all
of
that
like
we
discussed
into
a
configuration
screen,
then
we
would
want
to
have
a
separate
page,
but
for
now
like
for
the
initial
Restoration
in
customer,
when
we
move
to
customers,
then
I
think
just
sticking
under
a
settings.
Region
and
projects
would
be
okay.
Personally,
okay,.