►
From YouTube: UX Showcase iterating with high confidence
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
Okay,
so
starting
off
with
an
introduction
I'm
really
because
the
senior
product
designer
for
pipe
and
execution
team,
but
I'm
also
covering
for
the
pipe
and
security
team
for
a
while
and
my
presentation
is
about
iteration.
So
we
often
talk
about
iterating
through
designs,
but
today,
I
want
to
share
an
example
of
how
we
iterated
our
way
into
gaining
more
confidence
in
the
vision
and
goal
for
our
MVC
first
Native
secret
solution.
A
So
we
were
careful
not
to
start
with
the
proposal
that
had
gaps
in
experience,
because
the
user
basis
very
sensitive
for
this
particular
feature.
A
For
other
right
reasons,
though,
so
we
like
decided
to
design
our
way
into,
determine
like
what
would
be
a
complete
NPC
in
terms
of
what
would
user
want
and
expect
to
accomplish,
using
the
very
first
iteration
that
would
still
like
bring
good
amount
of
value
to
them
and
with
leave
them
keep
coming
back
for
whatever
more
we
have
to
deliver
so
and
at
the
same
time,
we
also
had
to
be
like
really
practical
about,
what's
feasible
in
the
time
that
we
were
targeting
to
develop.
A
That
in
and
that's
how,
like
this
whole
effort,
started
now,
of
course,
I
would
start
off
with
talking
about
what
is
a
secret.
So
a
secret
is
a
piece
of
sensitive
information
and
what
I
mean
by
sensitive
information
is
like,
for
example,
API,
Keys,
passwords
or
just
any
type
of
credentials
like
keys
to
connect
to
external
databases,
external
microservices,
so
that
they
would
enable
gitlab
or
a
component
built
within
gitlab
to
connect
to
other
systems,
and
the
reason
like
that
we
started
to
work
on
this.
A
How
we
identified
this
need
in
the
market
was
through
a
series
of
researchers
like
a
lot
of
researchers
and
eventually,
like
we
decided
that
the
biggest
concern
in
the
software
development
industry
today
is
security
because
well,
it
is
I
mean
we
couldn't
even
keep
a
count
of
how
many
security
breach
and
data
leak
related
articles.
We
have
would
have
seen
in
the
in
just
last
week,
so
like
keeping
customers
and
companies
data
safe,
ensuring
that
the
infrastructure
isn't
vulnerable
to
external
attacks.
A
This
is
definitely
like
on
the
top
of
or
or
the
mind
of,
all
the
organizations.
So
that's
the
reason.
Keeping
sensitive
information
safe
tops
the
list
of
requirements
for
organizations
of
all
sizes,
but
this
is
like
it's
too
wider
for
statement
as
in
keeping
sensitive
information
safe.
So
this
is
what
we
had
like.
A
We
definitely
did
have
a
couple
of
jobs
to
be
done,
that
we
already
that
we
were
able
to
document
already
through
series
of
researchers
like
I
said,
but
like
that
key
statement
that
would
kick
off
the
whole
work
was
keeping
sensitive
information
safe.
There
were
many
questions
that
were
still
like,
not
answered
like
how
can
we
best
ensure
this
integrates
with
other
GitHub
Solutions?
Who
makes
the
decisions?
A
We
came
up
with
a
plan
like
how
would
we
want
to
like
go
about
each
step
and
also
be
very
intentional
about
why
we
are
doing
these
things
like
all
the
activities
that
we
had
lined
up
so
gitlab
2D
gitlab
users.
A
They
can
definitely
leverage
like
third-party
secret
storage
providers
like
you
would
have
come
across
the
name,
hachika
Corp
Walt,
because
we
have
an
integration
with
them
and
we
also
have
like
talks
of
integration
with
many
other
service
providers,
but
like
there's
a
lot
when
it
comes
to
configuring,
those
Solutions
and
setting
them
up.
So
this
definitely
like
creates
a
lot
of
burden
on
the
devops
and
engineering
team,
so
we
did
have
like
a
window
of
opportunity
there.
A
So
this
is
like
a
rough
plan,
not
rough,
but
the
very
initial
plan
that
we
had
come
up
with
like
we
would
start
off
with
the
competitor
evaluation
and
then
from
there
The
Villages
like
see
how
confident
we
are
with
the
user
stories
that
we
end
up
with
and
then
like.
What
do?
We
need
to
do
next
to
like
gain
more
confidence,
so
I-
wouldn't
just
like
be
very
stuck
to
this,
but
rather
I
would
move
to
how
we
kept
on
adding
each
step
here
so
like
through
the
competitor
evaluation.
A
We
were
able
to
understand
what
are
the
industry
standards
expectations
we
have
to
align
with,
and
also
like
some
insights
from
what
about
the
work?
Philosopher,
competition
did
their
users
face
problem
with
so
like
trying
to
avoid
the
same
pitfalls
as
others
were,
but
besides
getting
an
idea
about
the
like
overall
user
flow,
which
was
pretty
simple
when
we
looked
at
from
like
a
bird's
eye
view,
so
it
was
about
adding
a
secret
accessing
a
secret
and
managing
a
secret,
and
we
also
learned
that
most
competitor
offerings.
A
They
were
really
difficult
to
set
up,
as
I
had
mentioned.
Previously,
they
lacked
real-time
feedback.
Not
many
were
able
to
provide
a
really
good
communication,
Channel
between
Ops
developers
and
compliance,
and
they
were
also
not
like
they
couldn't
do
a
great
job
at
integrating
Secrets
workflow
with
other
software
development
processes,
which
some
was
something
that
we
can
definitely
do
differently,
leveraging
the
power
of
our
platform.
A
So
combined
with
previous
extensive
surveys
on
Secrets.
This
gave
us
some
idea,
of
course,
about
like
which
direction
we
have
to
go,
and
so
we
thought,
like.
We
are
in
a
good
position
to
like
start
discussing
internally
like
how
each
one
of
us
perceived
how
what
this
whole
thing
would
be
like.
So
we
did
a
sketching
exercise,
and
this
was
really
engaging
the
whole
team
joining
they
participated
with
like
a
lot
of
enthusiasm.
They
collected
examples.
A
They
drew
many
like
they
drew
out
Visionary
markups
of
what
they
had
in
mind,
and
this
was
a
great
opportunity
for
us
to
kind
of
get
on
the
same
level
of
understanding,
because
that
was
really
important,
since
we
were
trying
to
work
on
something
so
huge.
So
we
took
these
user
stories
that
we
initially
I
would
say
had
like
30
to
40
percent
confidence
on,
and
then
we
based
this
whole
exercise
on
that
and
what
we'd
received
from
here.
Those
further
informed
our
like
future
plan.
A
So
using
this
exercise
we
were,
we
like
were
able
to
understand
what
are
the
must-haves
nice
to
have
and
the
pitfalls
in
a
Secrets
concept,
and
this
like
helped
us
get
an
idea
about
what
our
MVC
should
look
like,
because
the
must-haves
they
had
to
make
it
to
the
MVC,
because
I
mean
when
it
comes
to
the
user
stories.
For
this
particular
feature,
we
realized
that
we
cannot
break
the
chain.
So
I
would
like
yeah
come
to
this,
so
that
we
can
talk
more
about
it.
A
So
we
started
to
like
keep
record
all
document,
the
user
stories
in
this
way
and
yeah.
So
we
realized
that
we
cannot
break
this
chain,
but
what
we
could
do
through
iterations
is
probably
like
keep
getting
to
the
depth
of
each
one
of
this.
A
Like
entry
enrich
each
of
these
steps
in
a
way
that
keeps
on
adding
value
for
our
users
and
the
next
step
from
here,
because
now
we
had
a
set
of
now,
we
had
a
very
good
idea
about
what
we
need
to
build
and
the
obvious
Next
Step
was,
of
course,
to
like
reach
out
to
our
users
and
that's
when
we
came
up
with
our
very
first
prototype,
which
had
all
like
the
most
primary
functions
built
in
all.
A
What
we
perceived
were
primary
at
that
point
and
it
like
allowed
users
to
view
secrets
like
access.
The
secret
storage
then
create
a
secret
and
eventually
like
also
come
and
like
make
edits
to
that,
manage
that,
and
we
took
this
prototype,
we
formed
a
task
around
the
user
stories
that
we
had
with
us
and
we
shared
it
with
our
users
and,
of
course,
like
nobody,
helped
out
their
true
feelings,
which
was
really
helpful
for
our
team
to
be
able
to
proceed
and
that's
fair.
A
A
They
were
trying
to
see
if
it
can
work
in
tandem
with
something
else
that
they
were
using,
while
like
there
were
a
set
of
users
who
were
just
trying
to
see
if,
like
this,
can
complement
their
gitlab
CI
CD
setup
and
help
them
like
get
the
most
out
of
it
and,
along
with
that,
they
also
shared
like
what
would
work
for
them.
What
won't
work
for
them
and
what
they
really
appreciated
now
I
would
share.
A
Just
one
slide
from
Erica's
deck
like
I
was
not
sure
if
everything
else
was
too
confidential
to
share
in
our
presentation,
but
anyway,
this.
A
This
was
really
surprising
for
us
that
we
were
like
since
the
beginning,
trying
to
record
the
customers,
like
their
user
satisfaction
with
the
competitor
offering
they
were
using
and
after,
like
the
survey
that
we
had
just
sent
out,
the
responses
indicated
that
their
satisfaction
level,
with
what
they
had
just
seen,
which
was
this
prototype,
was
more
than
what
they
had
with
the
with
whatever
they
were
using
already
and
like.
A
This
was
a
really
encouraging
indicator
for
us,
but
at
the
same
time,
we
knew
like,
based
on
the
feedback,
that
we
still
had
a
lot
of
work
to
do
and
that's
how
we
got
to
The
Next
Step,
which
is
like
finally
coming
down
in
like
getting
deeper
into
designing
a
prototype
for
MVC
or
what
we
perceive
as
very
close
to
the
MVC,
because,
like
we
have
a
much
like
much
higher
confidence
in
the
situation
that
we
are
building-
and
this
is
something
that
the
technical
team
can
finally
like
get
on
with
it
like
they
can
start
thinking
about
how
to
implement
this,
especially
the
front-end
features.
A
A
Then
there
were
some
really
good
insights
about
how
we
were
presenting
environments
and
what
users
plan
to
do
with
those
environments
and
based
on
that
be
like
added
a
few
more
capabilities
like
you
would
be
able
to
add
more
than
one
environments
at
a
time,
and
there
should
always
also
be
an
option
to
like
have
secrets
which
are
environment
agnostic
for
the
lack
of
words,
because
it
sometimes
a
secret
is
not
related
to
cicd
and
yeah.
A
So,
like
this
whole
workflow,
it
went
through
a
good
revamp
and
we
made
sure
that
we
are
only
giving
to
users
what's
absolutely
necessary
for
them
in
the
very
first
iteration
that
we
plan
to
share
and
like
these
highlighted
ones,
are
the
ones
that
we
are,
including
in
the
MVC
everything
else
we
have
left
and
we
plan
to
like
get
deeper
into
it
in
the
future.
Iterations,
so
One
Vision
that
we
have
for
future
iterations
is
a
higher
amount
of
control.
A
Secret
management
is
a
lot
about
like
control
the
related
to
access
permission
related
to
like
how
you
want
them
to
rotate
expire.
So
we
would
only
like
make
these
features
more
advanced.
A
As
you
proceed,
but
we
started
to
like,
we
wanted
to
start
up
with
something
very
basic,
yet
functional
and
yet
very
useful
and
I
think
we
have
been
able
to
like
hit
that
Milestone
now
next
up
for
us,
is
sending
out
assignment
number
two
to
our
early
adopters
group
and
see
like
what
they
feel
about
this
particular
draft
of
design
proposal,
and
this
is
where
we
are
at
with
secrets.
We
have
made
a
lot
of
progress
in
now.
We
are
keeping
our
fingers
crossed
and
that's
it.
A
That's
the
end
of
presentation,
but
I
would
like
really
appreciate
to
hear
from
team
members
like
what
do
you
think
about
this
approach
and
what
is
something
else
that
they
did
in
the
past
that
helped
them
gain
more
confidence
in
the
vision
of
what
they
were
building,
especially
if
they
were
building
something
from
like
scratch.
A
C
C
First
I
I
can't
say
that
I've
well,
I
I
did
create
the
first
like
configuration
of
scanners
in
for
security
scans,
and
your
question
was
basically
how
do
you
feel
confident
about
building
something
from
scratch
like
not
making
improvements
on
it,
but
was
that
your
question
like
how
do
you
feel
confident
about
the
MVC.
A
C
Yeah
I
mean
for
that
product
that
I'm
thinking
of
with
the
SAS
configuration
UI
it
was.
It
was
going
to
be
helpful
to
have
anything
any
in
the
UI
to
make
it
more
of
a
guided
workflow
rather
than
having
the
documentation
the
docs
up
on
one
side
of
the
page
and
like
the
yaml
file
on
the
other
side
of
the
page
or
different
monitors
whatever
so
I
I,
also
like
tested
with
a
prototype,
understood
like
the
tasks,
the
primary
jobs.
C
Excuse
me
that
users
would
want
to
complete
and,
of
course,
there
were
like
primary
jobs
and
secondary
jobs
and
tertiary
jobs,
so
just
making
sure
that
they
could
easily
complete
the
primary
jobs.
C
That
was
the
focus
for
for
MVC,
but
I
have
a
similar
question
when
it
comes
to
like
how
do
we
know
for
sure,
what's
really
important
for
MVC
versus
future
iterations,
because,
like
with
the
research
that
I'm
about
to
present,
do
you
just
go
off
of
like
what
people
bring
up
on
their
own
or
because
sometimes
you
can
just
like
show
them
a
prototype,
and
they
can
say
this
is
great.
But
this
is
missing
or
I.
C
Don't
need
this,
but
I
think
it's
always
challenging
to
like
show
a
design
that
has
some
ideas
in
it,
but
then
get
them
to
Think
Through,
exactly
what
is
missing
like
really
have
them
test
it
and
communicate
like
what
is
the
most
important
things
here
for
you
versus
like
need
to
have
you
versus
a
nice
to
have
kind
of
thing.
A
Right,
that's.
A
Yeah
yeah,
so
something
that,
like
really
helped
our
team
with
this,
was
like
in
one
of
the
research
reports
by
Erica,
like
the
research
team,
had
really
captured
the
most
important
use
cases
that
users
had
mentioned
when
it
comes
to
secrets.
So
that
was
our
starting
point
like
we
started
off
from
there
and
we
like
took
it
to
our
like.
We
started
to
have
discussions
around
it
internally,
just
to
have
like
a
higher
level
of
conviction
among
ourselves.
A
First
now,
based
on
that
conviction,
we
formed
the
assignments
like
we
decided
on
the
tasks
that
we
are
going
to
give
to
users
so
that
they
would
be
able
to
relate
better
with
it
when
they
are
like
assessing
what
we
have
we
are
showing
to
them.
But
even
in
the
questions
that
we
like
shared
with
them,
we
made
sure
that
we
get
to
understand
like
what
emphasis
they
are
putting
on
what
they're,
seeing
the
different
elements
that
they're
seeing
on
the
screen
and
from
the
responses.
A
It
kind
of
became
somewhat
clear
to
us
that
there
are
some
parts
that
nobody
talked
about.
There's
some
parts
that
everybody
was
very
finicky
about
that
hey
I
would
want
to
use
this
in
a
very
certain
way,
so
we
also
schedule
some
interviews
with
the
respondents
like.
Can
you
talk
more
about
this?
What
exactly
you
had
Envision
and,
like
all
this
information
put
together,
it
gave
us
like
an
idea
about
what
is
it
that
we
cannot
do
without
like
what
absolutely
has
to
be
there?
A
C
A
Yeah
so
follow-up
questions,
I
would
say
because,
like
the
moment,
you
put
I'm
in
any
amount
of
leading.
Hence
there
it
just
gives
an
answer
that
would
we
want
from
them,
so
the
tasks
that
we
had
designed.
We
made
sure
that,
like
it
was
realistic,
it
was
something
that
they
were
able
to
like
connect
with
something
that
would
they
would
be
coming
across,
and
then
we
just
asked
them
like.
A
How
would
you
go
about
accomplishing
this,
given
this
UI,
so
the
themselves
like
gave
a
walk
through
about
how
they
would
do
things,
and
then
we
also
had
some
questions
very
open-ended
questions
about
like
what
are
the
use
cases
that
we
that
youth
like
come
across
day
to
day,
that
we
are
kind
of
like
missing
out
here
and
that's
how
we
get
got
more
idea
about
what
they
would,
what
more
they
would
want
to
do
with
it.
C
Yeah
that
reminds
me
in
this
last
study
that
I
did
a
lot
of
people
would
look
at
the
Prototype
and
say
yeah.
This
is
helpful,
like
I
I
had
questions
about
like
what
would
you
want
to
group
by?
What
would
you
want
to
filter
by
and
they
would
come
up
with
things
like
they'd
rather
tell
me
like
that
they
would
use
it,
but
then
not
actually
need.
It
then
say
like
I'll.
C
Never
need
this,
but
of
course,
like
you
know,
on
our
side
of
things,
building
things
out,
we've
got
to
prioritize
like
what
the
team
is
going
to
work
on,
so
something
that
I
think
really
helped
is
I.
Would
I
would
dig
in
a
little
bit
more
and
say
like
we
provide
a
use
case
in
which
you
would
use
that,
and
that
would
really
get
them.
Thinking
like
and
then
sometimes
I
heard
like
well
I
guess
it
would
be
rare
that
I
would
use
that
you
know.
So
that
starts
to
determine
the
priority
too
yeah.
B
And
before
we
end,
I
also
wanted
to
mention
that
another
facet
of
the
jobs
to
be
done
that
the
research
team
has
been
working
on
I,
think
Michael
Oliver
has
been
sort
of
spearheading,
it
is
ODI
outcome,
driven,
Innovation
and
part
of
that
is
to
look
at
your
jobs
and,
after
you've
broken
that
down
into
needs.
You
take
those
needs
and
you
can
assess
them.
It's
like
a
Kano
analysis.
C
C
Have
them
rank
their
current
tools
if
they're,
not
gitlab
and
then
and
then
I
I'm
guessing
the
Prototype
was
what
they
were,
comparing
it
against,
which
I
mean
you
know
is
tricky
because
performance
isn't
coming
into
play
with
the
Prototype.
It
probably
is
in
in
their
actual
tools
things
like
errors
and
stuff
like
that,
so
right,
but
it's,
but
it's
still
an
interesting
way
to
to
measure
whether
or
not
it's
an
improvement.