►
From YouTube: UX Showcase Security Config Evaluations
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hey
everyone,
I'm
michael,
I
am
a
product
designer
on
the
secure
team.
Today
I
wanted
to
talk
to
you
about
the
current
state
of
enabling
and
configuring
security
scanners
in
gitlab
and
what
we've
been
doing
to
better
understand
how
we
can
improve
that
process
going
forward.
A
A
A
One
really
good
example
of
that
is
that
there's
actually
three
separate
ways.
You
can
configure
a
scanner
within
the
ui
here,
so
at
its
most
basic,
we
have
tools
like
infrastructure
as
code
and
dependency
scanning,
where
you
come
in
here,
and
it's
essentially
a
really
simple
process
where
you
come
in,
and
click
on.
A
This
configure
with
merge,
request
button
and
then
that
basically
packages
together
a
merge
request
and
then
users
all
they
have
to
do
is
basically
follow
through
that
merge,
request
process
to
enable
the
scanner
itself
and
then
there's
other
scanners
like
sas,
which
is
a
pretty
similar
configuration
workflow,
except
for
actually
providing
users
with
a
few
options
that
they
can
come
in
here
and
sort
of
tune.
A
The
scanner
and
choose
which
analyzers
that
zoom
in
the
way
here
which
analyzes
they
want
to
include
and
then
there's
even
some
options
around
specific
things
within
the
analyzers.
A
So
we're
actually
asking
you
to
come
in
here
and
create
sort
of
separate
artifacts
to
be
able
to
enable
the
scanner
so
we're
asking
them
to
create
a
scanner
profile
which
is
sort
of
a
separate
workflow
in
and
of
itself
and
then
create
a
site
profile
and
then,
instead
of
sort
of
packaging
that
all
up
into
an
automatic
merge
request.
We're
actually
act
just
generating
the
code.
Snippet
for
users
and
then
send
them
off
to
the
pipeline
editor
to
be
able
to
add
that
in
themselves.
A
So
obviously
that's
a
much
different
experience
than
the
other
two
configuration
workflows
that
I
just
showed
you
so
with
that
in
mind
and
then
knowing
obviously
secure,
is
still
pretty
new
at
gitlab
and
there's
a
lot
of
room
for
growth.
You
just
want
to
take
a
step
back
and
think
about
the
configuration
experience
as
a
whole
just
want
to
think
about
how
we
can
align
the
experiences
and
make
the
process
just
more
scalable
and
consistent
going
forward.
A
So
our
first
step
to
doing
that
is
really
to
evaluate
the
current
experience,
looking
at
sort
of
all
the
tools
as
a
whole
and
not
just
each
one
individually
and
ultimately,
we
wanted
to
understand
what
are
the
similarities
and
differences
between
the
workflows
and
ui
patterns
that
are
being
used.
How
well
are
we
guiding
users
through
this
process
and
how
easy
is
it
for
new
users
to
come
in
and
figure
this
stuff
out?
A
So
we
approached
this
from
a
couple
of
couple
different
angles.
So
our
first
approach
was
to
evaluate
the
learnability
and
usability
of
the
current
experience,
and
so
we
basically
conducted
a
couple
ux
scorecard
evaluations
to
accomplish
that.
So
I
partnered
with
a
couple
other
product
designers,
so
libor
came
in
and
evaluated
the
process
of
configuring,
our
source
code
scanners,
so
he's
looking
at
sas
secret
detection
and
dependency
scanning
and
going
through
and
evaluating
the
process
of
enabling
those
for
the
first
time
and
then
michael
lee
came
in
and
looked
at
our
dynamic
analysis
scanners.
A
Then
we
actually
had
a
bonus.
Ux
scorecard,
come
in
from
the
growth
team,
so
mate
did
a
ux
scorecard
on
secure
onboarding,
where
he
basically
came
in
and
evaluated
what
it's
like
for
a
brand
new
gitlab
user
to
come
and
enable
sas
for
the
first
time.
A
So
after
evaluating
the
usability
and
learnability
of
the
experience,
we
then
wanted
to
just
understand
what
are
the
ui
elements
and
workflows
that
we're
currently
using
within
the
configuration
process,
and
so
we
basically
did
an
audit
for
the
security
configuration
area
and
what
that
process
looked
like
is.
Essentially,
we
identified
all
the
different
scanners
that
have
configuration
uis
and
then
for
each
one
of
those
we
basically
went
through
identified
the
relevant
jobs
to
be
done
for
each
of
them.
A
So
the
skier
protect
team
already
had
a
few
jobs
that
were
relevant
to
configuration
so
basically
just
identified
those
jobs
and
they're
at
high
level
enough
where
they
really
applied
the
configuration
process
for
all
of
our
scanners.
A
But
as
you
can
see
for
sas,
it's
a
pretty
simple
process
where
you
come
in
from
the
home
page
into
security,
configuration
page
and
then
into
the
sas
specific
page
and
then
basically
through
the
merge
request
process.
But
if
you
contrast
that
with
something
like
das,
which
you
remember,
that
ui
was
obviously
much
different.
We
can
see
that
through
the
workflow
here
that
the
whole
configuration
process
that
we're
sending
users
through
is
quite
a
bit
different.
A
So
it
starts
out
in
a
similar
way,
where
you're
coming
through
the
home
page
in
the
security
page
and
under
the
dashed
area,
and
then
it
kind
of
goes
off
on
its
own,
so
you're
coming
in
and
asking
users
to
create
or
select
site
profiles
and
then
scanner
profiles
and
then
we're
looking
at
essentially
how
compatible
or
if
those
two
profiles
are
compatible
and
then
basically
going
through
the
whole
code.
Snippet
and
ci
pipeline
editor
process.
A
So
obviously
it's
a
much
much
different
workflow
than
the
simpler
process
like
zest,
and
so
after
we
worked
through
the
after.
We
basically
went
through
the
workflow
and
captured
the
screenshots
and
the
workflow
itself.
I
then
went
to
seek
out
any
sort
of
new
relevant
issues
to
get
a
sense
of
what
was
kind
of
planned
for
all
of
these
scanner
configurations
going
forward
to
have
a
sense
of
how
they
were
kind
of
how
teams
were
thinking
about
how
they're
going
to
grow
and
evolve
over
time.
A
A
A
In
fact,
the
guidance
actually
mostly
drops
off
when
the
configuration
workflow
takes
users
away
from
the
series
security
configuration
area.
We
actually
saw
this
supported
within
the
ux
scorecard
evaluations,
where
all
three
of
the
evaluations
determined
that
was
pretty
difficult
to
determine
when
a
security
tool
was
enabled
or
if
it
was
configured
properly
and
really.
What
that
boiled
down
to
is
that
the
change
in
system
status
wasn't
really
easily
discovered
and
it
wasn't
clear
where
to
go
to
confirm
the
tool
is
enabled
or
where
to
view
the
results.
A
Then,
on
top
of
that,
we
also
weren't
doing
much
currently
to
help
users
recognize,
diagnose
and
recover
from
errors
throughout
the
configuration
process.
So
the
scanners
with
ui
configuration
options,
all
of
them
handle
field
errors
a
little
bit
differently
and
some
of
the
fields
actually
have
no
validation
at
all
right
now.
A
The
next
thing
that
we
learned
is
that
there
seemed
to
be
a
lot
of
variation
across
the
different
configuration
workflows.
So,
as
I
showed
up
before,
there's
currently
three
possible
workflows
that
a
user
could
enter
into
to
enable
a
scanner
within
the
configuration
or
within
the
ui
and
then
another
good
example
of
that
is
das
and
api
fuzzing.
A
So
only
two
out
of
three
of
the
jobs
to
be
done
are
largely
undressed
by
the
ui
right
now
and
one
in
the
other
configuration
job
to
be
done
is
pretty
much
addressed
by
only
about
half
the
scanners,
which
isn't
really
great.
A
So
after
completing
the
evaluation,
we
feel
we
have
a
pretty
good
understanding
of
some
of
the
larger
pain
points
and
opportunities
throughout
the
security
configuration
process
at
gitlab.
So
our
next
step
is
to
then
look
outside
of
gitlab
and
hopefully
learn
from
our
talk
about
target
audience
a
bit.
So
I'm
planning
a
contextual
inquiry
study
to
help
better
understand
how
teams
integrate
security
tools
into
their
ci
cd
pipelines
and
then
from
there
probably
planning
to
spend
some
time
learning
from
competitors
as
well.
A
So
doing
a
competitor
evaluation
or
two
just
to
get
a
sense
of
how
competitors
are
solving
similar
problems
for
their
users
and
just
understand
what
they've
done
in
the
pa
or
what's
been
done
in
the
past
and
then
from
there.
We
can
basically
start
iterating
on
the
experience
so
we'll
start
by
identifying
and
planning
out
our
priorities,
revising
and
aligning
on
an
ideal
user
journey
and
then
collaborating
to
improve
the
experience
from
there
and
there
you
have
it.
So
that's
pretty
much
what
we're
doing
to
understand
how
security
configuration
can
be
improved
at
getlab.
B
Nice
job,
michael
thanks
for
the
overview
you
looks
like
christy
you're.
The
first
person
first
comment.
C
Yes
and
I'm
trying
to
add
a
second
comment,
so,
okay,
let
me
finish
adding
that
kind
of
so
first,
I
just
wanted
to
make
a
comment.
This
is
such
a
great
example
of
how
learnability
is
important
throughout
the
user's
life
cycle
of
using
our
product.
So
I
think
we
have
a
tendency
to
think
that
well,
like
learnability
is
important
for
new
users,
it's
important
for
our
more
basic
workflows
that
everyone
is
using
and
you're
giving
a
great
example
here
of
how
that
is.
Not
true.
C
I
think
we
also
have
a
tendency
to
think
well,
if
someone's
configuring
security,
then
you
know
they're
they're,
deeply
technical
and
it's
fine,
like
the
the
old
trope
of
like
developers,
don't
care
about
usability
right.
We
know
that
that's
not
true,
but,
as
I
was
watching
what
you
were
presenting,
I
was
seeing
so
many
opportunities
for
ways
that
we
could
improve.
So
thank
you
for
giving
us
a
case
in
point
of
how
learnability
is
critical.
A
D
D
Yeah,
thank
you
yeah.
I
just
love
seeing
the
connection
of
using
jobs
to
be
done.
I
know
that's
been
a
big
question
that
many
designers
have
had
is.
I
know
we
use
these
for
ux
scorecards,
but
then
how
do
you
actually
use
it
elsewhere
and
I
love
seeing
the
connection
of
yes.
We
did
ux
scorecards,
but
then
you
went
back
and
you
did
this
evaluation
and
you
tied
it
back
to
those
three
jobs
to
be
done.
That's
that's
well
done.
Thank
you
for
giving
as
a
wonderful
example
of
how
to
use
it.
C
C
D
Yeah
and
just
to
tag
onto
that,
you
know,
jeremy
made
a
wonderful
unboxing,
the
ui
video,
which
gave
a
lot
of
inspiration
to
kind
of
how
you
can
look
at
our
ui
and
then
some
very
practical
things
that
we
could
do
to
move
forward.
So
I
was
wondering
if
you
had
an
opportunity
to
watch
that
video.
A
Yeah,
that's
a
great
question,
so
I
did
watch
the
video
and
obviously
I
thought
it
was
super
awesome
and
very
informative.
I
think
there's
a
couple
areas,
so
one
thing
I'm
thinking
about
is
the
das
configuration
area
right
now,
it's
very
just
boxy
in
general
and
you're.
Basically,
when
you
come
to
that
page
and
you
fill
it
all
out,
you
basically
just
have
two
large
boxes
on
the
screen.
A
I
don't
think
it's
really
helping
anything
right
now,
so
just
thinking
about
how
we
can
clean
that
up
and
make
that
information
a
little
bit
more
just
digestible,
I
think,
is
one
big
area
of
that
and
then,
as
christie
pointed
out
on
the
main
security
configuration
area
right,
there
too,
I
think
there's
a
lot
of
opportunity
to
think
about
how
we
can
unbox
that
I
haven't
really
done
a
lot
of
explorations
in
about
how
we
can
approach
it
yet.
But
I
know
there's
definitely
quite
a
bit
of
opportunity.
E
Yeah,
just
that's
something
that
we've
struggled
with
is
because
we
have
three
primary
routes
of
configuration,
as
michael
did
a
great
job
of
showing
we've
struggled
with.
E
Do
we
try
to
set
those
those
expectations
with
the
button
copy,
or
do
we
just
say
enable
on
all
of
them,
even
though
they
kind
of
go
off
in
different
paths?
But
the
reason
that
we
ended
up
with
the
varying
button
copy
is
to
try
to
set
expectations
for
what's
to
come
next.
Is
it
going
to
be
a
merge
request
page?
Is
it
going
to
be
a
a
configuration
page
before
you
create
a
merge
request?
E
Is
it
not
a
merge
request
page
at
all,
and
I
think
michael's
presentation
did
a
great
job
of
just
showing
how
this
current
experience,
maybe
isn't
working
so
well,
but
that's
just
some
more
context
there
on
on
why
we
have
so
many
different
button
copy.
C
Yeah,
I
think
thank
you
for
sharing
that
becca
I'll,
say
the
button
copy,
isn't
even
what
caught
me,
because
we
went
through
it
too
quickly
for
me
to
even
notice
that
there
was
was
different.
There
were
differences
there,
just
the
fact
that
we're
using
primaries
everywhere
I
mean
I'm
gonna,
say
the
simplest
possible
thing
which
is:
do
we
even
need
a
primary
on
that
page?
To
me,
a
primary
says
like
this
is
the
one
thing
that
you're
here
to
do
and
what
that
design
is
telling.
C
You
is
no
there's
like
six
or
eight
different
things
that
you
could
do.
Could
those
have
been
secondary
buttons
instead
of
primary
buttons?
I
think
that
would
give
probably
a
better
weight
to
the
the
mental
model
of
what's
happening
there.
So
I
am
not
saying
that
that
is
the
answer.
Please
don't
take
that
as
prescriptive.
C
That's
more
of
just
kind
of
a
we
probably
could
have
made
a
better
decision
there,
even
just
from
a
a
visual
design
standpoint.
E
Yeah,
even
that's
really
tricky,
of
course,
because
I
mean
with
sass,
we
decided
to
go
with
the
primary
button
for
enabling
it
to
kind
of
call
more
attention
to
the
fact
that
it's
not
enabled
and
then
once
it
is
enabled
it
switches
to
a
secondary
button.
And
if
you
want
to
go
back
and
configure
the
way
that
sas
runs.
E
So
the
idea
there
was
that
primary
grab
your
attention,
this
isn't
enabled
come
and
enable
it
and
then
it
switches
to
secondary,
because
it's
like
okay,
it's
enabled.
But
if
you
want
to
come
in
and
and
configure
some
things,
you
can
do
that.
So
I
I
can't
speak
for
the
other
scanners,
like
because
I
was
just
on
static
analysis
initially,
but
there
was
some
thought
that
went
into
both
primary
versus
secondary.
C
C
What
component
do
we
use
for
navigation
links
right
and
that
would
have
really,
I
think,
if
we
had
really
thought
about
the
components
and
what
they
are
for
and
how
we
are
using
them
and
how
we
might
use
them
differently.
We
might
have
come
up
with
some
really
interesting,
more
easily
scannable
ways
to
display
that
information
and
and
give
people
a
better
expectation
of
like
what's
gonna
happen.
Next,
when
I
click
a
button
like
I
expect,
like
something's
gonna
happen,
not
that
I'm
just
gonna
go
someplace
else
for
sure
that
makes
sense.
B
All
in
all,
I
think
this
is
a
an
excellent
reason
on
why
we're
doing
this
evaluation
and
and
also,
I
think,
just
go
ahead.
C
Yeah
I
said
I
want
to
be
clear,
like
I'm
not
trying
to
pick
on
anybody
or
like
say
like.
Why
did
you
do
this?
But
these
are
the
opportunities
for
us
to
look
at
when
we
have
a
lot
of
different
people
designing
against
the
same
thing
and
we're
not
coordinating
those
efforts
and
we're
not
thinking
about
it
holistically.
C
It's
really
easy
for
things
like
this
to
happen,
and
then
we
go
back
and
we
all
look
at
it
as
designers
and
kind
of
go.
Oh
well
that
wasn't
ideal,
so
not
picking,
but
also
just
calling
out.
This
is
a
problem
for
us
and
it's
going
to
continue
to
be
a
problem
for
us
because
of
the
type
of
product
that
we
work
on,
because
these
are.
These
are
real
sticky
points
that
we,
just
as
a
team,
probably
need
to
work
on
getting
better
at.
C
Yeah-
and
I
can
also
see
an
argument
for
so
there
was
a
pattern
already
there
and
now
I'm
coming
to
add
something.
That's
similar.
Do
I
use
the
pattern?
That's
already
there
for
consistency,
or
do
I
rethink
what's
there
today
and
I
think
sometimes
we
we
back
ourselves
into
corners
that
way,
because
we
kind
of
like
unintentionally
set
a
standard
and
then
all
of
a
sudden
it
becomes
it's
not
a
scalable
standard
and
it
starts
to
grow
and
then
because
of
the
way
that
we
work
again,
you
know
we're
working
it.
C
Sometimes
in
silos
like
whose
responsibility
is
it
to
go
and
address
that
fundamental
usability
issue?
I'd
say:
you
know
it's
everyone's
responsibility,
but
I
get
I
get
where
the
tension
of
that
comes
in.
C
B
B
Now
check
out
those
if
sorry.
F
Mom
I
was
on
my
phone,
so
it
was
confusing
yeah.
I
just
came
up
recently
as
a
discussion
of
like
whether
or
not
buttons
can
be
used
as
links,
and
I
think
the
answer
is
like
no.
They
can't
act
as
links,
but
you
can
style
links
to
look
like
buttons,
so
that
can
I
think
that
could
be
confusing
just
visually
when
something
looks
similar,
but
I
think
it's
because
buttons
can
line
up
next
to
each
other
have
to
look
into
it
more.