►
From YouTube: Group UX Review: Security Dashboard
Description
Kyle walking through a design recommendation for the layout on our Security Dashboard feature.
Secure UX team: https://about.gitlab.com/handbook/engineering/ux/stage-group-ux-strategy/secure/index.html
Baseline Experience: https://about.gitlab.com/handbook/engineering/ux/experience-baseline-recommendations/
A
A
Okay
cool,
so
just
giving
some
context
to
what
we'll
be
checking
out
today.
This
is
part
two
of
the
jobs
to
be
done
initiative,
which
is
a
recommendation.
So
what
we're
gonna
be
looking
at.
Is
this
what
we
call
the
security,
dashboard
and
there's
gonna?
Be
several
issues
created,
but
really
this
one
focused
on
a
front-end
fix
that
we
can
focus
on
just
as
as
Pedro
calls
it
an
easy
win,
and
so
it's
a
little
bit
less
involved
with
with
adding
too
much
functionality.
A
So
that's
why
we
prioritize
this
one
to
observe
as
the
recommendation
with
most
things
in
security,
certainly
with
the
security
dashboard.
It's
important
to
note
that
the
dashboard
is
at
a
very
early
stage,
so
you
know
we're
figuring
out
a
lot
about
it,
and
this
recommendation
in
of
itself
has
surfaced
a
lot
of
really
good
questions
and
action
items
to
learn
more
about
our
user.
A
Who
are
we
designing
for
we?
We
are
designing
for
organizations
web
dick
web
for
larger
organizations.
The
roles
would
include
security,
analyst
security
engineers
head
of
security,
however,
for
smaller
organizations
they
could
benefit
from
this.
That
you
know,
maybe
don't
have
a
web
security
department
would
maybe
be
the
tech
leave
the
CTO,
the
developers
themselves,
DevOps
engineers.
This
would
be
some
of
the
titles.
The
page
is
intended
to
provide
the
user
with
an
over
you
and
awareness
of
vulnerability.
It's
multiple.
A
Providing
the
ability
to
resolve
and
address
the
security
concerns
that
are
listed
just
a
quick
side.
Note
I,
actually
I
put
in
some
related
issues,
there's
some
really
exciting
work.
That's
been
done
that
n
DS
been
working
on
in
terms
of
navigating
from
vulnerability
to
vulnerability.
Right
now,
it's
on
the
table.
You
it
just
opens
a
modal
and
it's
it's
not
a
great
experience,
but
we're
really
about
new
stuff,
the
navigation
from
it.
A
A
So
job
to
be
done
in
context
now
that
we're
here
the
job
to
be
done
that
we'll
be
considering
for
this,
is
when
reviewing
vulnerabilities
for
multiple
projects.
I
want
to
see
them
all
in
one
location
so
that
it
can
prioritize
my
efforts
to
resolve
or
triage
them
while
seeing
the
larger
picture.
Okay,
so
the
and
I
I
just
have
to
walk
through
this.
A
The
other
thing
is:
is
this
chart
takes
up
the
whole
space,
so
it's
pushing
those
vulnerabilities
down.
This
high-level
summary
is
the
goal
with
that
summary
is
just
to
kind
of
give
them
it
give
either
an
idea
of
their
prospects
are
looking
like.
Maybe
they
can
focus
their
efforts
now,
with
this
data,
oh
I
see
two
critical
I
see
one
hi
now
I
can
filter
it
down.
So
let's
say
that
I
filter
it
down
to
critical
well
that
changes
to
data.
A
Indeed,
however,
it
can
be
a
little,
it
could
be
misinterpreted
because
we're
still
showing
these
data
points,
even
though
it's
filtered.
So
it's
not
a
good
data,
visualization
practice
and
again
it's
pushing
down
the
information.
This
is
the
most
important
thing
that
we
we
want
for
the
job
to
be
done
for
the
user
to
get
here
to
check
out
the
vulnerabilities.
So
our
goal
is
what
the
recommendation
is
to
create
a
layout
that
brings
the
most
important
data
right
to
the
top,
so.
A
Okay,
so
when
we
approached
it,
we
we
thought
about
it
in
terms
of
what's
the
primary
data
and
the
secondary
data,
and
with
this
layout
and
also
you
know,
it's
a
front-end
focus
change,
so
just
lay
out
an
annotation
one.
This
could
contain
the
header
and
filters
annotation
two
is
the
primary
data,
which
is
the
vulnerability
so
bringing
that
up
right
to
the
top
and
then
annotation
three
contains
secondary
data,
which
is
the
summary
vulnerabilities
over
time
and
the
recent
branch
update.
That
is
a
death
point.
That's
not
currently
on
there.
A
It
is
at
the
project
level,
but
we'd
like
to
bring
that
data
at
the
group
level
as
well,
just
a
consideration
at
smaller
screen
Isis.
That
aside,
could
take
up
the
space
or
maybe
it
could
be
removed
so
that
you
could
bring
those
vulnerabilities
right
to
the
top,
but
that's
just
of
a
secondary
consideration.
Okay,
so
how
this
would
look
with
bringing
that
line
graph
to
this
to
the
aside?
A
One
thing
that
you
know
it's
worth
considering
for
this:
the
affordance
that
we
have
is
line
graph
scale
really
well,
so,
whether
you're
on
mobile,
large
desktop
monitors
or
an
aside
like
this,
we
can
still
visually
tell
the
story
we
want
to.
If
you
make
this
larger,
it's
not
going
to
be
that
much
clearer.
Just
because
it's
larger,
you
still
see
the
the
changes
over
time.
A
So
how
this
layout
would
translate
to
our
current
style
would
look
like
this,
so
the
good
news
is,
is
we've
brought
the
we
brought
the
most
important
thing
to
the
top,
which
is
vulnerabilities,
but
on
this
iteration,
some
of
the
concerns
that
we
had.
It
isn't
really,
quite
as
it's
not
surfaced
as
clearly
as
we'd,
like
it's
an
improvement
from
the
other
one.
Yes,
but
it's
not
quite
as
clear
and
prominent
as
we'd
like
the
key
here
is
also
nice,
because
it's
a
it's.
A
We've
eliminated
the
need
for
two
different
elements
and
we've
put
together
the
key
and
the
summary,
but
it's
disconnected
from
the
severity
labels.
So
that
is
a
concern
we
had
and
in
terms
of
the
actual
data
visualization
that
we
have.
This
may
not
even
be
the
right
one,
we're
not
necessarily
comparing
vulnerabilities
against
each
other,
like
you
would
say,
you
know,
or
something
like
that,
you're
you're
wanting
to
see
that
in
the
the
severity,
how
it's
changed
over
time
individually,
so
maybe
a
line
graph
isn't
even
the
best
option
there.
If
we're
solving.
A
If
that's
the
story,
we
want
to
tell
with
our
data.
There
is
also
another
consideration
is
that
we
want
to
show
where
this
data
is
coming
from.
So
this
is
another
problem,
that's
kind
of
outside
the
scope
of
this
recommendation,
but
the
data
that's
being
shown
here
is
updated
from
the
most
recent
branch
on
a
project,
the
most
recent
default
branch,
and
so
we
haven't
told
that
to
the
user.
They
don't
have
any
indication
other
than
reading
the
documentation
of
where
this
data
is
coming
from.
A
A
So
what
we
did
is
we
really
tightened
up
the
summary
and
the
visual
that
we
wanted
to
show
of
vulnerabilities
over
time
we
aligned
the
the
different
severity
levels
with
the
ones
that
we're
using
in
the
table
so
that
we
can
visual
visually
correlate
the
to
the
user
can,
and
we
have
an
area
here
that
could
include
some
of
the
update
data
that
we
we
that
I
was
speaking
to
the
default
branch
that
we
know
we
want
to
add
now.
Some
of
the
outstanding
questions
that
we
have
here
is.
A
A
The
idea
there
is
we're
at
such
an
early
stage
that
maybe,
if
we
could
minimize
some
of
the
configuration
or
options
that
we
have,
maybe
we
could
have
a
little
bit
better
feedback
and
again
really.
The
most
important
thing
here
is
the
actual
vulnerability
management
of
the
vulnerabilities
so
kind
of
focusing
more
in
that
area.
But
what
are
your
thoughts
on
just
having
it
show?
The
last
30
days,
for
example,.
C
I'll
jump
in
since
no
one
else
yeah
when
I
think
about
how
we
look
at
the
severity
of
vulnerabilities
at
get
lab,
even
we're,
definitely
looking
at
them
over
time
and
wanting
to
see
where
things
are
cropping
up.
So
so
the
short
answers,
I,
don't
know,
but
I
would
be
very
cautious
about
only
showing
30
and
I'd
want
to
I.
B
I
was
also
gonna,
say
just
add,
so
what
Christie
said,
which
I
think
would
agree
with
when
you
first
talked
about
the
job
to
be
done?
I
had
a
question
about
it
right,
so
you
said:
I,
don't
remember
exactly
what
it
was,
but
it
was.
You
know
you,
you
want
to
see
things
kind
of
all
in
one
place
in
holistically
and
over
time
right,
but
my
question
was
well.
Why,
like
what's
the
underlying
goal
there,
and
maybe
that
might
point
to
more
details
on
how
people
would
want
the
data
to
be
displayed
over
time.
A
Yeah,
it's
that's
a
great
question,
I
think
filling
in
some
historical
context
on
until
to
this,
as
well
as
what
we
call
the
dashboard
it
really
it's
trying
to
trying
it's
it's
a
minimal
early
stage,
sort
of
MVP
that
was
trying
to
tackle
two
different
user
types.
So
there's
one
that
wants
to
actually
just
manage
and
triage
them,
and
that's
just
and
go
there
with
this
table
here
and
then
there's
the
other.
A
That's
more
kind
of
at
a
high
level,
see
so
level
that
wants
to
see
how
their
team
is
tracking
over
time
and
so
they're
kind
of
put
together.
That's
one
of
the
questions.
This
is
a
good
candidate
for,
like
prod
discovery,
to
kind
of
figure
out.
How
like
do
we
want
and
that's
another
thing
here
is
I
put
the
the
header
vulnerability
management,
because
it's
a
little
bit
more
oriented
towards
that.
But
oh
and
Philip
just
joined
us
as
well,
and
he
brings
up
a
great
point
that
you
know.
C
A
Yeah
at
bare
minimum
internally
and
and
some
of
some
of
this
as
well,
has
been
influenced
by
Dennis
who's,
our
one
of
our
security
engineer
experts
and
he
was
he
leaned
more
towards
the
actual
management
side
of
it
and
was
kind
of
indifferent
about
the
visuals.
But
I
think
that
as
a
next
step,
I
definitely
want
to
at
least
get
in
front
of
our
internal
team
and
and
see
if
we
can
get
some
more
a/b
testing
on
that.
We've.
C
B
B
A
B
C
A
And
and
I'll
I'll
throw
it
out
there
to
where
we're
definitely
on
the
hunt
for
customers.
At
the
moment
we
found
one
or
two
that
maybe
we
may
be
able
to
talk
to
in
July.
So
if,
if
anyone
on
the
call
knows
of
any
that
used
to
actively
that
we
could
even
maybe
get
this
in
front
of,
that
would
be
great
or
even
feedback
from
from
their
usage
of
the
existing
dashboard
yeah.
C
I'll
say:
I:
don't
think
that
it
even
necessarily
has
to
be
people
who
are
using
our
security
tools.
I
mean
this
is
just
general.
How
do
you
want
to
see
security
information?
This
is
a
leaked
by
you
as
a
Nicole
ping
Twitter
and
we
I'm
sure
we'd
get
some
some
quick
responses,
surprising
how
effective
that
is.
Awesome.
A
E
So
it
comes
with
that,
like
it's,
the
many-faced
God
of
our
so
I
think
it
if
you're
going
to
a
be
test
in
your
a
be
testing.
The
security
analyst
you're
gonna
hear
something
very
different
than
if
you're
testing
with
security
directors,
who
want
to
see
them
more
like
Splunk
as
a
competitor
in
this
chart,
really,
because
there's
all
this
like
great,
charting
or
very
similar,
like
periscope,
but
for
security
right,
so
you're
gonna
get
kind
of
mixed
reviews
either
way.
C
That's
in
that
goes
back
to
I
can
quit
Philippe
was
was
pointing
out
that
this
would
be
a
way
to
find
out
whether
or
not
you
even
need
to
have
two
different
displays.
There's
two
different
views
and
I
would
just
say
you
know,
make
sure
that
you're
talking
to
both
audiences
when
you're
putting
this
in
front
of
people
and
then
and
then
you'll,
come
out
and
feel
much
more
confident.
That's
a
lot
of
what
the
testing
is
about
is
confidence,
and
how
close
are
we
and
based
on
that
information?
C
A
Yeah
and
and
I
think
that
that
would
be
such
a
great
driver
for
some
of
our
like
next
steps
and
in
terms
of
who
we
want
to
solve,
for
and
and
so
on,
yeah.
Well,
those
are
all
the
questions
they
I
don't
know
if
there
was
any
other
thoughts
about
the
layout
that
came
to
mind
if
you
think
that
this
helps
kind
of
surface
the
primary
data
or
any
other
thoughts
that
came
to
mind,
I
didn't
see
anyone
else
up
next
on
the
list,
so
I
think
we
have
a
minute.
F
I
was
wondering
about
the
listed
layout
next
to
the
graphs,
as
the
graph
is
like
time-based
correct.
If
the
table
actually
services
any
vulnerability,
surface
dates.
So
when
they,
you
know
when
they
pop
off
as
to
hate,
it's
actually
a
problem.
I
said
Titan
flows
into
two
to
the
sidebar.
In
this
case,.
F
A
Yeah
there
there
is
some
efforts,
might
I
think
it's
outside
of
this
there's
there's
a
couple
linked
efforts
to
that
show
even
kind
of
better
organized
able
aside
of
this
issue,
but
right
here,
this
update
status
is
hoping
to
help
out
with
this,
which
is
to
say:
where
did
this
data?
Oh
excuse
me:
where
did
this
data
actually
come
from?
We
have
it
in
our
in
the
depths
of
our
documentation
and
it's
the
from
the
most
recent
branch.
F
F
A
That's
that's
another
issue:
we're
gonna
open
as
a
result
of
it.
It's
a
little
outside
of
front
end.
I
think
that
there
was
some
challenges
there,
because
Wallner
abilities
aren't
first-class
objects
yet,
but
it's
it's
also
some
feedback
that
we
got
from
Dennis.
You
know
he
said
it.
It
drives
him
nuts.
If
he
comes
in
the
week
like
after
a
weekend
on
Monday,
he
wants
to
put
in
the
weekend
what
their
abilities
that
were
surfaced.
So
we
have
a
bit
of
a
technical
constraint
there,
but
it's
it's
definitely
on
the
radar.
F
C
He
asked
about
feedback
on
the
rearrangement
of
the
content,
hierarchy
and
I'll,
say
I
think
this
is
a
huge
improvement.
It's
such
a
better
use
of
real
estate.
It
does
such
a
better
job
of
surfacing
more
important
information.
Just
at
a
glance
so
I
mean
it
seems
like
a
very
meaningful
change
to
me,
and
my
only
course.
Oh
now
now
I
have
some
just
style
questions
and
by
the
way
it
looks
good,
but
then
I
start
thinking
about
how
does
this
align
with
the
rest
of
the
product
and
with
pajamas?
C
These
are
nitpicky
questions
and
you
may
not
even
be
ready
for
them,
so
you
can
tell
me
if
you're
not,
but
when
I
look
at
the
table
layout
on
to
dot,
PNG
and
I,
look
at
see
think
it's
still
changing.
No,
this
green
might
be
there.
We
go
the
way
that
we're
doing
the
page
header
and
where
the
filters
live
with
the
borders
and
the
background,
look
different
to
me
than
how
we
do
those
in
the
rest
of
the
products
is.
That
intentional,
is
that
just
because
that's
the
level
of
fidelity
we're
at?
A
It
was,
it
was
intentional.
It
was
intentional
to
add
the
vulnerability
management
header
there
to
kind
of
drive
the
conversation
on.
Where
is
the
user?
If,
if
we're
hoping
that
the
table
is
a
place
to
go
in
triage
and
or
and
and
kind
of
filter
down,
it,
maybe
is
more
of
a
management
than
a
dashboard
per
se.
C
C
A
C
For
making
the
decisions
deliberately,
that's
one
thing
and
high
on
is
working
on
tables
right
now.
So
maybe
this
is
a
use
case
that
you
put
in
front
of
her
and
say:
hey
I,
think
you're
gonna
need
to
have
real
tight
tables
and
hear
the
reasons
why
and
then
we
add
those
into
you
know
into
the
specs,
but
yeah
just
want
to
be
deliberate
and
then
also
for,
if
we're
making
decisions
like
that,
make
sure
that
they're
documented
so
that
if
we
need
to
use
them
again,
we're
doing
it
consistently.
C
A
C
G
And
just
add
a
label
next
to
the
governor
duties
with
a
new,
for
example,
if
there
are
the
last
24
days,
24
hours
or
last
time
last
week,
but
then
you
design
is
absolutely
great.
Being
able
to
have
this
these
two
metrics
into
a
single
chart.
It
really
makes
sense.
We
don't
need
to
know
the
data
compared
to
the
others.
It
doesn't
make
sense
we're
having
some
trends.
It's
the
only
thing
that
matters
this
portion
is
going
to
be
used
not
for
reporting
the
just
for
us.
G
If,
suddenly
this
week,
I
have
a
thousand
new
critical
vulnerabilities
I
need
to
know
when
they
started
to
appear
on
the
dashboard.
So
with
that
I
can
spot
okay,
it
wasn't
Wednesday
what
occurred
on
Wednesday
and
then
I
can
investigate
if
I
don't
have
that
I'm
I'm
lost
completely
so
great
clues,
I
wrote
that.