►
From YouTube: UX Showcase: New User Onboarding
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
just
want
to
confirm
everybody
sees
my
screen
right:
okay,
cool
all
right,
so
hi
everyone,
I'm
kevin
product
designer
in
growth
and
today
I'm
gonna
be
talking
about
new
user
onboarding,
whoops,
sorry!
So
before
we
go
ahead
yeah.
I
just
want
to
kind
of
point
that
onboarding
is
way
more
than
sign
up.
A
So
today,
I'm
just
going
to
be
talking
about
the
surface
of
this,
which
is
new
user
onboarding
and
what's
a
successful
strategy
at
this
point.
Well,
if
you
got
to
check
what
the
industry
is
saying
is
basically
try
to
get
people
to
your
product
value
as
fast
as
possible
and
remove
all
friction
on
the
way.
So
I
think
a
good
example
of
that
that
you
may
have
is
your
favorite
food
delivery
app?
They
probably
have
the
same
strategy
now.
The
problem
is
when
your
product
is
covering
the
whole
devops
life
cycle.
A
A
So
here
we
had
this
kind
of
four
tails
cards
and
the
main
one
was
going
to
create
a
project,
because
if
you
cannot
like,
if
you
don't
create
your
project,
then
it's
hard
to
access
most
of
the
features,
and
you
also
try
to
guide
so
with
this
little
helper
here
on
the
right
guiding
you
through
multiple
steps,
as
in
like
setting
a
project
creating
issues
creating
a
merge
request.
A
So
all
this
is
great
for
the
first
day,
but
then
what
well
then,
most
of
the
time
we
send
users
to
their
gitlab
documentation,
either
through
empty
states
or
through
other
links
within
the
app
which
kind
of
creates.
This
flow
of
people
are
inapp
trying
to
do
something,
but
then
we
send
them
elsewhere
in
our
gitlab
documentation
and
they
have
a
lot
of
decks
to
parse
and
then
have
to
go
back,
and
it
seems
that
it's
not
enough.
A
A
A
It
should
be
accessible
after
the
first
day
so
again
to
get
a
following
on
this
idea
of
continuous
onboarding
and
it
should
be
flexible
and
tailored
to
users
needs.
So
we
could
come
up
with
a
an
mvc.
A
It
was
actually
quite
big,
but
we
had
a
couple
of
yeah
main
ideas
and
the
one
that
stand
out
was
creating
a
sandbox
project,
mainly
because
it
was
a
good
opportunity
to
create
a
safe
space
where
you
could
experiment
with
the
features
without
having
to
worry
about
breaking
production
code
or
development
branches,
and
a
good
way
to
introduce
you
to
this
sandbox
project
would
be
the
issue
board.
A
A
A
So
once
we
had
this
idea,
it
was
like
okay,
so
where
to
start,
we
know
that
software
developers
are
our
main
personas,
but
we
kind
of
wanted
to
back
this
up
by
data
and
when
we
look
at
our
new
sign
up
by
role.
So
here
I
took
a
specific
period
that
happened
when
we
introduced
this
data
collection
to
when
we
started
working
on
the
onboarding
board.
We
clearly
see
that
software
developer
leads
away,
so
we
decided
to
focus
our
first
nbc
on
software
developer.
A
So
we
quickly
built
up
a
prototype
of
this,
where
you
had
a
little
helper
on
the
right
that
was
kind
of
introducing
you
to
the
project
through
the
issue
board
and
a
couple
of
tool
tips
to
guide
you
through
the
process
and
then
each
issues
were
divided
into
multiple
sections,
so
the
first
one
was
more
description
of
the
issue
and
then
the
second
was
next
steps
like
actionable
next
steps
that
you
could
do
within
the
app
so
moving
forward.
We
wanted
to
test
this
prototype
with
users,
so
we
started
with
user
testing.
A
We
could
recruit
10
non-gitlab
users
that
we
divided
into
two
groups.
So
five
person
had
this
experience
without
having
to
go
through
sign
up
and
five
others
had
to
go
through
sign
up.
The
reason
we
did
this
is
that
when
we
started
with
the
no
sign
up
flow,
basically
people
were
a
bit
confused
of
what
was
happening
like
directly
landing
on
an
issue
board
was
probably
not
the
best.
A
So
then
we
kind
of
added
the
sign
up
flow
to
all
that
and
we
managed
to
get
mainly
software
developers.
So
what
we
got
out
of
this
is
that
the
tooltips
were
working,
but
the
in-app
messages,
so
the
little
helper
on
the
bottom
right
was
not
adding
that
much
value.
A
The
next
steps
in
the
issues
were
working
very
well,
but
the
groups
versus
project
relationship
was
confusing
mainly
because
on
the
prototype,
without
the
sign
up,
we
were
asking
you
to
create
a
group
within
a
project
it
was,
it
was
yeah,
people
didn't
realize
what
was
a
group.
What
was
the
project
and
to
kind
of
solve
this,
we
try
to
iterate
on
the
prototype
and
adding
the
group
and
project
creation
to
the
sign
up
part
and
actually
worked
way
better.
A
Then
what
well
as
well
was
the
learning
by
doing,
instead
of
like
passing,
observing
and
then
yeah
about
the
issue
lying
some
people
kind
of
read
it
through
some
people
just
went
very
fast
on
it
and
knowing
that
they
could
come
back
to
to
the
project
was
was
a
thing
that
worked
well,
although
they
were
not
too
sure
at
this
stage
because
remember
they
were
non-get
lab
users,
so
they
had
no
idea
of
what
the
app
looked
like.
A
So
our
final
prototype
looks
like
this
so
like
I
said
we
added
the
group
and
project
creation
and
we
retained
the
tooltip
and
in
addition
to
this
yeah
sorry
this
is
a
gif.
So
it's
gonna
happen.
We
added
this
slide
with
the
novus
and
experience
split.
The
reason
we
did
this
was
to
trim
the
number
of
issues
on
the
board.
So
if
you
would
choose
novus,
you
would
kind
of
have
some
basic
things
that
was
going
to
tailor
to
software
developers.
A
A
So
we
ran
that
for
five
weeks
and
we
had
roughly
300
gay
people.
We
did
this
on
sas
and
we
wanted
to
see
the
the
impact
on
conversion
rate
stage,
adoption
and
user
retention,
so
the
learnings,
the
first
one
the
tooltips
were
actually
not
not
effective,
so
yeah,
the
user
testing
session
was
kind
of
pointing
out
that
the
tooltip
were
working
well.
A
But
what
actually
happened
during
the
ap
test
is
that
only
two
percent
of
the
people
that
were
enrolled
actually
reached
the
issue
board,
so
the
98
percent
of
the
other
users
were
banishing
elsewhere,
but
we
still
saw
an
increase
in
stage
adoption
and
mainly
in
create
release
and
verify
which
kind
of
fall
back
into
sorry
cascaded
into
new
user
retention.
A
So
we
roughly
had
six
percent
increase
for
30
days
that
observed
in
30
days
period
and
to
this
day
we
still
don't
know
how
this
impacted
conversion,
so
we're
still
trying
to
review
this,
but
it's
trending
upwards.
So
it's
positive
for
now.
A
This
one
is
a
bonus.
One
copies
key,
we're
still
trying
to
validate
this
one.
But
if
you
remember
the
previous
screen,
we
had
one
of
the
preview
screen.
Sorry,
we
had
this
split
between
novice
and
experienced,
and
the
distribution
actually
shows
us
that
most
of
the
people
that
were
enrolled
choose
novus.
A
A
Basically,
if
you
look
closer
at
the
screen
again,
that's
that's
my
hypothesis,
but
we
could
have
biased
them
toward
picking
one
option
over
the
other,
and
in
this
case
novus
has
this
cta
that
has
shown
me
everything
versus
experience.
That
is
showing
me
more
advanced
stuff
at
this
time
of
the
journey.
Maybe
you
would,
you
would
show
me
everything,
so
we're
basically
going
to
try
to
iterate
on
this
copy
and
see
if
it
affects
the
distribution.
A
So,
to
conclude,
this
is
still
a
success,
but
I
think
what
what
we
kind
of
learn
at
testing
this
at
scale
is
that
it's
probably
misplaced
in
the
user
journey.
Maybe
it
shouldn't
be
at
the
very
beginning.
Maybe
it
should
be
like
later
on
and
and
the
very
beginning
should
be
something
different
than
the
onboarding
board
and
basically
oops
sorry
looks
like
something's,
not
working.
A
Our
next
steps,
so
we
want
to
fill
in
the
blanks,
because
we
still
don't
know
this,
where
our
users
are
going.
What
are
they
doing
after
sign
up?
That's
a
massive
link,
and
actually
that's
really
good-
that
we
were
able
to
identify
this
through
the
a
b
test.
A
A
So
thank
you
for
your
attention
and
also
thank
you
to
everyone
that
worked
on
this,
because
it
was
a
massive
project
like
pms
designer
data
engineers.
It
was
a
lot
of
collaboration
breaking
across
like
so
many
months,
and
also
a
special
thanks
to
mate
for
driving
the
design
part
on
this.
I
think
it
was
really
amazing
to
have
embar
on
this.
Thank
you.