►
From YouTube: UX Showcase - Project Specific 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
Cool
so
hi
everyone,
I'm
emily,
and
I'm
a
designer
on
the
growth
team,
and
today
I'm
going
to
share
our
ios
specific
onboarding
that
we're
doing
on
the
activation
side.
A
So
the
problem
that
we're
kind
of
facing
here
is
projects
are
overloaded
with
options
when
configuring
stage
integration
at
gitlab,
so
we're
kind
of
onboarding
we're
giving
you
all
the
options
to
start
with.
We
haven't
really
tested
out
doing
very
specific
onboarding
for
the
projects.
You're
doing
so
there's
a
lot
of
actions.
Users
can
take.
A
This
can
get
sort
of
overwhelming
and
we
should
really
determine
what
the
user
is
building
and
help
guide
them
through
the
value
that
gitlab
can
add
to
their
application,
so
in
particular,
setting
up
for
ios
does
take
additional
steps.
So
we
thought
this
was
a
perfect
place
to
start
just
getting
them
set
up
for
a
project
with
ios.
A
So
the
hypothesis
here
is,
if
we
know
a
user,
is
building
an
ios
application,
so
we
scan
their
project.
We
know
that
then
we
should
update
their
first
time,
experience
to
guide
them
through
a
specific
setup
so
that
they
can
get
started
with
their
project
quickly
and
with
without
the
additional
noise
that
might
show
up.
A
So
really.
Where
do
we
start
with
this?
In
growth?
We've
been
working
with
verify
onboarding
very
closely,
and
this
seemed
like
the
best
place
to
start
so
start
with
onboarding
configuring
a
pipeline
and
setting
up
a
runner.
We
could
build
on
what
was
already
successful
for
onboarding
there
and
just
adjust
the
experience
to
be
a
bit
more
ios
specific.
A
A
So
we
wanted
to
get
involved,
everyone
that
could
be
helpful,
so
want
to
give
a
great
shout
out
to
nadia,
gina
and
marcel
for
jumping
in
being
there
from
the
very
start,
helping
me
bounce
ideas,
just
get
me
on
the
right
track.
Give
me
the
context.
I
needed
to
build
a
great
onboarding
journey
here
and
then
additionally,
I
wanted
to
thank
my
design
pair
becca
who's
been
helping
me
just
go
through
the
flows
from
fresh
eyes
after
I've
been
staring
at
them
for
a
while.
So
before
I
even
jumped
into
this.
A
So
the
first
thing
we
did
was
kind
of
figure
out
the
flow,
so
we
realize
once
they
have
this
project
set
up
and
the
user
navigates
to
like
the
empty
stage
pipeline
page
they're,
ready
to
use
verify.
We
want
to
decide,
do
they
have
runners
available?
Do
they
not
have
runners
available
and
if
they
don't
have
ios
runners
available
guide
them
through
that
setup
and
then
when
they
go
to
configure
a
pipeline
guide
them
through
the
setup
for
pipeline
for
ios.
A
So
we
went
through
a
few
different
iterations
of
this,
but
landed
on
this
updates
to
the
pipeline
zerastu
page.
I
also
added
the
full
design
here
for
anyone
to
take
a
look
at
after.
But
what
we'll
really
do
is
break
this
down
into
two
sections.
A
So
when
they
land
on
this
page,
we
guide
them
to
set
up
a
runner
if
they
don't
have
one
available
yet
and
then,
if
they
do,
we
guide
them
through
configuring,
a
deployment
pipeline
and
then,
if
they're,
just
someone
who
doesn't
need
a
guide,
they
just
want
to
jump
right
in.
We
provide
them
with
the
ios,
with
fast
lane
template
or
if
they're,
not
building
for
ios.
If
they're,
this
isn't
what
they're
looking
for,
they
can
always
kind
of
revert
back
to
the
original
empty
state
page
and
get
all
the
templates
they
need.
A
Then
the
second
thing
was
the
runner
setup.
We
wanted
to
kind
of
keep
mvc
simple
use.
What
was
already
existing
so
for
this?
We
were
just
going
to
bring
up
the
existing
install
runner
modal
that
you
find
on
the
settings
page
with
an
additional
pop
over
kind
of
like
let's
get
started,
setting
the
runner
up,
giving
them
some
additional
context
on
this.
So
here
they'll
be
able
to
set
up
their
mac
os
runner.
They
get
the
instructions.
A
We
also
provide
them
with
the
token
here
which
we
don't
on
the
modal
in
the
runners
page,
because
it's
already
on
that
runner's
settings
section
and
then
they
can
get
started
with
that.
So
once
they
have
that
set
up,
they
click
close
and
we
notice
they
have
a
runner
ready.
A
Then
we
move
to
the
next
one,
which
was
that
second
box
they
can
click
on,
which
is
the
pipeline
configuration
walkthrough.
So
this
one
did
take
a
lot
of
back
and
forth.
We
got
engineering
involved
here,
seeing
what
we
could
do.
What
was
the
simplest
way
to
walk
users
through
pipeline
configuration
the
first
time
and
we
landed
on
kind
of
testing
out
a
second
version
of
the
drawer
that
already
existed
and
just
more
of
a
stepped
approach.
So
users
could
kind
of
go
through
the
steps
one
by
one.
They
could
reopen
the
steps.
A
At
any
point,
the
reason
we
decided
to
move
for
the
drawer
versus
something
like
a
pop
over
here
or
like
a
modal
is
because
the
drawer
lets
them
have
the
context
on
the
right
side.
But
then
they
can
also
work
on
the
template,
as
they're
going
so
they're
not
losing
context
there
as
they're
going
through
this
this
design
and
then
once
they
get
to
the
end.
We
just
prompt
them
to
hit
commit
and
then
their
pipeline
configuration
for
ios
is
complete.
A
And
then
we're
thinking
what
happens
if
they
don't
want
on
this,
they
can
kind
of
close
out
of
it
at
any
time.
We
just
give
them
a
pop
over
of
how
to
get
back
in
to
guide
them
through,
but
otherwise,
if
this
isn't
something
they're
looking
for,
they
can
close
it
out
and
kind
of
work
through
the
template
on
their
own
as
well.
A
It's
not
really
something
they
need
to
go
through
if
they
don't
want
to
so
the
next
steps
we're
going
to
do
with
this
is
we're
going
to
run
this
as
an
experiment,
so
50
versus
the
control,
which
is
our
general
onboarding
experience
with
users
building
for
ios,
and
then
we'll
run
this
until
it
hits
statistical
significance.
I
think
in
like
two
months
I
think,
is
what
we
were
saying
now.
A
If
this
experiment
is
a
success
and
we'll
be
measuring
conversion
rate,
verify
usage
and
invitation
rate,
we'll
look
into
doing
more
tailored
onboarding
for
other
projects
and
seeing
how
we
can
like
expand
this
into
the
drawer
on
the
existing
drawer
already
and
then
see
how
we
can
maybe
integrate
it
with
like
continuous
onboarding
and
a
few
other
things,
and
that's
it.
I
open
it
up
to
questions
now.
If
anyone
has
them.
B
Tina
has
the
first
question:
I
was
I'm
mid
typing
sorry,
but
I'll
I'll
voice
it.
I
just
wanted
to
say
that
the
walkthrough
side
panel,
that
you
showed
within
the
the
pipeline
editor,
is
really
cool
and
what
I
was
gonna
ask
is:
how
did
you
end
up
landing
on
that
idea
of
using
that
side
panel?
Like
did
you
look
into
competitors
that
were
using
it?
I'm
just
wondering
how
just
curious
about
that.
A
Yeah,
so
I
kind
of
looked
into
it
through
a
few
different
rocks.
It
was,
I
think,
if
you
saw
at
the
beginning,
we
were
looking
at
doing
popovers
and
then
engineering
was
like
that's
a
bit
too
difficult.
We
can't
do
that
so
kind
of
went
in
this
side
drawer.
Actually,
I
have
to
give
it
to
becca,
because
we
were
chatting
about
it
during
one
of
our
design
pairs.
A
Looking
at
different
things,
you
could
do
for
a
walk-through
and
she's
like
hey
what
about
something
that
they
could
see
on
the
side,
but
then
they
could
also
edit
the
template
at
the
same
time.
So
they
have
like
the
same.
They
can
read
the
instructions
but
be
able
to
do
it
without
having
to
navigate
back
and
forth.
We
also
thought
that
was
a
really
good
idea
of
building
on
what
was
already
existing,
so
there's
already
existing
drawer
in
like
the
pipeline
editor.
A
Can
we
just
kind
of
build
on
top
of
that
for
mvc
and
see
what
we
could
do
so
that's
kind
of
how
we
landed
on
it
just
explored
a
few
different
options
for
walkthroughs,
seeing
what
was
already
existing
in
the
product
and
then
what
we
could
use
that
users
could
kind
of
edit
but
also
see
instructions.
At
the
same
time,.
A
Awesome
also,
I
do
have
to
apologize.
I
only
have
like
my
computer
screen
right
now,
so
I
can't
see
the
agenda
sharing
this,
so
I
can't
see
all
the
questions
available
there.
D
Yeah,
I'm
quickly
finding
out
that
I
am
nowhere
near
as
fast
as
typhus.
Is
you
guys
so
my
I?
D
I
have
a
former
life
in
ios
development
and
and
design,
and-
and
I
was
wondering
if
there
was
any
hypothesis
surrounding
like
the
fact
that
if
a
developer
or
a
company
of
an
ios
program
were
to
be
setting
something
up
in
in
gitlab
to
develop
an
ios
app
that
we
could
sort
of
tailor,
we
could
use
like
the
human
interface
guidelines
from
apple
to
sort
of
tailor
the
experience
to
them.
D
Given
that
and
again
I
say,
there's
a
lot
of
like
assumptions
that
I'm
making
here
but
like.
If
you
are
developing
for
the
ios
platform,
you
have
to
do
it
on
a
mac
and
so
there's
a
lot
of
assumptions
that
these
are
primarily
mac.
Users,
primarily
like
see
single
ecosystem
developers
and
they're
really
used
to
that,
and
we
could
use
that
as
sort
of
leverage.
The
human
interface
guidelines.
A
Yeah,
so
that's
a
very
interesting
thought
on
this.
We
were
kind
of
doing
this
setup,
mostly
just
getting
them
started
up
with
like
a
pipeline
running
and
getting
their
runners
set
up,
but
I
think
going
forward
if
this
is
a
success,
I
think
there's
a
lot
more.
We
can
add
to
these
tailored
experiences
with
like
best
tips.
They
could
use
just
keep
adding
to
it
as
we
work
through,
like
the
guided
onboarding
and
also
if
this
is
a
success
too.
A
I
think
we
can
open
it
up
to
like
android
setting
up
for
android
projects.
How
do
we
do
onboarding
much
more
specifically
than
we
are
right
now,
so
I'm
quite
excited
for
kind
of
all
the
things
this
opens
up
to,
and
maybe
we
need
to
do
a
bit
more
research
to
see
what
else
we
should
add
into
it.
But
I
like
the
idea
of
where
it's
going.
E
Cool
it
looks
like
I
have
the
next
question.
I
was
hoping
you
could
say
something
more
about
at
the
end
you
mentioned
until
it
reaches
significant.
No,
that's
not
a
word
statistical
significance.
E
How
does
the
growth
team
determine
what
statistical
significance
looks
like
like?
Is
it
the
same
metric
across
experiments
or
does
it
depend
on
the
experiment.
A
Yeah,
so
it'll
depend
on
the
experiments
like
how
many
people
are
going
through
it.
The
measures
we'll
doing
so
like
conversion
rate,
verify
usage
invitation
rate
is
the
one
we're
specifically
looking
at
for
this
and
this
particular
experiment.
I
know
we'll
have
to
run
for
quite
a
bit
longer,
because
statistical
significance
also
depends
on
how
many
users
are
going
through
the
flow,
and
this
flow
is
a
very
like
specific
grouping.
A
So,
like
people
setting
up
ios
projects,
which
we
know
isn't
going
to
be
like
a
heavy
grouping
going
through
so
yeah,
it
changes
based
on
kind
of
what
measures
we're
looking
at
kind
of
how
many
users
are
going
through
the
flow
itself.
Some
hit
it
much
faster
than
others
and
we'll
just
tailor
it.
Based
on
that.
A
Yeah,
so
during
the
starting
of
experiments,
which
actually
this
is
a
goal
of
mine,
this
year
is
kind
of
get
more
into
like
experiment,
writing
and
helping
pms
work
with
like
what
we'll
be
actually
measuring.
So
some
of
these
measures
come
down
from
our
okrs,
so
it's
like
the
okr
that
growth
team
is
trying
to
move.
Some
of
them
are
ones.
We
want
to
look
through
to
see
so
yeah.
We
work
with
like
the
pms
on
helping
figure
out
some
of
these
cool.
C
E
Interesting
yeah,
our
team
is
going
through
like
road
map
planning
right
now,
and
there
was
a
question
in
the
template
that
came
up
about
kind
of
success
criteria
and
and
how
we
can
measure
that,
because
I
think
largely
we
tend
to
focus
on
you
know
is
the
is
the
feature
complete
like
it.
Has
the
design
been
through
solution,
validation
and
then
implemented?
But
I've
started
wondering
if,
if
there
is
anything
like
any
stats,
we
can
look
at
or
set
as
goals.
So
it's
something
I'm
curious
about
anyways.
E
C
E
C
I
mean,
if
you
want
to
chat
about
it
more,
you
have
to
kind
of
figure
out
what
are
the
right,
metrics
and
then
there's
a
process
for
creating
an
issue
to
request
to
have
all
of
that
set
up
and
instrumented.
C
Cool
okay,
thank
you
so
much
emily,
and
next
we
also
have
emily.