►
From YouTube: 2022-12-07 Product Analytics PM:UX Sync
Description
Weekly sync where we discuss the latest UX developments, questions and ideas in Product Analytics. In this week's call we talk about the dashboard working group and query designer.
A
B
A
A
Think
about
this.
As
like
the
regions,
the
filters,
the
widgets
Etc,
and
also
what
you
call
those
so
I'll
share.
What
product
analytics
has
decided
with
the
emphasis
that
this
is
all
far
and
subject
to
change
and
that
we're
open
to
working
with
the
group
on
on
these
changes,
so
yeah
I've
linked
to
the
meeting
notes.
There
I've
also
asked
the
question
that
I
found
some
deprecated
designs,
that
I
think
I
can
use
as
like
a
base
for
creating
this.
A
B
Yeah
I
think
it's
a
good
start,
because
that's
I
mean
that's
what
we're
using
the
perfect
concept
and
then
that's
what
we
based
our
requirements
for
the
dashboard
Alpha,
which
of
course
the
data
begin
to
be
displayed,
has
changed,
but
the
regions
are
still
accurate
in
terms
of
here.
Here's
where
your
dashboard
level
controls
are.
Here's
where
the
the
widgets
are
going
to
show
I
would
I
I,
don't
know
if
it's
showing
the
editability
of
it,
but
I
would
say.
B
Yeah
like
a
basic
wireframe
is
also
good
to
go
like
I,
don't
know
if
that's
something
that's
going
to
be
quicker
to
do
in
figma
or
not,
but
I
mean
just
a
napkin,
drawing
almost
just
to
show
like
here's,
where
editability
will
go.
Here's
what
we
plan
to
do
as
far
as
like
editability
for
widgets
and
things
like
that.
But
it's
basing
something
off
of
that
is
a
good
start,
because
that
hasn't
changed
too
much
in
terms
of
how
we
defined
dashboards.
Now,
for
the
internal
preview
is
what
I'm
trying
to
say:
okay,.
A
My
what
I,
envisioned
this
to
be
is
like
a
super
abstracted
version
of
what
we
have
make
it
as
easy
to
consume
as
possible.
I'll
start
with
the
first
iteration
of
just
being
the
static
View
and
then
create
the
issue,
and
then
we
can
discuss
further
on
like
how
we
can
iterate
this
to
show
stuff
like
editability
Etc,.
D
I'll
vocalize
and
type
I'm
trying
to
think
how
to
ask
my
question
so
I
need
to
read
through
the
meeting
notes
for
the
working
group.
What
is
the
expectation
of
the
outcomes
of
this
working
group
and
our
actions
will
take
based
on
the
decisions
of
the
working
group
like
what
one
thing
I'm
mindful
of
is:
if,
since
we're
actively
working
on
dashboards,
does
the
working
group
come
up
with
mandates
that
we
have
to
start
following
with
V1?
D
A
I
can
give
my
understanding
of
it,
but
Dennis
rod.
Please
also
fill
in
my
understanding
is
that
it
is
the
working
group.
Is
there
to
kind
of
set
out
the
guideline
or
recommendation
for
what
a
dashboard
should
be,
but
it's
a
two-way
door
at
the
moment.
So
there
isn't
a
well-defined
like
idea
of
what
a
dashboard
should
be
right
now
and
we're
busy
contributing
to
that.
B
B
What
are
things
displayed
on
the
dashboard
but
like
Marshall
and
others
have
and
I
and
neon
have
like
brought
up
like
well
we're
going
to
be
looking
at
configure,
build
dashboards
and
like
we
need
to
Define
what
capabilities
those
will
like.
We
want
them
to
do
as
well
as
like
what
we
expect,
as
as
an
organization
as
git
lab
to
be
able
to
like.
Allow
customers
to
do
like
well,
we
log
certain
functions
is
that
a
thing
like
do:
users
always
have
like
full
customizability
of
dashboards.
B
It's
every
dashboard
going
to
be
customizable,
so
I
feel
like
that.
That's
going
to
expand
and
I
guess
in
terms
of
your
question
about
based
on
the
current
goals
and
the
potential
for
that
to
expand
we're
at
a
at
a
interesting
point
where,
which
is
something
which
is
why
Jan
and
I
are
bringing
this
up
is
like.
We
have
a
really
good
opportunity
for
us
to
kind
of
show
what
we've
been
working
on
and
help
influence.
B
That
and
like
say
like
here
here,
are
our
needs
and
here's
what
we
think
we
need
and
get
their
feedback
on
it
to
see
if
they
agree,
but
also
then
work
with
them
to
say
hey
like
do
you
agree
on
the
naming
for
these
things
or
conceptually?
Do
you
agree
with
that,
so
that
we
can
help
contribute
to
that
instead
of
it
feeling
like
the
working
group
is
determining
things
and
we
have
to
come
back
to
it
later
on
in
a
different
provision
and
like
update
it
to
be
in
accordance
with
it.
B
D
C
Was
the
just
to
touch
base
around
the
menu
structure
issue
that
we
have
from
our
last
meeting?
It
feels
like
we're
very
close
to
final
agreement,
at
which
point
we
need
to
start
adding
epics
and
issues
against
each
of
these
screens,
as
per
are
to
Do's
on
that
issue.
So
I
just
wanted
to
see
if
anyone
had
anything
they'd
like
to
discuss
I
started
it
off
with
a
question
around.
If
we're
going
to
need
any
tabs
Sam,
it
sounds
like
you
have
a
perfectly
valid
point
to
vocalize
on
that.
C
D
Yeah,
so
your
proposed
structure,
I,
really
like
it
in
terms
of
how
the
buttons
and
the
screens
are
laid
out,
it
didn't
seem
to
me
like
tabs-
would
be
appropriate
for
any
of
the
things
that
are
listed
there.
That
we'd
want
to
split
it
up
on
and
in
general
I
feel
like
Tabs
are
a
good
way
to
represent
a
similar
sort
of
workflow
with
a
different
axis
of
data,
but
that's
not
what
any
of
this
proposed
structure
is.
D
C
Yeah
I
agree
with
you.
The
tab
I
can
see
tabs
being
useful,
maybe
on
an
advanced
dashboards
once
we
get
to
like
version
four
schema.
I
want
to
go
to
have
dashboardable
data,
tab
of
all
dashboards
to
get
different
angles
and
the
same
sort
of
data
structures
without
overly
crowding
One
dashboard,
but
I
don't
see
any
particular
action
right
now.
That
makes
sense
as
a
tab,
possibly
query
designer
you
could
have
a
dashboard
as
a
as
like
the
dashboard
and
then
have
a
second
tab
where
you
go
to
the
query.
C
Designer
and
changes
to
the
query.
Design
are
reflected
immediately
in
the
dashboard
and
stuff,
but
that
is
possibly
much
I.
Don't
see
that
as
an
immediate
requirement
and
nor
do
I
see
it
as
something
that
is
a
blocker
or
or
something
that
necessarily
needs
to
be
considered
for
this
initial
structure
that
we're
trying
to
push
forward.
D
Agreed
and
that's
actually
a
good
segue
into
my
next
point
about
query
designer
I
feel
like
we
should
make
this
more
prominent
in
the
menu
structure
than
it
currently
is
one
of
the
workflows
we
will
see.
Users
following
is
I,
have
a
bunch
of
raw
data,
I,
don't
really
know.
What's
in
the
data
to
be
able
to
create
a
dashboard
to
display
it,
I
want
to
explore
my
data
first
and
the
query.
Designer
is
a
great
way
to
be
able
to
explore
that
data
dynamically,
so
I
feel
like.
D
We
should
make
this
more
prominent
a
proposed
solution.
Let
me
know
what
you
all
think
is
moving
the
the
button.
Query
designer
and
I
put
this
in
the
agenda
as
well.
Basically
moving
it
up
one
level,
so
you'd
have
the
top
level
dashboard
screen.
Then
you
have
the
button
to
do
instrumentation,
create
a
new
dashboard
or
look
at
the
query
designer
directly
there,
and
then
your
individual
dashboard
listing
would
be
there.
D
B
D
A
B
B
My
more
relevant
thought,
while
you
were
talking,
was
almost
lost
it.
Do
we
have
to
support
additional
workflows
depending
on
how
you
access
the
query
designer,
because
basically,
what
I'm
thinking
is
like
if
you
hit
query
designer
from
a
specific
dashboard,
it
has
like
this
button,
so
you
can
add
to
dashboard
right.
So
the
context
is
there
that,
like,
if
you're
in
audience,
for
example,
and
then
you
hit
query
designer,
you
are
effectively
exploring
data,
but
then
with
the
intent
to
add
that
widget
or
visit
or
widget
to
the
audience
dashboard.
B
If
we
take
that
out,
do
we
have
to
support
an
additional
workflow
of
like
okay
at
a
dashboard,
but
now
you
have
to
pick
which
dashboard
and
then
like?
How
does
that
save
things,
and
that
becomes
a
much
more
complex
workflow,
especially
given
now
that
the
query
designer
has
no
way
of
actually
saving
or
adding
two
dashboards.
B
B
If
we
pull
it
out,
which
I,
which
I
agree,
would
make
sense
to
like
kind
of
highlight
and
bring
out
on
its
own,
that
might
that
sounds
like
it
should
be
a
separate
iteration,
because
we're
going
to
support
a
little
bit
more
of
a
complex
workflow
in
terms
of
how
you
actually
apply
that
to
dashboards
and
save
it
to
their
respective
gamma
files.
If
that
makes
sense,.
A
That
is
exactly
what
I
wanted
to
bring
up.
This
feels
like
a
good
second
black
iteration
on
this
feature,
because
yeah
managing
those
contexts
about
like.
Where
do
you
want
to
save
this?
How
we're
going
to
present
that
in
some
stuff,
like
the
ux
or
we're
going
to
pull
that
in
the
front
end,
that's
quite
a
bit
of
added
complexity.
C
I
would
second
the
second
iteration
I
can
see
this
being
useful
in
terms
of
our
Mr
workflow
approach.
You
click
no
go
straight
to
query
designer.
You
fill
out
your
query
and
then
you
press
create
and
it
goes
create
it
or
editing
and
it
pre-fills
the
query
designer,
with
all
your
queries
that
you've
already
written
sort
of
thing
as
to
whether
to
bring
it
up
I
feel
like
we
could
have
the
button
in
both
places.
C
I
mean
the
button
on
the
dashboards
level,
as
well
as
on
the
individual
level,
because
right
now
it's
disassociated
entirely
from
the
flow.
But
it
is
a
valid
point
that
we
should
make
it
more
discoverable,
at
least
initially,
and
it's
an
easy
win
for
us
to
just
have
that
button
in
existence.
If
that
makes
sense,
because
it's
not
associated
to
any
one
particular
flow
right
now,
but
when
the
next
iteration,
when
we
start
adding
it
to
into
the
flow
that's
when
we
want
to.
B
D
Well,
so,
for
this
one
remember,
the
problem
we're
trying
to
solve
here
is
discoverability
of
what's
in
the
data
set,
if
what
we
iterate
towards
is
a
different
experience
for
this
dashboard,
individual
dashboard
list
version
of
query
designer
and
the
individual
dashboard
context,
query
designer
being
different
experiences.
That's
okay!
It's
the
discoverability
problem!
That's
really
the
the
top
of
my
mind
right
now
for
this.
B
D
D
B
But
you're
saying
you're
concerned
about
discoverability,
but
also
concern
about
user
experience,
but
the
more
the
more
discoverable
we
make
it
the
more
complex
it
is
to
like
make
sure
that
user
experience
is
I,
guess
as
easy
as
possible,
so
they
kind
of
to
kind
of
work
against
each
other.
I
feel
like,
but.
B
D
Like
so
I,
don't
believe
we're
cutting
functionality
for
this,
because
we
don't
have
any
sort
of
save
experience
today
to
go
from
otab,
Mr
and
again
yaml
file
and
an
MR
to
saved
correct
our
existing
functionality.
That
we've
seen
in
the
demos
is
just
the
the
GUI
designer
and
the
code
tab.
What
I'm
proposing
is
just
instead
of
making
that
be
instead
of
making
that
experience
live
underneath
each
individual
dashboard.
Moving
that
to
the
the
top
level
dashboard
screen
like
there's.
B
B
Plan
to
imminent
Lantern
has
called
this
out
in
the
last
two
demos
to
like
add
that
saving
functionality
and
that
as
it's
currently
demoing
is
within
the
individual
dashboard.
So
my
understanding
and
I
know
to
started
to
put
some
ethics
together
for
this,
and
we
needed
to
find
that
is
that
we
are
wanting
to
get
to
that
point
of
saving
or
adding
to
a
dashboard
very
soon.
If
we
bring
this
out
I
think
that
would
change
that
and
would
increase
the
scope
of
being
able
to
save
that
functionality.
B
Maybe
maybe
it's
a
better
discussion
to
have
I,
guess:
I,
guess
I'm
not
sure
where
to
go
from
here,
because
I
agree
like
it
would
be
great
to
to
bring
enough
like
make
it
more
discoverable,
but
also
we
don't
have
a
good
idea
of
how
well
this
query
designer
is
defined.
So
it's
hard
to
like
make
that
decision.
I
feel
like
right
now.
A
The
the
thing
that
Sam
brought
up
also
made
me
think
of
what
we
do
for
our
hard-coded
dashboards,
because
it
will
probably
be
a
similar
experience
where,
if
you
can
use
the
query
designer
you
can
use
it,
but
you
can't
save
it
so
you'll
you'll
have
the
code
output,
but
you
won't
ever
be
able
to
write
to
the
file.
So
that's
a
whole
I
think
we'll
have
to
figure
out
I
guess.
B
C
Feel
like
there's
a
the
issue
here,
is
that
the
query
designer
is
being
built
without
any
kind
of
ux
or
product
necessarily
deep
dive
input.
We're
not
thinking
about
the
problem
before
we're
building
the
problem,
we're
just
building
the
solution,
which
is
definitely
one
way
to
go
just
to
get
it
out
there,
but
isn't
necessarily
going
to
be
conducive
to
integration
with
the
rest
of
the
system
that
we're
necessarily
building,
which
is
now
we're
starting
to
feel
that
tension
right
like
right
now,
as
Sam
says
we
could.
What
we've
said
already
is.
C
C
B
B
Evaluating
you're
evaluating
it
based
on
like
how
it
exists
currently,
but
we
have
no
visibility
into
at
no
there's,
no
clearly
defined
visibility
into
like
where
it
intends
to
go
I'm
just
going
off
of
what
Tim
has
said
in
terms
of
he
really
wants
us
to
be
able
to
save
the
dashboards,
but
that
opens
up
a
host
of
another
questions.
So
I
just
feel
like
discussing
this
menu
item.
Is
a
question.
That's
based
on
an
answer.
B
We
don't
yet
have
if
that
makes
sense,
but
I
guess
my
question
to
you
Sam
is
like:
do
you
feel
strongly
that
this
is
something
that
we
would
have
as
a
first
iteration
like
when
we,
when
we
do
expose
query
designer
D?
Would
you
prefer
to
have
this
like
at
the
at
the
Forefront,
because
that
is
something
worth
noting
so
that
we
can
help
shape
the
direction
of
where
the
query
design
is
going
to
go?.
D
B
And
that's
actually
why
I
asked
about
the
name,
because
I
feel
like
query
designer
is
intent
on
like
specifically
for
like
building
the
dashboard
versus
like
I
was
thinking
of
data
Explorer,
which
is
I
think
similar,
but
a
different
purpose
of
just
literally
playing
with
the
data
with
no
intent
to
actually
say
that
anywhere.
You
can
marry
the
two
eventually,
but
that's
why
I
asked
about
the
naming
but
yeah
well.
D
D
Part
of
the
reason
remember
we're
doing
this
proposed
menu
structure
is
so
that
we
have
a
more
concrete
proposal
to
go
back
and
talk
with
the
rest
of
the
ux
word
with
about
our
left.
Sidebar
discussion
as
well,
so
I
I
think
this
is
a
good
point
to
call
out
that
we're
having
some
friction
on
this
topic,
but
also
we
don't
necessarily
have
to
solve
this
question
today.
B
D
Okay,
well
so,
let's
put
let's
put
a
pin
on
this
and
and
come
back
to
it
then,
and
we
can
get
we
need
to
get
requirements
put
together
for
that.
Another
question
I
had
on
this
proposal
is
funnel
analysis.
Right
now,
that's
proposed
to
be
a
widget
that
goes
on
an
individual
dashboard.
Do
we
need
a
top
level
menu
item
for
this?
What's
going
to
go
there
that
wouldn't
be
covered
by
the
individual
widget
and
the
file
backed
configuration
for
that.
B
You
need
a
way
to
define
those
funnels
and
ultimately,
that
creates
a
schema
in
Cube,
and
that
I
think
would
be
what
you
would
select
from
that
funnel
widget,
so
I
to
be
fair,
like
I,
quite
literally
just
like
thought
of
that
in
the
call
with
Rob,
because
I
haven't
really
thought
through
how
funnel
designers
because
are
going
to
work
because
we
know
we
want
to
get
to
it.
But
we
haven't
yet.
B
D
B
B
It's
a
pre-baked
in-depth,
funnel
view
of
like
here's,
why
things
are
converting
or
you
can
dive
deeper
into
that
and
that's
potentially
another
item
that
I
would
expect
to
see
in
like
the
funnel
analysis
or
I
guess
it
could
potentially
exist
as
its
own
another
dashboard.
But
those
are
just
kind
of
like
off
the
top
of
my
head
like
why
we
would
eventually
need
a
section
for
final
analysis.
D
Okay,
cool
yeah,
I
know
that
makes
sense
well,
since
we
are
at
time
in
terms
of
next
steps,
if
we
have
other
feedback
on
this,
let's
go
async
for
this,
but
what
I
think
we
need
to
do
for
an
action
item
before
the
close
of
week
is
to
reply
back
on
that
left,
sidebar
organization
issue
with
the
broader
ux
folks
to
re-engage
on
that
discussion.
Now
that
we
have
a
more
concrete
proposal,
do
you
think
well,
I
guess:
does
anyone
have
any
other
comments?
C
We
need
to
add
the
issues,
slash
epics
links
to
the
different
menus,
but
other
than
that,
if
we're
okay
with
the
general
top
level
structure,
even
if
we
don't
have
an
exact
agreement
on
the
finer
details
like
within
those,
then
I
think
that's
fine.
Just
proving
we've
got
minimum
of
force,
unique
pages
that
we
need
as
what
we
want
to
prove.
Isn't
it
correct.