►
From YouTube: GitLab Growth experiment discussion: Adding the "Invite members" option in assignee dropdowns
Description
Product design issue for context: https://gitlab.com/gitlab-org/gitlab/-/issues/217921
Experiment tracking issue: https://gitlab.com/gitlab-org/growth/team-tasks/-/issues/299
Experiment dashboard (GitLab team members only): https://app.periscopedata.com/app/gitlab/696222/WIP-MP:-Experiment-Dashboard-:-Add-invite-members-to-assignees-dropdown
A
Perfect
so
we're
discussing
the
experiment
where
we
added
the
invite
members
option
to
the
assignees
drop
down,
and
this
is
the
original
issue,
and
this
is
the
tiny
change
that
we
actually
made
right
and
it's
this
drop
down
here.
Actually,
so
I'm
not
seeing
it
now
because
I'm,
I
guess,
I'm
not
part
of
the
experiment.
I
think
the
experiment
is
now
on
50,
I
believe
so.
Yes,
yeah,
okay
and
yeah.
The
whole
idea
was
to
have
this
option
sticky
down
there
right.
A
So,
even
when
you
scroll
to
the
users,
it's
always
there
and
if
you
search
for
someone
and
there's
no
matching
results,
it's
it's
even
more
noticeable
in
a
way
right
and
yeah.
We
wanted
to
do
this
because
we
were
working.
We
were
focusing
a
lot
on
increasing
the
invitations
to
gitlab,
and
this
was
just
the
first
part
of
it
where
we
showed
this
invite
option
to
the
gitlab
users
that
actually
can
invite
new
members
to
gitlab
right.
A
The
the
part
that
really
interested
us-
and
I
think
we'll
get
to
discuss
here
as
well
shortly-
is
what
happens
when
we
show
this
to
all
the
gitlab
users,
even
the
ones
that
can't
actually
invite,
but
maybe
they
could
request
an
invitation
and
then
that
invitation
would
then
be
confirmed
or
allowed
or
whatever
we
want
to
call
it
right
so
yeah
this
is.
This
is
the
design
I
still
have
the
prototype
here.
Does
it
still
work?
A
It
should
yeah
it's
still
in
sketch
because
we're
not
using
sketch
anymore
yeah,
and
this
is
the
result.
Yes,
this
was
the
mvc
where
we
just
linked
to
the
settings.
Members
page
what
we
envisioned
further
down
the
road
was,
it
would
trigger
that
in
the
invite
a
member
model
right,
so
it
doesn't
need
to
go
to
a
separate
page.
You
can.
Basically,
you
could
basically
invite
new
members
to
that
project.
That
you're
in
from
any
page,
like
you,
know,
an
issue
in
a
merge
request,
whatever
right
that
was,
that
was
the
idea.
Basically.
A
B
A
B
B
So
when
we
looked
at
the
actual
funnel
of
users
that
were
in
the
experiment,
we
only
saw
a
0.1
click-through
rate
on
users
that
were
shown
the
invite
option
in
that
drop
down
to
actually
clicking
to
invite-
really,
that's
you
know,
obviously
quite
a
low
click-through
rate
or
for
specific
sorry
for
event
count.
So
this
is
raw
event
totals
when
we
look
at
user
count,
so
per
user.
It
goes
up
to
0.13.
B
So
this
tells
us
you
know,
because
people
are
assigning
multiple
issues,
so
they're,
seeing
this
multiple
times.
So
in
the
one
of
the
issue,
one
of
the
tracking
issues
mate
had
some
really
good
points
around
that.
You
know
this
isn't
an
experience
that
users
are
going
to
do
all
the
time
where
they're
not
constantly
going
to
invite
from
this
location,
but
it's
kind
of
an
added
benefit
and
we
don't
have
user
id
tracking
on
front
end.
B
So
we
can't
tell
this,
but
one
of
our
hypotheses
is
that
new
users
or
new
groups
may
be
more
likely
to
find
this
valuable,
because
they're
still
actively
inviting
their
team
yeah
versus
an
established
group
may
only
use
this
on
an
occasion
because
they
have
the
majority
of
their
team
in
their
account.
But
it's
still
an
added
benefit.
B
B
So
to
me,
this
tells
us
that
this
is
a.
This
is
a
good
experience
for
our
users,
they're
not
going
to
do
it
all
the
time,
but
it
is
definitely
adding
value
to
the
overall
adoption
rate
of
github.
A
Yeah-
and
that
was
exactly
the
idea
right
early
on
where
someone's
is
starting
to
adopt
gitlab
and
especially
focused
on
groups.
We
want
to
make
it
as
easy
for
them
to
invite
new
users.
That
was
exactly
the
idea.
I
was
expecting
that
existing
groups
wouldn't
be
using
this
as
much
so
it's
really.
We
don't
have
data
to
to
prove
that
right.
New
user,
new
groups
versus
existing
groups,
probably.
B
It
doesn't
improve
the
new
user
experience,
but
since
we
don't
have
user
id
tracking
on
front-end
events,
you
know
we
can't
look
into
this
experiment
and
understand
who
the
users
are,
of
course,.
A
Yeah,
okay,
so
maybe
it's
worth
in
a
future
experiment
to
do
that,
just
so
that
I
mean
it's
a
it's
a
valuable
learning
for
us.
It's
an
assumption
right
now,
but
if
we
can
confirm
it,
that
would
be
a
really
good
learning
for
us,
so
groups
early
on
are
much
more
likely
to
invite
new
users
and
the
easier
we
make
it
for
them,
the
more
they
do
it
basically
right.
B
Yep-
and
that,
and
my
part,
my
thinking
around
this
too,
is
as
well
is
that
we're,
I
think,
we're
adding
to
the
user
experience.
You
know
it's
not.
We
know
it's,
not
an
action
they're
going
to
take
all
the
time,
but
it
at
the
right
moment
in
time.
It
makes
it
easier
for
them
to
invite
somebody,
especially
now
that
we're
going
to
implement
the
modal.
B
It
means
they
won't
be
removed
from
their
issue.
They'll
just
have
the
modal
appear,
they
can
invite
the
person
and
then
go
back
to
work.
So
I
think
we're
going
to
further
improve
the
experience
with
the
modal
and
maintain
one
point
that
you
made
was.
One
of
our
questions
was
what
are
do
non-admins
think
about
this
experience.
So
if
we
think
about
our
overall
users
on
gitlab.com,
the
vast
majority
of
them
are
not
admins.
Yeah
admins
make
up
a
small
percentage
of
our
users
and
that's
the
users
that
are
really
in
this
funnel.
B
So
what
we've
this
experiment
is
still
live.
What
we're
doing
is
showing
that
same
experience
of
clicks,
invite
from
the
assignee
drop
down,
but
there's
a
a
message
that
says
this
feature:
isn't
quite
ready
for
you
yet
just
to
understand
are
non-admins
interested
in
the
ability
to
potentially
request
somebody
to
be
invited.
B
This
could
be
a
really
good
piece
of
work
for
us
in
the
future
because
it
unlocks
potentially
a
ton
of
user,
invites
in
the
future
or
even
access
to
trials
or
upgrades
where
team
members
can
request
their
admin
to
do
a
particular
action,
and
this
experiment
was
just
turned
on
the
other
day,
but
so
far
we're
seeing
a
1.27
click-through
rate
for
you
for
non-admins
clicking
that
invite
option.
So
that
is,
you
know,
127,
like
127
percent.
Okay,
did
that
math
right?
I
forget,
but
yeah.
A
B
Yeah
this
is,
I
believe
this
is
a.
This
is
a
this
is
a
unique
users.
Okay,
so
it's
it's
equivalent
to
this
chart
here.
Okay,
so
for
advent
we
had
a
click-through
rate
of
0.13
and
so
far
on
this
very
new
experiment,
we
have
a
1.27
click-through
rate
for
non-ad
interesting
interesting,
that's
a
lot
higher!
Actually,
it's
a
lot
higher,
so
I
think
I
think
this
this
adds
to
some
of
our
work
that
we
have
in
in
research
around
what
what
should
this
experience
look
like
for
non-admins?
B
A
Yeah
yeah
exactly-
and
this
is
this
is
something
I
started
to
think
a
while
ago,
and
this
is
why
we're
running
this
experiment
right,
where
we,
basically
after
they
clicked
this,
invite
members
link.
We
showed
them
a
model
where
we'd
say
hey.
This
feature
is
not
available
yet,
and
there
was
some
pushback
from
from
some
people.
A
It's
kind
it
kind
of
sucks
to
launch
an
experiment
like
that
right,
where
we're
not
actually
delivering
any
anything,
we're
just
trying
to
experiment
to
learn
something,
but
I
think
the
the
possibility
of
learning
here
is
so
huge
that
it
in
this
case
it
was
worth
it
because,
as
you
said
now,
we
can
think
about.
You
know
asking
non-admin
users
for
free
trials,
asking
non-admin
users
or
non-advanced
users
asking
admins
for
invitations,
and
this
will
also
have,
I
believe,
an
impact
on
the
early
stage.
Adoption
of
groups
when
they
start
adopting
gitlab,
basically
right.
B
I
couldn't
agree
more
and
I
think
it's
one
of
those
one
experiments
where
it's
a
really
interesting
research
moment
for
us,
and
you
know
we
would
never
roll
this
experiment
out
to
a
hundred
percent
to
show
non-admins
this
ability
to
invite
with
just
a
modal
saying
the
feature's,
not
ready
yeah.
We
have
it
out
to
20
right
now.
A
It
was
exactly
because
of
that,
because
I
knew
that
this
kind
of
work
would
be
huge
right.
You
need
to
think
about
the
whole
experience.
What
is
it
like
when
someone
asks
an
admin
user?
Hey?
I
want
to
invite
this
person.
What
does
the
interface
look
like?
What
is
the
email
notification
like
all
these
things?
Right?
It's
not
a
simple
thing,
so
we
better
be
really
sure
that
our
users
want
to
do
that
before
we
invest
the
energy
and
timing
and
development.
B
On
top
of
that,
we
also
have
to
think
of
the
other
side
of
the
equation
of
what
does
the
admin
experience
look
like
requests,
and
how
do
we
think
about
an
admin
of
a
large
instance
that
may
get
many
requests?
Yeah
there's
a
lot
of
work
there,
but
I
think
this
this
experiment
so
far
is
very
much
justifying
that
it
is
absolutely
worth
our
time
to
invest
in
it.