►
From YouTube: 2023-09-27 Product Analytics UX/PM Sync
Description
Today we talked through:
1. Customer feedback about customizable dashboards, how to create a single experience for those no matter the data source
2. Usage Quota MVC design (https://gitlab.com/groups/gitlab-org/-/epics/11387)
3. Upcoming work for a new designer beyond the current milestone.
A
The
September
27th
product
analytics
PM,
ux
weekly.
It
looks
like
we
have
a
couple
of
follow-ups
from
last
week's
action
items.
First
up
on
the
agenda:
Rob
thanks
for
creating
the
issue
to
document
design
decision
and
thanks
to
you
and
John
priority,
starting
to
populate
that
it's
going
to
be
super
helpful
as
we
transition
with
a
new
product
designer
starting,
hopefully
soon
see,
and
then
the
visualization
designer
MVC
just
wanted
to.
A
All
right,
moving
on
to
oh
sorry,
no,
okay,
moving
on
to
latest
prototype
are
results
of
research,
not
formal
research
per
se,
but
wanted
to
share
I
had
a
chat
with
a
customer
yesterday,
the
impetus
or
the
the
reason
for
the
call
was
that
they
got
excited
about
product
analytics
dashboards
and
customizable
dashboards,
not
knowing
what
they
were
or
what
they
contained.
What
they're
looking
for
was
really
Dora
metrics,
and
so
we
pointed
them
at
visualization
designer
they
did
like
the
customizable
dashboard,
because
I
walked
them
through
that
demo.
A
Real,
quick
and
showed
them
hey.
I
could
pull
through
our
metrics
and
usage
metrics
for
that
same
app,
which
resonated
a
little
bit
but
a
more
interesting
use
case.
I
thought
was
better
visualization
of
audit
events,
so
I'll
share
that
with
the
team
for
the
audit
events,
but
more
good
validation
that
customers
want
customizable
views
of
their
data,
whether
it's
being
whether
it's
data,
that's
coming
from
their
usage
of
gitlab
or
their
applications.
So
just
wonder
share
that
with
the
payment
I'll
show
the
recording
I
just
didn't
get
to
it.
A
B
Thank
you.
I
was
typing
trying
to
type
furiously
before
I
go
into
the
turtle
space
of
when
I
try
to
talk
and
type.
At
the
same
time,
but
I
know,
compliance
is
working
on
getting
audit
events
into
collect
house
which
is
like
a
performance
game
as
well
as
like
I,
think,
would
help
support
like
I,
guess
all
right.
Would
it
be
a
good
opportunity
to
kind
of
like
you
know,
we've
got
to
optimize
looking
at
the
dashboard
customizable
dashboards.
Is
there
a
potential
for
compliance
to
look
at
this
as
well
as
like?
B
Okay,
you
know.
You've
got
audit
eventually
existing
functionality
of
hearing
that
you're
working
on
getting
this
into
a
much
more
performant
database.
What
are
your
thoughts
about,
potentially
like
building
some
type
of
visualization
that
you
could
eventually
plug
that
into
as
an
available
option
for
dashboards,
yeah.
A
B
B
A
What's
the
long-term
vision
for
customizable
dashboards
for
data
coming
from
gitlab
or
outside
of
gitlab,
and
how
we
can
apply
a
common
set
of
filters
to
that
and
a
unified
user
experience
to
it
and
we'll
Loop
product
design
into
that
soon.
But
we're
really
just
picking
more
product
Vision,
less
nuts
and
bolts.
A
But
if
we
give
folks
that
Vision,
then
they
can
build
visualizations
that
will
work
in
a
customizable
dashboard
framework
across
the
app
which
I
think
would
be
really
nice
and
a
great
you
know
feature
set
that
we
can
plug
into
that
ultimate
tier,
so
yeah,
I'll
figure
out
who
that
is
I'll
put
that
at
the
next
time,
nice
cool
and
then
moving
into
a
review
of
any
questions
about
the
upcoming
implementation.
I
dropped
in
the
things
that
were
honestly
just
top
of
mind
yesterday
and
links
to
those
but
usage
quota.
A
C
A
Yeah,
it
was
Snippets
of
the
screenshot
of
the
pipelines
page
and
then
just
plugged
into
preview,
and
some
other
data
put
on
top
of
it
to
show
what
it
would
look
like
for
product
analytics.
Instead
of
Pipelines,
it's
a
it's
a
attached
in
the
design
management
to
the
issue
that
was
promoted
to
an
epic.
So
we
can
pull
it
back
in
and
start
from.
There.
C
C
Yeah
max
is
just
started
working
on
the
back
end
graphical
implementation
of
this,
so
we
have
another
strong
idea
of
what
that
API
is
going
to
look
like
from
a
front
end
which
and
design
perspective.
We
know
what
data
we're
going
to
get
so
from
that.
We
can
get
a
strong
idea
of
what
we
can
Implement
for
the
MVC
at
least.
Okay.
A
A
A
D
I
just
made
a
note
to
myself
on
that
action
item.
So
wait
we'll
see
if
either
of
the
Fulfillment
designers
have
some
bandwidth
Maybe
like
an
hour
or
something,
and
then
they
can
take
a
look
at
the
design
that
you
did
James
and
just
see
if
anything
stands
out
to
them
since
they
work
on
they
work
on
that
page.
A
lot.
E
A
Reuse
I've
tried
to
avoid
all
of
the
problems
that
we
made
initially
on
usage
quota
with
pipelines
and
jump
ahead
a
little
bit,
but
we
know
that
there's
still
some
gaps
of
data
that
we
just
don't
have
and
we
don't
know
how
users
are
going
to
use
it.
Yet
so
there's
some
unknown
but
we'll
get
it
started.
Cool.
C
And
more
broadly
I
know:
there's
a
discussion
around
the
current
usage
quota,
sort
of
structure
of
the
page
and
tabs
and
whether
that's
still
the
right
way
to
go
or
if
there's
an
alternative
structure
that
we
should
be
taking
place.
But
I've
had
a
broad
agreement
that
that's
a
separate
issue
that
doesn't
need
to
affect
this.
B
Out
of
curiosity,
I
know
when
I
wrote
the
very
rough
versions
of
the
issues
for
for
uses
quota
like
we
were
looking
at
transfer,
egress
like
or
or
like
that
ongoing
initiative.
Is
that
like
something
we
still
want
to
reference
or
look
at
all,
or
is
that
its
own
thing
now
like
we're
not
factoring
that
into
our
direction
for
issu's
quota.
B
Some
some
design
box
in
terms
of
like
what
they
wanted
to
do,
I,
don't
know
like
I
hope
we
is
that
at
all
like
in
play
with
what
we're
kind
of
looking
for
for
doing
in
usage
quota,
or
we
just
kind
of
moving
going
forward
with
like
what
what's
actually
existing
and
build.
Today
with
like
pipeline
usage,
I.
B
D
B
B
A
E
Yeah,
it
seems
based
on
the
discussion
threads
the
latest
one
there
that
we're
all
pretty
much
in
agreement.
There's
been
some
feedback
in
terms
of
small
changes
we
can
make
in
terms
of
layout
and
text
on
Rob's
NVC
designs,
but
yeah.
If
we're
all
in
agreement.
I
just
wanted
to
make
doubly
sure
that
we're
good
to
start
with
the
implementation
and
then
potentially
development
on
phase
one,
which
is
the
MVC.
E
C
C
We're
not
changing
too
much
from
the
proof
of
concept
necessarily
which
is
tied
generally
tidying
it
up
to
make
it
feel
slightly
more
polished.
So
we
can
get
it
out
to
users
and
start
getting
their
feedback
on
what
how
they
want
the
direction
to
go
so
I'm
more
than
happy
for
us
to
start
doing
the
implementation
planning
and
look
at
you
know
bringing
if
we're
running
low
on
task,
bringing
the
first
phase
into
this
Milestone
or
the
next.
D
B
A
Wording
changes
rearranging
the
columns,
so
they
make
a
little
bit
more
sense.
It's
not
back
and
forth
yeah
and
some
language
cleanup
I,
am
in
favor
of
fixing
or
getting
the
click
events
included
so
that
we
can
see
those
and
start
to
see
some
of
the
metadata
or
the
extra
data
associated
with
that
tracking
I
think
we
might
pull
support
for
querying
unstructured
events
out
of
the
MVC
as
a
separate
effort.
A
A
I
think
we
attacked
last
week
about
that
could
be
a
parallel
path.
It
shouldn't
have
to
hold
up
the
visualization
designer,
especially
while
we're
in
the
beta.
We
can
convey
that
hey
your
custom
events
aren't
going
to
be
queryable
yet
because
of
the
shift
from
Jutsu
to
snow
plow,
we're
working
on
the
best
way
and
a
first
iteration
to
give
you
those
custom
events
in
a
way,
that's
visualized
and
so
trying
to
sort
through
the
the
viability
of
especially
the
the
querying
of
those
things.
C
Okay,
in
that
case,
I'll
move
that
out
of
the
MVC
and
in
fact
the
post
MVC
is
its
own
tangential
same
boost
that
Customer
Events
issues
going
to
turn
into
an
epic.
It's
just.
It's
got
so
many
moving
Parts,
so
it
can
be
its
own
tangential
task.
It
also
means
that
we
need
to.
We
can
feature
flagget
off
separately,
while
we're
developing
towards
that.
C
C
A
If
we
need
to
put
that
out-
and
we
do
the
UI
stuff
all
together
and
then
we
fix
the
link
clicking
like
confined
with
that
sort
of
that
iteration
plan
that
that
works
for
me
or
that
phasing
plan,
but
I,
think
a
good
iteration
is
the
ux
improvements
and
then
a
nice
new
feature
is
going
to
be
put
back
the
support
for
the
custom
events
once
we
get
that
sorted
out
of
how
do
we
store
those?
How
do
we
create
those?
A
D
Yeah
I
mean
if
you
want
to
go
back
and
take
a
look,
but
if
you,
if
you
don't
do
that,
I
think
it's
fine,
like
I'm
having
I,
have
a
list
of
things
for
the
new
designer
to
take
a
look
at,
and
one
of
them
is
for
them
to
take
a
look
at
that
scorecard
and
the
recommendations
and
see
if
they're
still
relevant.
So
that
would
be
a
good
first
task
for
them
anyway
like
to
get
oriented.
So
we,
if
you're,
okay
with
waiting,
we
could
wait.
Yeah.
A
Awesome
all
right
and
then
I
think
that
we've
already
covered
everything
in
the
last
bullet
item
or
the
last
agenda
item
with
the
previous
two
agenda
items
things
that
are
already
scheduled.
16
6
are
all
usage
quota
thing
and
then
we
have
some
things
that
are
not
yet
scheduled
that
we'll
probably
need
some
design
on
or
in
a
ready
for
design
phase.
So
those
can
sit
and
wait.
I
think
for
a
while
longer.
A
B
I'd
want
to
call
out
one
that's
not
yet
existing,
but
how
we
handle
filters
kind
of
like
temporarily,
because
I
think
with
the
user
ID
type
and
things
like
that.
We'll
have
more
things
to
be
able
to
filter
by,
but
we
really
only
discussed
it
and
James
I
know
you
and
I
were
talking
about
like
what.
If
we
use
these
tokenizers
existing
in,
like
the
issue
list
or
the
Milestone
board.
As
like
a
an
existing
pattern
to
leverage
that,
but.
B
I
think
we're
gonna
use
a
toggle
to
start
right,
yeah
yep,
yep
yeah,
just
as
as
we
eventually
start
like
customers
and
I
know,
we
will
want
more
as
well
but
like
having
the
so
we
don't
have
a
kitchen
sink
of
toggles
and
drop
downs
need
a
more
scalable
way
of
handling
that,
but
not
something
that
I
think
we
need
to
worry
about
now.
It's
just
as
we
look
at
issues
like
funnel
visualization
I.
Think
filtering
is,
is
a
contender
in
that
time
frame.
Yeah.
B
No,
for
sure,
we'll
definitely
want
to
be
very
like
script
with
what
is
actually
available
to
you
in
the
token
Azure
I.
Definitely
don't
imagine
that's
just
like
passing
through
what
Cube
allows
you
to
filter
or
anything
like
that
like
we
have
to
be
very
deliberate
about
that,
so
it
may
just
be
that
it's
just
like
in
terms
of
like
how
we
would
want
to
handle
that
with
the
current
like
knowing
that
we
don't
know
the
capacity
to
like
do,
research
into
new
patterns
and
variant.
B
What's
what
the
future
solution
is
something
we
can
evaluate,
but
yeah
we
definitely
want
to
regardless
of
where
which
direction
we
go
into.
We
want
to
make
sure
that
we
are
in
complete
control
of
what
the
user
can
actually
filter
by,
because
it's
not
only
just
from
a
easier
experience
point
of
view,
but
also
from
a
performance
point
of
view.
B
C
Just
calling
it
out
yeah,
we
should
also
make
sure
from
a
ux
point
of
view.
Obviously
we're
not
the
only
ones
use
customer
dashboards,
customizable
dashboards
now
and
not
all
groups,
need
all
filters
for
their
user
experience,
so
I
mean
having
a
tokenized
search
will
actually
make
that
slightly
simpler,
excluding
excluding
certain
tokens
based
like
injecting
them
in
based
upon
the
usage,
but
at
the
same
time
it
might
yeah
we'll
need
to
make
sure
we
Loop
in
other
groups
as.
E
Well,
we
could
result
in
a
confusing
ux
where
all
dashboard
Pages
look
the
same,
but
certainly
you
can't
filter
by
certain
tokens,
because
not
all
visualizations
at
this
moment
are
compatible
or
respect
the
filters.
So
our
solution
currently
is
to
just
have
a
hard-coded
list
of
these
are
dashboards
where
the
filters
should
not
be
rendered
and
respected.
Yeah
the
vs,
the
vsd
is
the
current
example
and
that's
probably
going
to
expand
so
yeah.
E
We'll
also
need
to
think
of,
like
some
we'll,
basically
need
to
reach
out
and
probably
form
some
sort
of
working
group
in
the
end
between,
like
all
the
different
groups
that
are
contributing
to
and
working
on,
customizable
dashboards
to
try
and
figure
out.
What
is
our
unified
approach
on
how
we
handle
filters,
the
ux,
the
technical,
the
development
side
of
it
like
yeah,
everything.
D
A
I
could
start
that
by
taking
inventory
of
what
search
is
available,
I
think
the
the
not
low
hanging
fruit,
but
the
first
things
that
will
be
converted
are
things
under
the
analyze
menu
like
secure
would
probably
come
later
and
figure
out.
What
is
there,
what
different
visualizations
use
different
filters
and
we
can
work
a
longer
term
vision
of
that
into
that
customizable
dashboard
Vision.
A
D
B
Ideally,
we
would
like
all
groups
to
like
building
dashboards,
to
use
this,
or
at
least
have
the
option
to
use
this
dashboards
in
general,
because
part
of
the
working
group
we
had
earlier
this
year
was
like
we've
got
30
different
dashboards
and
they
all
look
different
and
then
you
know
potentially
like
I
mentioned
earlier,
like
maybe
compliance
could
leverage
this
and
then
observability
definitely
has
some
some
opportunities
to
use
this
as
well.
So
it's
just
two
of
us
for
now
the
two
groups
for
now,
but
it
could,
it
could
expand.
Okay,.