►
From YouTube: Insights walkthrough - Solution validation: Add data for multiple machines of a runner to admin area
Description
Gina Doyle (Senior Product Designer: Runner Fleet) shares insights from the solution validation study around adding data for multiple runner machines to the Runners page.
New Runner token architecture epic: https://gitlab.com/groups/gitlab-org/-/epics/7663
Research issue: https://gitlab.com/gitlab-org/ux-research/-/issues/2391
Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/388854
Dovetail insights: https://gitlab.dovetailapp.com/projects/4GWiutjf7vb492q1LoNfjO/v/1jBttXaiDyDGnUYmtRWjyu/present
A
Hi
everyone
I'm
Gina,
Doyle
and
I'm
a
senior
product
designer
for
the
runner
fleet
team.
The
runner
team
has
been
putting
a
significant
amount
of
work
into
a
new
token
architecture,
effort
for
runners
which
you
may
have
heard
about,
but
if
not
I'll
leave
a
link
in
this
recording
so
that
you
can
access
it.
A
A
So
with
the
new
token
architecture
work,
if
there
are
multiple
Runners
registered
with
the
same
authentication
token,
you
will
see
these
listed
as
machines
in
the
database
that
all
relate
to
a
single
configuration.
You'll
likely
see
this
the
most
in
Auto
scaling
scenarios,
although
this
makes
the
load
on
the
database
much
smaller.
We
assumed
that
introducing
the
term
machines
and
grouping
Runners
and
machines
in
this
way
would
break
mental
models
with
users
and
cause
more
confusion.
A
What
we
didn't
fully
understand
was
how
do
users
interact
with
machines
today
we
need
to
validate
the
problem,
so
we
took
a
step
back
from
solutionizing
and
went
to
research.
The
best
way
to
move
forward
was
to
meet
with
Runner
administrators,
who
are
using
Auto
scaling
Runners,
which
would
be
Docker
machine
or
kubernetes
executors
and
understand
how
their
job
to
be
done
relate
to
the
main
Runner
Fleet
job
to
be
done
about
managing
runners.
A
To
give
you
a
little
bit
of
insight
into
what
we
were
solutionizing
beforehand,
we
had,
let
me
stretch
the
screen
out.
We
were
listing
the
runner
and
the
table
and
then
saying,
if
it
hadn't
indicating
if
it
had
machines
by
using
the
two
and
this
icon
and
then
showing
machine
details
in
a
drawer.
We
did
end
up
using
this
for
a
little
bit
of
the
research
sessions
and
I
will
explain
why
very
soon.
A
So,
as
we
continue
on,
you
may
hear
me
use
the
term
Runner
managers,
a
runner
manager
acts
as
a
coordinator
for
auto
scaling
instances
and
can
create
many
Runners
when
scaling.
So
each
Runner
manager
shows
up
as
a
separate
Runner
and
the
runner's
table
today,
even
if
they
have
the
exact
same
configuration
details.
Sometimes
this
can
cause
clutter
in
the
UI,
because
a
huge
number
of
them
are
registered
at
once
and
maybe
like
only
one
of
them
is
contacting
gitlab.
A
So
for
the
study
we
met
with
mostly
internal
git
lab
team
members,
since
we
manage
shared
Runners
for
our
SAS
customers
as
well
as
One
external
Runner
administrator
and
the
sessions
were
formatted
as
a
split
between
understanding
how
users
interact
and
manage
Auto
scaling
runners,
highlighting
any
pain,
points
that
they're
facing
today
and
then
also
asking
them
to
complete
tasks
with
that
proposed
UI.
That
I
was
showing
for
Runner
machines.
The
reason
why
that
we
did
this
is
because
we
wanted
to
give
them
a
solution
so
that
they
weren't
designing
for
us.
A
We
were
ultimately
able
to
obtain
really
great
insights
from
the
study
that
increased
our
confidence
and
our
understanding
of
Auto
scaling
Runner
management,
as
well
as
which
terminology
is
best
to
use
moving
forward.
So
as
a
summary,
we
did
confirm
that
the
job
to
be
done
for
Runner
Fleet
do
apply
for
auto
scaling
and
non-auto
scaling
Runners.
We
also
found
things
like
the
term
machines
is
confusing
and
grouping
Runner
managers
is
useful
and
then
the
term
Runner
manager
is
something
that
users
are
familiar
with.
A
So
I'm
going
to
start
just
jumping
into
these
insights.
Now,
starting
with
this
first
one
users
need
to
compare
data
across
Runners,
whether
it
is
a
runner
group
of
runners
or
Runner
managers.
This
relates
to
the
jobs
to
be
done,
and
rather,
regardless
of
the
type
of
Runner,
it's
really
beneficial
to
be
able
to
compare
data
across
those
Runners
at
once.
A
The
next
Insight
here
is
that
Runners
are
seen
as
Runners,
whether
they
are
Runner
managers
or
not,
or
what
we
are
calling
Runner
machines
if
Runners
have
the
same
auth
token
they're
just
considered
a
group
of
runners
users
see-
and
this
is
what
their
mental
model
has
become,
based
on
what
we've
created
the
UI
as
for
years
now,
they
see
Runners
as
objects,
so,
whether
they're
the
agents
that
are
actually
running
the
job
or
they're
the
ones
that
are
acting
as
coordinators.
They
still
see
them
as
runners.
A
This
leads
us
to
kind
of
using
this
insight
to
determine
where
we're
going
to
go
with
the
terminology
for
the
term
machine
and
then
what
we
should
update
the
UI
text
to
be
Runners
and
Runner
manager,
rather
than
just
machines,
and
we
also
found
like
I,
was
saying
before
in
the
summary
that
users
are
actually
really
familiar
with
the
term
Runner
manager
and
there's
multiple
customer
blogs
that
are
out
there.
That
mention
that
term.
A
A
Another
Insight
is
that
a
summary
of
statuses
in
a
group
of
Runners
is
helpful
to
get
a
quick
idea
of
how
they're
performing
and
how
they're
configured
when
they're
when
it
comes
to.
If
there
is
a
group
of
Runners,
we
want
to
be
able
to
provide
an
overview
very
quickly
of
their
statuses
and
then
the
configuration
details
that
pertain
to
all
of
them
example
of
status
could
be
two
of
five
are
online
and
then
an
example
of
configuration
could
be
their
tags.
A
So
the
recommendations
here
is
to
make
summary
status
stats
number
over
total.
So
it's
clear
how
many
are
in
that
group
and
then
summarize
the
data
of
the
runner
group
and
parent
row
row
and
in
the
runner
details
and
allow
for
each
expandable
route
to
contain
single
Runner
data
when
I
show
you
the
the
designs.
I
think
this
will
make
sense
a
lot
more.
A
This
next
Insight
is
actually
was
a
great
one
for
us
to
pull
out
of
this
study
that
doesn't
directly
relate
to
the
to
the
iteration
that
we're
working
on,
but
it
is
critical
for
an
admin
to
see
which
Runners
are
failing.
So
something
I
learned
through
this
study
as
well,
is
that
Runner
failures
are
different
than
job
failures.
A
job
may
fail
because
the
test
failed,
and
it
should
fail
because
the
test
in
that
case
failed,
but
the
runner
ran
that
job
successfully
when
a
runner
fails.
A
Maybe
it's
due
to
a
timeout
or
something
like
that.
There
could
be
actually
something
wrong
with
the
runner
or
the
runner
configuration,
and
that's
something
that
the
runner
admin
would
want
to
fix
and
want
to
know
right
away.
So
it
is
helpful,
helpful
for
them
to
see
which
ones
have
failed
recently
or
are
failing
so
that
they
can
fix
them
as
soon
as
possible.
A
lot
of
users
have
set
up
alerts
for
when
this
happens,
or
maybe
a
developer.
A
They
report
that
their
job
isn't
getting
picked
up,
and
that
kind
of
like
triggers
the
admin
to
look
into
this.
But
if
we
are
able
to
just
show
that
information
right
away,
it
will
make
that
whole
process
way
quicker,
so
I'm
going
to
create
an
issue
for
this
feature
so
that
we
can
explore
bringing
this
into
the
into
gitlab.
A
The
next
Insight
that
we
got
here
is
that
comparing
Runner
machine
memory
or
capacity
enables
admins
to
debug
faster,
so
a
lot
of
the
things
that
admins
can
do
in
the
UI.
We
don't
pull
in
from
external
resources.
They
kind
of
have
to
go
to
those
other
places
to
find
out
stuff,
like
memory,
for
example,
but
actually
being
able
to
see
this
and
have
insight
into
it
can
help
them
figure
out
why
a
runner
is
failing.
A
Also
if
these
metrics
were
available
over
a
long
period
of
time,
the
admins
could
also
figure
out
how
to
optimize
their
Fleet
and
cut
costs
and
make
use
of
machine
sizes
more
effectively.
One
of
our
runner
teammates
has
already
made
an
issue
to
start
getting
insight
and
visibility
into
gitlab
for
this.
So
I'll
just
be
relating
this
insight
to
that
issue.
A
The
next
Insight
is
about
users
using
the
runner
UI,
and
this
was
actually
a
really
cool
thing
for
me
to
understand
more
just
about
their
workflow
with
the
current
UI.
So
they
seem
to
use
the
UI
for
high
level
insights
into
if
a
runner
is
misbehaving
and
they're
great.
The
it's
great
at
this
high
level
because
they
can
figure
out
if
a
runner
is
not
working
properly
like
if
the
runner's
offline
or
it's
not
running
jobs.
A
But
then
the
next
steps
typically
happen
outside
of
gitlab,
like
debugging,
in
the
runner
logs
or
some
other
system
data
that
is
not
on
git
log
and
I.
Think
we
could
investigate
how
possible
it
is
to
bring
this
type
of
information
into
gitlab,
so
I'll
be
creating
an
issue
and
exploring
how
we
could
do
that.
A
This
next
Insight
is
about
the
projects
Runner
view,
which
is
something
that
we've
heard
multiple
times
before
so
I'll
just
be
relating
this
to
existing
insights
and
maybe
bumping
up
severity
of
of
existing
system
connecting
issues.
But
the
admin
group
views
uis
are
significantly
significantly
more
usable
than
the
project
View.
For
the
following
reasons.
A
Pages
half
of
the
participants
were
fine,
with
the
runner
details
being
on
a
separate
page.
They
actually
mentioned
specifically
being
able
to
focus
in
on
the
details
versus
half
of
them
said.
The
ease
of
switching
between
different
Runner
details
and
not
having
to
wait
for
another
page
to
load
makes
the
drawer
beneficial.
So
if
we
want
to
keep
exploring
this,
then
I'll
be
running
research
specifically
around
using
drawer
versus
having
the
details
on
its
own
page
and
see
if
it
impacts
the
user's
ability
to
complete
their
main
main
job
to
be
done.
A
A
And
then
you
also
get
this
other
indication
here
that
there's
two
it's
like
a
collection
of
Runners,
so
I
wanted
to
make
it
clear
by
adding
that
other
indication
that
there's
like
a
group
here
you
all,
you
can
also
see
the
summary
status
updates
that
I
was
talking
about
and
then.
Finally,
when
you
expand
this,
these
are
each
of
the
runners
that
are
in
that
single
that
are
in
that
Runner
group.
A
So,
in
this
case,
all
of
these
Runners
have
the
same
tag:
they're
both
root,
that
they
use
Ruby
as
a
tag
and
then
like
they
have
the
same
description
but
they're
also
associated
with
the
same
project
and
they're
protected,
but
they
have
different
IP
addresses
and
they've
run
different
jobs.
They
may
have
been
created
at
different
times
and
they
may
have
contacted
git
Lab
at
different
times
as
well,
so
that
that
is
it
there.