►
Description
Walking through design recommendation for the layout on our Security Dashboard feature. This is part 2 of our Baseline Experience initiative.
Links:
Security Dashboard Documentation: https://docs.gitlab.com/ee/user/application_security/security_dashboard/
Baseline Initiative: https://about.gitlab.com/handbook/eng...
Part 1 issue, audit: https://gitlab.com/gitlab-org/gitlab-design/issues/401
Part 1 experience walkthrough: https://www.youtube.com/watch?v=_JtUdaTyAbk&list=PL05JrBw4t0KqkW0oPW3n0HqVgKcONVnO5&index=3
Part 2 issue, recommendation: https://gitlab.com/gitlab-org/gitlab-design/issues/460
A
Hi,
I'm
kyla
designer
and
the
gitlab
secure
team.
Today,
I'm
following
up
on
one
of
our
UX
team
initiatives,
called
experience,
baseline
and
recommendations.
This
is
part
2,
which
is
a
recommendation
to
part
one
of
our
security
dashboard
audit.
The
video
is
linked
in
the
description
of
that
part.
One.
The
experience
we're
focusing
on
is
improving
the
following
user
task
or
job
to
be
done,
which
is
the
following.
A
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,
let's
walk
through.
First
the
problems
that
we're
focusing
on
that.
We
are
then
making
recommendations
for
so
the
current
screen
that
we're
looking
at
is
the
security
dashboard.
A
The
first
problem
that
is
visible
is
that
the
actual
vulnerabilities
that
I
want
to
see
are
not
visible.
So
here
we
have
a
high-level
summary
and
we
have
chart
data,
but
the
the
actual
vulnerabilities
are
scrolled.
You
have.
The
user
has
to
scroll
down
here
to
check
them
out
and
to
address
them
in
the
screen
that
we're
looking
at
is
a
1440
by
900
pixels
screen,
which
is
a
pretty
common
laptop
display.
So
we
want
to.
We
want
to
figure
out
a
way
of
surfacing
those
and
making
them
visible.
A
The
summary
view
still
displays
zero
for
the
non
selected
critical
level
criticality
levels.
This
may
confuse
the
user
as
a
data
displaying
zero,
maybe
Intimus
interpreted
as
valid
data.
In
addition,
it's
not
ideal.
It's
not
an
ideal
use
of
space
because
it's
pushing
the
most
relevant
data,
which
is
these
high
level
severity
vulnerabilities
in
the
chart.
It's
pushing
them
down
the
way
a
bit.
A
Let
me
just
unselect
this
another
problem
that
we're
focusing
on
is
that
it's
unclear
to
the
user.
What
the
timeframe
of
the
table
vulnerabilities
occurred
that
are
being
displayed.
The
graph
here
has
a
time
selector,
so
you
can
see
the
vulnerabilities
over
time
in
in
the
chart,
but
that
is
not
visit.
A
That
does
not
control
that
the
time
selector
does
not
control
the
table
data
here
and
in
fact
the
actual
data
that's
being
showed
here
in
the
table,
are
the
results
of
the
most
recent
security
scan
on
the
default
branch,
though
this
is
not
explicit
to
the
user,
so
they
wouldn't
be
aware
of
when
these
vulnerabilities
were
added
or
found
to
then
be
displayed
here
all
right.
Let's
take
a
look
at
some
of
the
recommendations
for
this
issue.
A
It's
pretty
focused
on
the
layout,
so
here
in
annotation
one,
the
layout
changes
are
focused
on
prioritizing
the
tables
vulnerabilities
data.
We
do
this
by
again
an
annotation
one,
the
header
this
could
include
the
section
headers,
so
that
could
be
called
vulnerabilities
or
vulnerability
management
and
the
filters
would
be
there.
So
the
header
gives
them
a
good
idea
of
what
you
can
be
doing
on
that
page
management.
A
It's
one
idea
because
they're
going
to
be
managing
and
triaging
vulnerabilities
here
and
then
it's
side-by-side
with
the
filters
that
can
that
controls
the
data
below
it
here
in
the
main
section
in
annotation.
That's
where
the
recommendation
is
saying:
let's
put
the
most
important
data
there
front
and
center,
which
would
be
the
actual
vulnerabilities
in
the
table
data.
This
makes
it
immediately
visible
to
the
user
when
they
land
on
the
page.
A
So
just
translating
this
in
visual
design
just
to
get
an
idea
of
what
this
would
look
like.
As
I
said,
we
have
the
header
at
the
top
owner
ability,
management
and
the
relevant
features
that
we
have
to
our
filters.
Excuse
me
that
we
have
today,
and
we
have
the
actual
vulnerabilities
front
and
center,
so
they
land
here
and
it's
it's
immediately
clear
to
them.
A
Excuse
me
it's
immediately
clear
to
them
invisible
here
in
the
aside,
we
see
the
the
chart
that
shows
vulnerabilities
over
time,
as
well
as
the
high-level
summary,
which
also
serves
as
a
key
to
the
chart.
Now,
let's
say
that
the
user
changed
and
unfiltered
the
severity
level
to
say
higher
critical
level.
So
in
this
case
the
user
changed
it
to
critical.
Here
in
the
aside,
it's
only
showing
the
relevant
data
that
is
critical
severity
level
vulnerabilities.
A
This
opposed
to
the
current
way
just
removes
any
confusion
of
the
other
data
points
that
display
zero
and
this
just
surfaces
what's
relevant
at
the
time,
in
this
case
the
user
filtering
down
to
just
critical
level.
It's
a
few
other
thoughts
for
consideration
is
a
confidence
filter
and
a
date
range.
This
could
give
the
user
more
control
of
the
data
that
they
want
to
manage,
prioritize
and
triage.
A
An
example
of
this
is
you
the
user
could
come
in
and
if
there's
a
lot
of
vulnerabilities
and
they're
overwhelmed,
they
can
use
the
filters
to
just
surface
critical
level
ones
that
are
high
confidence
and
that
were
in
just
the
last
day.
So
one
at
one
use
case
there's.
Maybe
the
user
was
out
of
the
office
yesterday
and
they
just
want
to
know
what
new
ones
are
they're
surfacing.