►
From YouTube: 2022-11-09 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 MVC onboarding flow designs.
A
A
So
something
you
may
have
noticed,
Sam
me
and
Yan.
We
went
through
all
of
the
designs
because,
obviously,
we've
been
designing
the
proof
of
concept
more
or
less
what
is
already
in
the
proof
of
concept
and
what
we've
discussed.
What
have
been
figured
out
from
that
in
the
flowchart
pretty
much
converting
this
into
screens
into
different
views,
but
all
of
that
doesn't
go
into
the
initial
sort
of
MVP
or
MVC
whatever
we
call
it.
I
can't
remember
that
coming
we
use
so
we've
broken
down
Envy
MVC.
A
A
So
we
split
the
file
into
the
main
sort
of
design
for
the
actual
file
itself,
then
MVC
designs
and
then
near
future.
So
we've
moved
all
the
designs
we
had
into
something
future
into
the
next
step
sort
of
area
something
but
ninyan
can
always
continue
to
iterate
on
and
work
towards
as
and
start
slotting
into
future
Milestones.
Based
upon
the
map
that
we're
going
to
discuss
in
a
little
bit
or
the
roadmap
we're
going
to
discuss.
So
this
is
very
much
just
the
minimum
five.
A
The
minimum
we're
gonna
do
for
the
first
step
of
internal
preview
and
just
showing
the
whole
flow
from
end
to
end
in
the
UI,
so
obviously
starting
off,
and
if
anyone
has
any
questions
or
would
like
to
just
or
like
to
point
out
any
issues
or
anything
they'd
like
today
feel
free
to
jump
in
and
cut
me
off
start
off
with
an
empty
page.
When
someone
visits
the
analytics,
we
don't
know
where
the
menu
is
yet
do
we.
B
No,
so
there's
a
couple
thoughts
and
where
I
think
we're
probably
going
to
land
is
making
a
standalone
left.
Sidebar
entry
and
the
thing
that
we
hadn't
discussed
and
what
I
was
getting
stuck
on
originally,
is
we're
probably
going
to
rename
the
existing
analytics
tab
to
internal
analytics
or
git
live
basically
to
differentiate.
These
are
your
product
versus
this
is
your
how
you're
using
git
lab
sort
of
analytics,
but
we
haven't
made
a
final
decision
on
that.
Yet.
B
B
Yeah
that'd
be
they'd,
be
fine
with
all
of
this.
We
just
have
to
remember
to
be
as
iterative
as
possible,
even
if
some
of
our
iterations
might
feel
a
bit
embarrassing
with
how
they
look.
But
that's
actually
a
good
sign
that
we're
cutting
deep
enough
into
the
scope
that
we're
actually
iterating
effectively.
A
B
A
A
C
B
B
That
we're
going
to
roll
this
out
is,
for
the
very
very
first
releases
we're
going
to
be
very
careful
with
who
we
talk
to
and
show
about
this.
This
will
be.
We
have
a
saint
conversation
to
introduce
it.
It
has
lots
of
weird
edge
cases.
Here's
how
you
do
it
so,
the
in
how
do
we
introduce
it
to
the
customers?
We
talk
to
them
directly.
Once
we
get
to
the
point
of
having
that
left,
sidebar
discussion
and
making
a
decision
there,
then
it's
going
to
be
part
of
the
product
menu
structure.
A
Okay,
so
that's
fine
once
they're
into
that
stage
once
this
loads,
no,
the
next
stage
is,
it
will
call
our
back
end
worker.
The
Max
has
worked
on
I've
helped
him
with
his
and
at
least
initially
it's.
This
will
be
super
quick,
really,
quick.
It's
because
we
all
we
wait
for
is
for
the
Jitsu,
front-end
JavaScript
key
to
be
returned
to
us.
A
We
don't
wait
to
see
if
clickhouse
is
initiated
or
anything
like
that,
because
we
don't
need
to
so
the
once
once
we've
got
that
key.
This
screen
moves
on
this
might
be
slower
in
future,
once
people
start
creating
their
own
infrastructures
Stacks
button
other
the
stacks
button.
For
now,
while
we've
got
control
of
the
second
is
very
quick,
so
this
can
almost
be.
You
know
a
second,
maybe
two
seconds,
and
then
it's
gone
yeah.
C
A
B
B
That
case,
what
we
definitely
need
to
make
sure
we
do
is
talk
about
that
in
the
documentation
in
text
format.
Just
because
I
know.
One
of
the
first
questions
we
will
get
is:
where
is
my
data
and
where
is
it
going?
So
we
should
make
sure
the
documentation
covers
that,
so
people
can
self-service.
That
answer.
A
Thanks
because
otherwise
I
will
forget-
and
it's
a
very
good
point,
okay
on
to
the
next
screen
right
now,
we
only
have
three,
as
we've
discussed,
it's
gonna
and
then
they're
all
JavaScript
related
they'll,
just
kill,
expand
and
collapse
to
show
the
different
options.
The
actual
key
that
we've
been
given
by
the
stack
creation
process
will
appear
here,
along
with
their
domain,
that
they've
given
in
the
admin
settings
for
Jitsu,
so
that
should
literally
in
each
one
be
a
copy
and
paste.
A
Well,
we
will
do,
but
we
might
need
to
split
up
the
page
or
change
the
heading
slightly
to
make
it
clear
that
these
other
these
existing
options
are
all
sort
of
front-end
JavaScript
related.
If
that
makes
sense
right,
but
that's
a
ux
question,
then
I
don't
see
it
changing
dramatically.
It's
just.
We
might
need
to
highlight
a
bit
clearer.
B
So,
for
this
page
the
really
minimal
information
a
customer
would
need.
Is
this
API
token,
as
well
as
that
destination?
What
would
you
think
about
putting
those
two
pieces
of
information
somewhere
at
the
top
of
the
page
at
the
bottom
of
the
page,
I-
don't
care
but
putting
them
stand
alone
and
making
them
more
prominent.
So
that
way,
if
someone
says
Hey,
I
want
to
use
Curl
to
do
all
my
browsing.
Okay
knock
yourself
out
other
that
way,
they
don't
have
to
look
through
example,
Snippets
here.
A
B
A
A
Really
like
the
idea
of
making
it
clearer
and
at
some
point
we
are
going
to
need
a
way
of
surfacing.
I
guess
these,
these
details
to
the
user
after
this
stage
as
well,
because
once
after
this
point,
unless
you
go
to
the
code
that
you've
created
you've
you've,
you
don't
know
the
key
you're
not
told
the.
A
B
C
A
A
He's
been
underneath
the
covers
on
the
bed
for
about
the
last
four
hours
and
he's
just
decided
to
pop
his
head
out
and
say
hello
excited
to
wake
up
for
the
day.
Yeah
yeah,
pretty
much
lazy
next
screen
is
just
the
empty
dashboard
screen
when
they
haven't
got
that
yaml
configuration
that
we're
currently
working
on
installed
right
now.
We
just
shows
you
to
learn
more
link,
I've
realized.
None
of
that
is
entirely
centered.
A
B
C
So
adding
the
buttons
to
the
project,
question
mark
I,
don't
know
adding
the
button
on
this
page
relatively
simple,
like
that.
Url
of
constructs
it
and
the
way
that
the
blob
editor
works
is
it
takes
the
URL
parameters
from
what
you've
set.
So
it
would
just
be
a
URL
on
this
page
and
the
rest
will
be
handled
by
blob
editor.
So
we
we
wouldn't
have
to
build
anything,
but
users
may
find
it
confusing
that
we're
just
linking
them
to
a
blob
editor
for
an
empty
file
yeah.
So
as
a
first
iteration.
C
B
C
A
Be
I
would
be
if
we
can
get
attempt
a
static
template
set
up.
Then
I'd
be
very
keen
on
adding
that
button,
because
then
that
actually
becomes
useful,
whereas
I
feel
like,
as
Jan
said,
if
it's
just
a
button
to
a
blank
page
with
nothing.
No,
no,
no,
no
clear
way
of
going
after
that,
it's
to
it'd
be
super
confusing
yeah.
C
C
B
B
Able
to
create
a
pretty
Universal
set
of
contents
for
that
template,
but
that'll
basically
amount
to
what
does
what
do
our
pre-built
dashboards
have
in
them?
One
of
the
things
I'm
thinking
of
is
active
users
over
a
time
frame,
probably
monthly
gitlab.
We
use
Mao
as
our
main
metric
for
tracking
progress.
Many
companies
use
Dow
or
daily
active
users.
So
I
think
that,
as
a
very
first
hello
world
example
would
resonate
with
the
audience
for
this
type
of
capability.
A
Okay,
brilliant,
so
that
that
sounds
to
me
like
the
whole
button
concept,
unless
it's
something
we
can
do
immediately,
sounds
like
literally
the
next
step
after
this,
if
that
makes
sense
is
very
shortly
afterwards.
We
would
we'd
add
that
if
we
find
that
we
can
add
if
we,
if
the
template
is
slightly
more
complicated
than
we
think
or
you
know,
the
schemas
take
longer
to
finalize.
C
B
B
Somewhat
talk
going
back
to
the
previous
design
on
the
instrumentation
setup.
What
would
you
all
think
about
putting
a
button
on
that
dashboard
page
that
says
you
know,
get
your
your
keys
or
get
your
tokens
or
something
similar
there
and
then
just
linking
back
to
this
page
from
from
the
dashboard
screen.
A
C
A
thought
what
we,
what
we
could
do
for
the
dashboard
configuration
is
almost
like
some
of
the
other
dashboard
apps
that
we've
been
using
like
Jutsu
and
a
cube
have
where
we
can
have
like.
On
the
right
hand,
side
always
have
a
button
available
where
it's
basically
like
viewer
connection
details
or
something
that
takes
you
to
this
page
or
like
set
up
your
connection,
so
that
no
matter
no
matter
where
you
are
on
product
analytics,
you
can
always
just
access
it
quickly.
B
A
A
Okay-
well,
let's
discussed
that
so
just
the
final
Design
This
is
base
taking
what
Tim
has
already
done
and
refining
it
a
bit
to
a
sort
of
the
MVC
level.
This
is
taking
the
the
tree
style
format,
because
I
know
eventually
we're
looking
at
having
some
kind
of
structure
to
these
dashboards.
So
this
is
just
that
first
iteration,
where
everything
is
a
just
a
single
layer,
tree
structure
with
a
title
and
a
description,
no
iconography
or
labeling,
or
anything
like
that
at
the
minute.
A
You
can
look
at
adding
that
as
a
future
stuff,
because
the
iconography
is
very
is
limited
to
just
gitlab
svgs
at
the
minute,
which
may
or
may
not
work
from
a
user's
point
of
view:
I,
don't
know
user
research
and
whether
it
makes
sense
for
them
as
well
right.
So
this
is
just
a
simplified
version
and
then
we
can
easily,
from
a
front-end
point
of
view,
transition
this
into
a
tree-like
structure.
Once
we
get
the
schema
definition
defined
on
how
that
would
work
from
a
sort
of
the
config
file,
conceptually.
B
C
Okay,
we
I
mean
there's,
there's
also
some
edge
cases
around
like
subdirectory,
that
we
still
need
to
figure
out
like
rope
mentioned,
that
will
go
into
a
schema
like
how
deep
do
we
allow,
because
something
that
Rob
and
I
discussed
previously
is
like
that
it's
potentially
a
vector
for
ddosing
gitlab.
If
we,
for
example,
just
allow
infinitely
deep
directory
to
to
be
created
here
with
the
infinite
number
of
dashboard
files
that
could
create
some
chaos.
So
we
probably
want
to
think
about
it.
B
C
A
B
Good
we're
thinking
in
that
that
line,
though,
because
we
should
always
have
limits
and
constraints
on
things
to
prevent
abuse
like
that,
so
good
thinking,
I,
don't
think
a
limit
there
might
be
10.
What
would
you
all
think
of
that
I
mean
that
seems
like
more
than
reasonable
in
terms
of
tree
depths,
where
any
legitimate
user
shouldn't
hit
it
I.
A
C
A
C
B
A
B
A
That's
pagination
limits
on
graphql,
the
API
graphql
API
and
they
could
only
have
one
dashboard
per
directory,
so
every
you'd
have
to
create
a
directory.
Then
a
yaml
file
within
that
directory.
It's
a
link
to
a
dashboard,
so
we
haven't
got
pagination
defined
on
here,
but
it's
something
we
can
add
as
we
get
to
that
sort
of
offering
to
users
that
next
level.
B
Well,
so
for
for
this
conversation
before
we
go
too
deep
on
abuse,
we
do
have
an
issue
to
do
a
Security
review
of
all
of
this.
We
should
have
a
similar
issue
if
we
don't
already
to
discuss
abuse
protections.
So
let's
say
that,
for
this
screen,
we'll
need
to
put
some
abuse
Protections
in
place,
and
we
can.
We
can
do
that.
Asynchronously
how's,
that
sound
yeah.
C
Yep
noted
as
a
action
item
we're
at
time.
We
still
have
the
discussion
on
how
the
MVC
issues
align
with
what
our
actual
MVC
vision
and
roadmap
is
that's
something
that
we
can
either
do
async
or,
if
you'll
feel
like
it.
We
can
always
make
this
a
weekly
meeting
for
now,
since
it
seems
like
we
have
a
lot
to
discuss.
C
A
B
A
Yeah
I
need
so
I've
created
issues
for
each
one
of
those
screens
already
and
linked
them
to
that
instrumentation
screens
issue
so
under
that
you'll
see
all
a
bunch
of
related
issues
which
are
tied
to
each
one
of
those
designs.
I
haven't
and
I
need
to
it's.
My
hardest
priority
is
to
fill
each
of
those
out
with
more
information
details
and
also
implementation
plans,
get
them
weighed.
Now.
We've
got
a
rough
go
ahead
for
the
majority
of
those
designs
just
before
small
tweaks.
A
C
No
I
was
I
was
just
about
to
ask
that.
Are
we
still
planning
on
using
that
whole?
You
know
issue
process
flow
because
you
talked
about
creating
implementation
plan,
because
I
think
it
would
be
useful
to
first
start
off
and
collaborate
on
you
know
validating
the
solution
or
the
problem.
The
problem
within
the
solution
and
taking
it
through
the
whole
the
whole
step
or
all
the
steps.
B
We
will
be
a
little
bit
more
lightweight
on
the
validation
phase,
just
because
we
don't
have
a
dedicated,
ux
or
ux
research
researcher
resource,
that's
a
mouthful
so
we're
going
to
have
to
get
creative
and
how
we
do
some
of
the
validation
that
can
be
done
with
either
just
a
conversation
with
some
potential
test
users
internally
or
some
of
it
will
need
to
be.
You
know,
we've
agreed
and
are
aligned
on.
These
are
the
problem
statements.
This
is
a
solution
to
that
problem
statement.
B
As
far
as
we
can
see,
it
might
not
be
perfect,
but
I
want
us
to
be
cognizant
of.
We
keep
iterating
forward,
not
necessarily
spending
all
our
time,
validating
that
what
we're
doing
is
perfect
before
we
move
it
all.
Just
because
all
of
these
things
we're
doing
right
now
are
two
way
door
decisions
V1.
If
anything,
there's
going
to
be
a
lot
of
follow-up
work
afterwards,
no
matter
how
much
validation
we
do
so
so
that's
how
I'm
gonna
look
at
our
planning
process
for
all
this
rope.
C
A
I
am
more
or
less
happy
either
way.
I'm
I
can't
remember
how
far
but
yeah
I
have
literally
just
chucked
in
proposals
on
each
step.
I've
not
filled
out
anything
else.
I
haven't
even
put
the
final
designs
on
each
issue,
yet
so
it's
probably
better
for
me
to
just
get
those
filled
out.
First,
I
guess
I
mean
in
terms
of
validation.
This
is
as
Sam
says.
This
is
of
the
this
is
version
one.
A
A
B
A
B
B
That's
sometimes
a
way
that
my
ux
counterparts
and
I
kind
of
explore
what
customer
Journeys
might
look
like
for
a
given
design
as
a
way
to
discover
oh
I,
get
stuck
on
this
screen
or
I
want
to
get
to
do
that
sort
of
workflow,
I
I,
don't
expect
you
all
to
put
those
together,
but
if,
if
you're
keen
on
becoming
a
figma
expert,
that
is
something
that
is
is
pretty
useful.
In
my
experience.
A
C
A
Only
thing
I'd
like
to
ask
is:
do
we
or
should
we
have
design
issues
in
the
various
epics
to
make
sure
that
we've
got
somewhere
to
do
the
next
steps?
Because
right
now,
we've
got
this
one
just
for
the
internal
handbook,
internal
preview
stuff.
But
then
we've
got
cluster
setup
manual,
cluster,
setups
automatic
picking,
regions
and
various.
B
A
Okay,
only
reason
I
ask
is
because
once
we've
got
this
done,
we're
going
to
have
six
odd
front-end
issues
to
start
working
on,
which
is
great
and
exactly
what
we
need.
But
then
we've
got
to
keep
that
pipeline
going.
So
we've
got
to
go
back
to
ux
and
start
looking
at
the
what
we're
going
to
do
next
and
keep
that
going
forward,
which
I
am
okay,
not
an
expert
in.
C
Oh
I'm,
good
yeah,
please
just
check
the
meeting
notes
to
make
sure
that
I
didn't
best
represent
anything
that
you
said,
but
yeah
thanks
thanks,
so
much
also
Sam.
For
for
your
time.
This
was
like
super
helpful
just
to
bounce
some
ideas,
and
you
know
make
sure
that
we're
aligned,
especially
if
you're
like
yeah,
ux
and
ux
and
product
needs
to
work
quite
closely
in
order
to
sorry
I'm
getting
a
cold.