►
From YouTube: 2021-09-13 Plan/Manage/Ecosystem weekly design review
Description
This week we discuss Service accounts, Persona research for Sys Admins, and Wizards / Onboarding systems.
00:00 - Service accounts discussion
24:42 - Persona research for Sys Admins
26:51 - Wizards and walk thru for setting up Issues
A
A
A
A
So
from
here
you
would
be
able
to
return
or
create
a
new
access
token
based
off
of
whatever
you
want
here,
so
this
is
kind
of
like
the
first
iteration
on
how
this
would
work
and
I've
already
gotten
a
bunch
of
feedback
from
some
other
folks.
So
I
had
some
other
interviews
lined
up.
These
are
all
internal
stakeholders
right
now,
tams
and
support,
and
my
front-end
engineering
manager,
but
there's
been
discussion
on
how
this
would
work
across
the
organization.
A
Yeah,
so
the
flow
is
definitely
different,
because
currently,
the
way
that
it
works
is
that
at
the
project
level
you
would
generate
an
access
token
first,
and
then
that
goes
and
creates
a
bot
user
that
nobody
ever
would
would
ever
see
unless
you
were
to
go
look
for
it.
So
that's
one!
That's
the
current
flow,
I'm
curious,
if
that's
a
logical
flow,
and
so
that's
what
I'm
going
to
try
and
validate
with
this
prototype
with
external
customers.
A
Also,
the
limitation
of
only
having
one
token
per
user
is
what
we
currently
experience.
So
the
this
iteration
would
allow
us
to
associate
various
tokens
for
a
particular
or
individual
bot
which
would
allow
more
flexibility
and
future
growth.
So,
if
I
want
to
say
I
have
a
security
bot
and
it
has
a
defined
role
and
a
defined
task,
and
in
the
future
we
have
some
sort
of
new
feature
implementation.
B
A
So
right
now,
users
are
having
to
create
a
user
seat
that
takes
up
a
billing
seat,
and
so
it's
not
necessary
because
these
bots
never
interact
with
the
environment.
They
never
interact
with
the
platform
and
strictly
they
get
into
the
system.
With
their
token
they
do
a
task
and
then
that's
it
so
having
them
pay
for
that
seems
kind
of
unfair
other
organizations.
Don't
have
that
also,
so
we
want
to
try
and
help
that
as
well
as
offer.
B
C
I
don't
have
a
ton
of
feedback.
Unfortunately,
my
wi-fi
froze
in
the
middle
of
your
presentation
and
I
had
to
switch
to
a
different
wi-fi,
so
I
missed
a
portion
of
it,
but
it
seems
like
what
you're
trying
to
accomplish
is
understanding
or
validating
if
it
is
valuable
for
the
user
to
have
multiple
tokens
per
bot,
correct.
A
A
D
D
A
Yeah,
that
was
one
of
the
that
was
one
of
the
feedback
points
that
I
had
in
my
discussion
is:
how
does
somebody
save
this?
Is
there
a
download
button?
Is
there
a
copy
paste?
Something
like
that?
So
I
definitely
want
to
iterate
on
that
and
figure
out.
What's
the
most
logical
solution
for
that,
because
this
is
a
one
directional
thing
only,
you
can't
come
back
to
it
and
look
it
up,
because
it's
always
a
security
problem,
so
I
want
to
find
out
or
I'm
open
to
suggestions
if
you
have
feedback.
A
D
I
would
wonder
about
the
security
of
it
as
well,
downloading
it
or,
if
it's
just
a
code
that
we
can
copy
to
clipboard
and
there's
a
way
that
we
can
salt
that
in
a
secure
situation,
I
would
hope
I
would
imagine-
and
maybe
we
haven't
gotten
there
and
we
can
contribute
this.
But
in
our
design
system
we
would
have
like
a
little
clipboard
icon
or
something
that
goes
next
to
the
feed
or
attached
to
our
field
or
attached
to
the
field.
That
sort
of
thing.
D
A
A
an
icon
button
what
we
would
have-
and
I
would
just
use
that
copy
function
for
it
and
that's
what
I
was
thinking
is
that
for
our
our
first
mvc
is
just
let's
try
that
and
get
feedback
on
it
to
see.
If
this
is
a
logical
thing,
because
the
way
that
it
would
work
is
that
you
would
take
that
access
token
and
put
it
into
your
code,
and
so
you
would
have
two
windows
up
and
then
you
would
move
on
with
your
task
and
my
assumption
is:
that
would
be
the
logical
process.
C
A
A
D
C
A
Yeah,
so
basically
I've
skipped
that
frame
in
this
prototype
in
this
wireframe.
So
definitely
I
need
to
add
fidelity
for
that
and
have
that
screen
so
clicking
here
would
give
them,
or
this
would
be
grayed
out
clicking.
It
would
give
them
a
generic
name
and
this
would
be
opened
available,
but
that
also
brings
the
question:
is
this
necessary?
Do
they
need
to
create
the
container
or
the
account
first
and
save
it
before
going
on,
or
can
they
create
the
token
in
the
same
process?
So
I've
clicked
on
created
a
name?
A
B
A
B
A
A
So
yes,
and
no
so
if
I
go
back
or
at
the
start,
I
can
create
an
account.
I
can
click
and
create
a
name
and
save
it
and
I'm
done,
but
I
have
not
given
it
an
access
token
and
that's
where
I'm
saying
does
that
make
sense?
Should
it
actually
just
be
one
unified
process
where
you
create
the
access
token
and
give
it
a
name?
At
the
same
time,
you.
D
D
Can
this
actually
be
one
separate
one,
one
unified
process
as
well,
and
then
and
then
the
one
thing
that
I
also
wanted
to
jump
in
on
before
I
be
quiet
since
I
interrupted
alexis,
is
the
the
way,
the
buttons
the
action
buttons
jump
from
top
top
right
to
bottom,
to
top
right
to
bottom,
and
that
could
be
solved
with
a
unified
sort
of
flow
as
well?
That's,
that's
it
sorry.
Alexis.
B
A
A
Yeah
exactly
I
don't
know
why
I
don't
have
any
groups
or
projects
but
yeah
like
so
there's
in
cases
where
we
have
a
lot
of
content
and
there's
the
save
is
like
somewhere
down
here,
like
actually
several
scroll
pages
down,
and
I'm
trying
to
think
of.
Is
there
a
better
way
of
doing
this,
because
it's
such
a
very
specific
action,
the
idea
of
a
wizard?
A
I
think
we
need
to
investigate
more
as
an
organization,
because
I
know
there
are
cases
for
it
and
it's
not
really
been
discussed
beyond
growth
and
mate
was
talking
about
this
a
while
back
in
terms
of
generating
a
wizard
or
a
process
to
onboard
new
users,
and
I
think
that
can
help
across
the
organization
for
things
like
this
right.
How
do
you
go
and
generate
this
sort
of
process?
A
The
one
thing
I
have
on
hesitation:
there
is
the
making
it
simple
enough
or
excuse
me
not
so
simple
enough
that
it
would
interfere
with
somebody,
who's
technically
competent
and
says,
like
I
don't.
I
need
the
token
type
and
they
type
scope
and
the
code,
and
I'm
done
right
instead
of
having
to
click
through
like
a
clippy
right.
D
There's
always
a
difficulty
in
in
daniel.
You
mentioned
it,
which
is
don't
alienate
your
pro
users
like
you,
want
to
make
everything
as
approachable
and
as
easy
as
possible.
But
at
what
cost?
And
you
know
I
I
don't
know
the
the
I
don't
know
the
the
metrics
yet,
but
you
know
in
these
areas
I
would
imagine,
you've
got
you're
more
pro,
more
sophisticated
user,
and
but
it
doesn't
mean
that
we
also
don't
need
to
accommodate
for
somebody
that
may
not
understand
this.
A
B
D
I
was
gonna
say
this
sounds
kind
of
like
this
is
setting
up
for
a
future
of
more
functionality
where
this
area
is
gonna,
see
so
maybe
setting
it
up
in
that
stepping
fashion.
Even
though
right
now
we
could,
we
could
probably
take
care
of
this
this
process
with
a
single
screen,
as
we
were
talking
about
before,
but
it
may
not
be
like
that
much
longer
and
sort
of
setting
the
user
up
for
a
stepped
process
might
be
good
in
sort
of
anticipation
for
the
user.
D
Those
that
spend
a
lot
of
time
in
this
area,
daniel
I'll
leave
that
definitely
up
to
you
on
sort
of
like
where
you're
seeing
the
future
of
this
going.
Do
we
want
to
just
unify
this
into
a
single
screen
and
make
it
simpler
or
easier
to
develop
and
easier
for
the
user
not
going
back
and
forth,
or
do
we
want
to
think
about
the
future
of
this
area
and
where
that's
going?
If
so,
a
stepping
function
may
may
be
something
to
set
up
for
the
user.
C
In
order
to
be
able
to
create
an
issue
and
the
specific
context
is
they
need
to
be
able
if
they
come
to
an
issue
page
the
issue,
tracker
page
or
issue
list
page,
and
they
have
a
group,
but
they
don't
have
any
projects.
They
don't
have
any
issues,
but
they
can't
create
an
issue
until
they
create
a
project,
so
there's
kind
of
a
multi-step
process
that
they
have
to
do
and
when
you're
on
boarding.
This
feels
especially
complex.
C
But
I
think
that
there
is
value
in
us
differentiating
between
the
two
types
of
processes.
If
we
do
start
documenting
it
in
pajamas,
because
there
are,
I
think,
you're
right.
I
think
there
are
different
approaches
there,
that
that
tend
to
happen
and
there's
a
difference
in
the
level
of
depth
required
for
the
user
interaction
versus
how
much
the
system
is
going
to
try
to
take
on.
I
think.
D
It
could
be
one,
however,
with
your
product
counterpart
and
us
obviously
think
about
where
this
is
going,
and
if
it's
gonna
get
really
complicated
or
several
steps
deep,
then
you
know
we.
We
need
to
sort
of
set
up
that
that
nbc
as
an
anticipation
of
that
complexity,
for
the
best
of
all
of
our
users,
both
pro
and
not
so
pro.
A
D
A
Yeah,
so
I
was
doing
where
to
go.
It's
now
gone
from
others
at
the
bottom.
The
workspaces
stuff
there's
been
no
persona.
Research
on
sysadmins,
which
I
thought
was
bizarre,
and
so
we're
doing
that,
and
I
was
curious
if
anyone
could
give
help
or
feedback
on
feedback
sessions
come
and
the
persona
or
not
the
personas,
the
testers
we
got
there
and
if
I
know
alexis
you
had
done
one
recently,
if
you
have
tips
on
how
to
generate
like
a
list
of
people
to
talk
to.
B
On
user
testing,
I've
had
really
good
luck
with
just
like
having
kind
of
I
don't
know,
not
a
vague
screener
but
basing
it
on
what
they
do
in
their
role
every
day.
So
not
trying
to
be
too
specific
around,
like
the
title
of
their
role,
but
like
here
are
some
kind
of
like
general
jobs,
select
the
ones
that
you
do
and
trying
to
be
kind
of
picky
there.
But
that's
really
the
only
place,
I'm
super
picky
and
I
don't
care
about
their
role.
A
B
And
then
afterwards,
like
even
asking
on
user
testing
like
hey,
if
you're
interested
in
talking
with
us
still
can
you,
you
know,
write
your
email
things
like
that,
and
I've
had
a
few
people
ask
to
do
more
tests,
so
I've
actually
had.
I
feel,
like
sometimes
better
feedback
on
unmoderated
testing
on
user
testing
than
they
have
with
our.
Like.
First
look,
I
don't
know
what's
going
on,
but
I've
loved
it
so
far.
I
can
help
you
with
screeners,
but
it
sounds
like
that's
not
your
issue.
So.
C
C
C
Okay,
one
of
my
engineers
reached
out
and
said:
did
we
know
that
we
are
advertising
for
jira
issue
tracking?
If
someone
has
a
group
but
no
projects
and
no
issues
on
the
issue
tracker
page,
but
we
are
not
advertising
to
create
a
gitlab
issue,
so
we're
saying
create
a
jira
issue,
but
not
a
gitlab
issue
which
isn't
really
what
we're
saying,
but
it's
kind
of
implied,
because
we
don't
have
an
explicit,
create
issue
button.
C
So
it
was
a
good
point,
but
it
made
me
realize
that
the
reason
that
we
don't
have
a
create
issue
button
here
is
because
they
don't
have
a
project,
and
so
that
led
me
to
think
well.
We
really
need
to
establish
kind
of
the
the
process
that
they
need
to
go
through
and
again,
I'm
not
proposing
this
graphic
or
this
verbiage
necessarily,
but
just
trying
to
articulate
to
the
user
that
there's
a
multi-step
process
that
they
need
to
do
in
order
to
see
issues
at
all.
C
Here
I
also
raised
the
question
of:
is
there
value
in
even
showing
the
issue
tracker?
If
you
don't
have
any
projects,
because
you
don't
have
a
project,
you
can't
have
issues
because
issues
are
created
at
the
project
level.
They
may
surface
at
the
group
level,
but
they
are
created
at
the
project
level.
So
if
you
don't
have
any
projects,
why
even
show
the
issue
tracker
feature
to
me?
C
So
that's
something
that
we're
kind
of
working
through,
but
my
thought
was
initially
if
we
do
keep
the
current
functionality
and
just
try
to
improve
this
page
for
nbc.
While
we
research,
whether
or
not
we
should
even
have
issues
shown
that
we
would
first
encourage
them
to
see
that
this
is
a
multi-step
process
and
that
first
they
need
to
create
a
project
and
then
second,
they
can
create
an
issue
from
that
project.
C
This
actually
led
me
down
this
kind
of
rabbit
hole
of
looking
at
onboarding
in
general
when
it
comes
to
creating
an
issue
as
it
relates
to
groups
and
projects,
and
I
think,
there's
a
lot
of
opportunity
there.
So
I
did
create
an
onboarding
issue
and
spoke
with
the
growth
team
and
they've
been
doing
some
research
on
it.
So
I've
gotten
some
good
feedback
there,
but
I
think
for
just
mvc.
C
Is
there
a
better
way
that
we
can
articulate
that
this
is
something
that
they
would
need
to
do
this
multi-step
process
in
order
to
see
issues
here,
so
this
was
kind
of
my
first
stab
at
it.
But
I
I
really
think
that
we
do
need
to
have
something:
that's
a
bit
more
standardized
in
terms
of
like
a
multi-step.
C
C
In
this
case,
you
would
have
gone
to
the
issues
page,
the
like
issue
list
page,
but
you
don't
have
any
projects.
You
can
still
view
so
like
if,
if
I'm
in
an
issue
here,
it
would
be
this
page,
but
there
are
no
projects.
Therefore,
there
are
no
issues.
If
you
don't
have
a
project,
you
can't
have
an
issue,
so
there
are
no
issues,
but
that's
again
my
thought
is:
why
even
show
this.
D
B
C
C
C
C
D
A
Like
it
was
preemptive
before
they
figured
out
the
in-between
step
by
saying
I
have
no
project,
why
am
I
showing
you
lists,
because
we
still
have
issues
attached
to
the
project
object
and
now
they're
attached
to
the
group
object
which
doesn't
have
the
project
so
now
you're
in
this
weird
limbo
space?
So
to
me
it
feels
like
a
book.
A
D
A
B
C
A
It's
okay,
I'm
at
the
group,
I'm
in
my
issues,
list
yeah,
there's!
No
way
that
I
would
imagine
clicking
an
issue
here.
So
to
me.
This
feels
like
a
bug.
Why
am
I
seeing
this
when
I
can't
do
this
and
it's
like
okay?
Well,
you
can
do
this
thing,
but
you
need
to
create
a
project
first,
I'm
like
well.
Why
am
I
not
seeing
a
to
create
to
use
the
issue
tracker?
You
must
create
a
project
blah
blah
blah
need
to
be
improved
and
solved
in
a
project.
A
C
Agree,
and
actually
that
was
something
else
that
I
added
into
the
verbiage
for
the
proposed
change
that
I
made
was
a
little
bit
of
explanation
as
to
why
that's
even
relevant,
but
I'm
pretty
sure
that
that
page
has
been
there.
It's
just
most
people
don't
come
across
it
because
most
of
us
have
projects,
and
so
we
see
projects
and
issues
and
don't
usually
come
across
the
screen.
But
an
engineer
came
across
it
recently,
potentially
testing
it
was
alex.
A
C
A
A
C
Yeah,
I
think
it's
probably
one
of
the
two.
That
being
said,
it
sounds
like
there's
already
an
mr
in
place
to
give
the
ability
to
create
an
issue
from
this
view,
in
which
case
the
empty
state
language,
I
would
expect,
would
be
very
different
than
hey.
You
got
to
create
a
project
first,
it
would
actually
just
be
create
some
issues
here
in
order
to
see
something.
So
we
had
already
started
talking
through
proposed
language
for
the
create
a
project
and
then
created
an
issue
approach.
C
A
C
A
D
In
small,
and
not
only
that
and
the
way
that
it's
chosen
to
solve
the
issue
is
to
kick
them
out
to
jira
and
that's
questionable
at
first,
obviously,
but
then
at
the
same
time,
the
solution
is
in
that
really
itty-bitty
font,
and
it's
like.
Why
would
you
that's
not
very
helpful,
so
I
I
agree.
Yes,
I'd
like
to
be
tagged
in
on
it
just
so,
I
know
what
happened.