►
From YouTube: Invite user workflow review + Ideas to make it better!
Description
Matej walks us through his findings after researching the invite user workflow and shares some ideas to make it better. Contribute to the issue here -- https://gitlab.com/gitlab-org/gitlab/-/issues/214425
A
Okay,
can
you
all
see
it
perfect,
so
I
was
kind
of
wrapping
up
what
I
had
what
I
was
able
to
do
so
far
for
the
moving
the
invitation
member
invitation
form
into
a
model
and
how
that
could
integrate
with
other
parts
of
the
application.
I
was
trying
to
wrap
on
my
findings
so
far
today
and
I
did
that
in
a
comment
in
this
issue.
A
So
that's
the
main
issue
where
we
work
on
this
and
I
focused
I
decided
to
focus
on
three
scenarios
that
I
think
are
quite
real-life
scenarios
of
how
how
and
when
users
wanted
to
invite
new
team
members
to
kidnap
and
especially
kidnap
calm
and
at
first
I,
didn't
know
if
it
makes
sense
it's
valuable
to
create
user
journeys.
For
these.
You
know
tasks
because
we
already
worked
on
this
and
it
wasn't
this
issue
last
milestone.
A
This
is
the
one
that
we
cater
for
currently
the
past
right,
it's
relatively
simple
to
do,
and
then
the
other
two
are.
Let's
say
that
the
software
developer
wants
to
assign
an
issue
or
a
merge
request
to
a
co-worker,
but
they
are
not
an
existing
member
of
gitlab
yet
and
the
third
one
is
I
definitely
wants
to
delegate
delegate
a
task
to
a
non-existing
member,
so
they're
kind
of
similar,
and
they
work
one
way
to
another,
but
I
still
treated
them
as
separate
scenarios
and
I.
As
I
said,
I
excluded
the
first
one.
A
So
in
this
image,
I
did
only
top
level
view
of
inviting
on
existing
members
what
the
journey
is,
but
not
in
details
yet
so
what's
what
are
the
people
involved
in
the
scenario
and
what's
happening
right
and
what
are
what
I
realized
is?
There's
a
lot
of
waiting
time,
especially
for
this
second
scenario,
where
a
co-worker
wants
to
assign
something
to
you
know
someone
else,
because
they
need
to
ask
that
person,
the
deathly,
probably
the
the
owner
of
the
group
or
to
project
hey.
A
Can
you
invite
this
person
and
then
they
need
to
wait
so
that
that
person
invites
them,
and
when
that
person
invites
that
in
person
they
need
to
wait
so
that
they
know
receive
an
invitation.
They
sign
up,
they
accepting
the
patient,
then
the
person
that
invited
them
receives
notification
on
an
email
and
then
they
can
notify
that
first
person
hey
this
personal
joint
and
you
can
assign
work
to
them
right
and
when
it's
just
about
delegating
a
task.
So
it
starts
with
a
template.
They
will
need
to
invite
that
person
again.
A
They
need
to
sign
up,
accept
an
invitation,
then
that
person
can
receive
the
notification
and
they
can
assign
work
to
them.
And
then
they
that
new
person
receives
a
notification,
but
something
was
assigned
so
I
was
starting
to
think.
Is
there
a
way
to
eliminate
all
this
waiting
time?
Because
waiting
time
is
like
a
silent
killer
of
productivity
in
software
development
right,
you
can't
really
put
a
finger
on
it,
but
it
can
consume
so
much
time
if
you,
if
you,
if
you're,
not
careful
so
I,
created
more
detailed
user
journey
maps
for
both
scenarios.
A
So
yeah
a
bit
more
in
details,
what's
going
on,
they
need
to
you
know,
send
a
message
to
a
chat,
app
or
whatever
or
email
users.
Usually
it's
a
chat,
but
there's
this
waiting
time
and
it
could
be
just
a
couple
of
hours.
It
could
be
a
day
or
two.
It
depends
of
how
much
the
bottleneck
that
person
is,
that
owner
of
the
group
or
the
project
right
and
then
this
is
the
user
journey
of
the
dead
leads.
A
So
when
they
are
inviting
a
new
user
to
get
lab
the
first
in
the
first
session,
they
can
invite
them
and
then,
in
the
second
session
right
really
it's
not
the
same
session
because
they
need
the
other
need
to
wait
for
the
other
person
to
accept
and
sign
up.
They
can
actually
assign
the
work
to
that
person.
So
it's
quite
a
long
and
broken
process
as
well
and
yeah.
A
This
is
basically
where
all
the
waiting
time
comes
from
so
I
as
I
mapped
these
two
journeys
and
that's
why
I'm
glad
that
I
decided
to
map
these
journeys?
It's
because
I
had
two
main
ideas
that
came
out
of
that.
So
in
both
of
them,
the
green
ones
are
the
ideas,
and
two
of
them
were
good
users
assigned
issues
and
merge
request
to
pending
members.
A
So
we
already
have
the
notion
of
a
pending
member
when
you
invite
someone-
and
they
don't
accept,
yet
you
can
see
them
as
a
pending
member
under
member
management
in
project
settings
right.
Could
we
allow
users
to
assign
those
spending
members
to
merge,
requests
and
issues
and
the
other
one
would
be
good
non
owner,
but
also
among
guests
users?
Invite
new
members,
but
during
an
invitation,
would
need
to
be
approved
by
the
owner?
A
And
then
the
rest
is
pretty
much
right,
because
that
person's
estrus
identification
update
was
approved
and
then
another
notification
when
the
new
member
signed
up
and
up
and
up
and
accepted
that
invitation.
So
many
difference
is
instead
of
doing
it
in
separate
sessions
and
in
separate
steps.
Where
there's
a
lot
of
waiting
time
between
you
can
do
it
in
one
go
and
the
same
for
the
third
scenario,
which
is
basically
pretty
much
this
so
the
new
user
journey
Maps
or
the
potential
user
journey
Maps.
A
A
They
basically
can't
do
that
at
the
moment
at
all,
because
we
don't
allow
people
to
or
non-owners
to
invite
new
people.
So
you
can't
do
that
and
you
can't
assign
anything
to
a
pending
member
and
for
the
first
scenario
where
a
development
needs
delegated
tasks
among
existing.
Remember
again,
they
can
kind
of
do
that,
but,
as
we
saw
it
requires
two
sessions
and
a
bit
of
waiting
time,
and
you
know
people
forget
or
they
get
distracted.
So
I
read
the
experience
quite
low
at
four.
A
So
it's
basically
below
the
acceptable
mind
that
I
set
for
myself
and
the
likelihood
quite
high
on
six,
so
the
likelihood
to
lose
I
scored
it
at
seven
and
then
I
also
wrote
down
what
kind
of
things
we
should
do
to
improve
all
these
scenarios
and
for
the
first
one
is
just
increase
the
likelihood
of
inviting
members.
So
this
is
something
that
we're
looking
at
in
expansion
in
general
and
then
for
the
second
one,
add
the
ability
to
invite
for
non
non.
A
A
Right,
so
it's
not
I
get
to
sign
them
yet
because
currently
we
don't
allow
that,
but
the
invitation
was
sent
and
in
when
they
access
that
invitation.
They
will
that
be
able
to
assign
that
wishes
to
them,
but
in
maybe
more
distant
future.
Maybe
we
could
do
something
like
this
I
search
for
them.
They're,
not
there
I
invite
them
and
it
says
inviting
a
sign,
and
it
would
actually
do
this.
It
would
send
an
invitation
but
it'll
also
assign
to
that
person
at
the
pending
member
right.
A
A
B
In
your
mind,
what
would
happen,
let's
say:
I
invite
someone
who
doesn't
exist
and
they're
a
pending
assignee.
They
don't
take
any
action
and
for
whatever
reason
and
maybe
I
removed
them
after
a
while,
because
they
haven't
taken
any
action
once
they're
no
longer
assigned.
So
what
happens
to
their
invite?
Are
they
still
invited
I.
A
B
I
would
be
hesitant
to
have
that
invitation
flow.
Have
a
like
a
timer.
If
the
standard
one
doesn't
I,
don't
know.
I
I
worry
I
like
the
idea,
but
my
worry
with
actually
like
assigning
people
is
the
the
edge
case
of
where
you
assigned
someone
who,
like
doesn't
know,
gitlab,
exists
and
they're
like
what
does
this
get
lab
thing?
What
am
I
I?
B
B
They
still
there
no
longer,
and
maybe
we
need
to
handle
that
case
of
like
because
I
think
it
also
be
confusing
of
like
the
email
says,
you've
been
invited
in
are
assigned
as
the
owner
of
this
issue
or
whatever,
and
then
that's
no
longer
the
case.
We
might
need
to
explain
that
yeah,
but
I
think
like
because
also
if
the
end
result
is
like,
we
want
more
people
to
be
invited
and
using
gitlab
it'd
be
in
our
interest
to
maintain
that
invite,
even
if
the
assignment
no
longer
exists.
It's
true
yeah.