►
From YouTube: UX Showcase Simplifying complexity
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
A
Hello:
everyone
today,
I,
am
here
to
talk
to
you
about
simplifying
complexity,
and
so
in
my
last
ux
Showcase
in
August
I
was
encouraged
by
Vivica
to
speak
about
this
topic.
So
how
can
we
simplify
the
complexity
in
gitlab?
It's
a
I
think
a
question
that
is
on
everyone's
Minds
every
almost
every
day.
This
is
also
something
I
discussed
recently
at
an
event
organized
by
outsystems,
a
local
platform
as
they're
facing
similar
challenges
of
complexity
that
we
do
and
throughout
this
presentation,
I
added
links
to
learning
resources.
A
In
case
you
wanted
to
dig
more
into
a
particular
concept,
because
there
are
many
things
I
mean
we
could
dedicate
the
presentations
each
one
of
those
Concepts.
So
yeah.
Let's
do
this
for
those
of
you
who
don't
know
me:
I'm
Pedro,
I'm,
a
Staff
product
designer
and
I'm,
a
maintainer
of
our
design
system.
Pajamas
I've
been
at
gitlab
for
almost
seven
years.
A
A
I
was
fortunate
enough
to
participate
in
an
amazing
workshop
with
Jared
spool
and
Dana
chisnell
renowned,
ux
experts
about
designing
for
the
lights,
and
there
were
so
many
great
things
there,
but,
among
other
things,
we
worked
on
answering
this
question:
how
can
we
Inspire
our
organization
to
go
beyond
shiny
features
with
products
and
services
that
deliver
remarkable
Delights?
A
And
this
is
you
know,
a
great
quench
question
to
answer.
This
presentation
is
inspired
by
a
lot
of
what
I
learned
that
day.
So
before
we
get
into
the
how
we
can
deal
with
complexity,
let's
understand
how
and
why
complexity
affects
gitlab,
a
great
concept
to
frame
this
complexity.
Challenge
is
experience
rot,
introduced
by
Journal
spool,
it's
fairly
straightforward,
experienced
Rod,
builds
up
as
products
slowly
add
more
and
more
features
in
an
effort
to
surpass
users
expectations
and
beat
the
competition.
A
The
problem
is
that
many
of
those
features
are
actually
not
essential
to
users
or
were
not
considered
in
the
original
design.
We've
all
been
there
right,
so
more
features
means
more
complexity
and
worse
experience.
One
side
effects
of
experience
rot
is
that
the
complexity
increases
the
cost
to
support
and
skill.
The
product
and
as
Jared
explains
it
not
only
makes
design
and
development
difficult.
It
puts
the
entire
organization
at
risk
to
understand
the
experience
rot
in
practice.
A
Let's
look
at
the
Kino
model,
so
this
model
was
developed
in
Japan
in
the
1980s
by
Professor,
noriaki
Kano
after
analyzing
how
different
companies
spend
their
money
and
the
resulting
customer
satisfaction,
and
so
here
on
the
horizontal
axis,
we
can
see
how
much
product
investment
is
made.
You
can
think
of
this
as
the
level
of
feature
you
know,
functionality
sophistication
or
how
well
it
is
implemented
and
on
the
vertical
axis,
it's
how
much
customers
are
frustrated
or
satisfied,
and
he
identified
several
categories
to
map
the
product
Investments
to
this
model.
A
The
first
one
is
performance,
payoffs,
so
better,
but
complex
right.
This
is
the
kind
of
Investments
that
the
more
you
invest,
the
more
satisfied
customers
become.
It's
the
typical
make
it
better
by
adding
more
and
more
features
right.
The
main
issue
is
that
you
have
to
keep
investing
to
get
more
satisfaction,
and
while
this
is
happening,
the
product
is
becoming
more
and
more
complex.
The
second
is
basic
expectations,
and
these
are
the
must-haves,
the
things
that
customers
naturally
expect
that
don't
even
need
to
be
mentioned.
A
An
example
in
gitlab
is
editing
a
file
through
the
web
UI
without
having
to
clone
the
repository
to
your
local
machine.
These
basic
expectations
don't
get
praised
by
our
customers,
but
they
get
really
frustrated
if
they're,
not
there
and
the
third
most
exciting.
Also
whose
name
is
the
excitement
generators?
A
Yet
another
approach
to
the
light
is
by
removing
friction
from
the
user's
Flow,
by
making
a
task
faster,
shorter
or
simpler.
To
complete
a
flow
example
in
gitlab
is
making
it
quicker
for
users
to
start
working
on
their
project
by
pushing
a
readme
file
to
the
repository
when
the
project
is
created
and
the
ultimate
approach
to
the
lights
is
infusing,
meaning
into
the
experience.
A
For
example,
in
gitlab,
our
user
profile,
badges
highlight
user
contributions
and
accomplishments,
helping
create
a
sensitive
community
and
purpose,
and
because
we
don't
have
all
the
time
in
the
world
for
this
presentation,
I'll
just
be
focusing
on
the
performance
payoffs
and
the
basic
expectations
and
performance
payoffs
in
gitlab
is
usually
where
we
tend
to
invest
in
and
I'll
show
you
in
a
bit
why
this
happens.
Our
most
recent
qualitative
analysis
of
the
sus
verbatim,
driven
by
Erica,
suggests
that
we're
not
making
progress
in
terms
of
meeting
user
expectations.
A
We
also
received
an
increased
amount
of
feedback
that
our
product
is
not
intuitive
and
is
complex
confusing.
So,
generally
speaking,
this
is
usually
a
result
of
misunderstanding.
One
users
value
knowing
their
basic
expectations
and
what
makes
them
excited
and
if
we
are
over
investing
in
performance
payoffs
we
are
creating
experience
rods
at
gitlab.
Avoiding
experience
rot
is
a
constant
challenge
for
us.
Why?
First,
let's
look
at
the
four
phases
of
devops,
so
in
the
first
three
phases
bring
your
own
Best
in
Class
and
do
it
yourself?
A
A
So
basically,
what
this
means
is
that
gitlab
is
competing
with
specific
tools
and
although
these
tools
usually
require
custom
integration
and
are
smaller
scope,
they
are
more
focused
and
aren't
as
prone
to
experienced
Rod
as
gitlab.
And
how
are
we
competing
with
those
specific
tools?
Our
product
has
eight
stages
and
more
than
50
categories.
So
this
means
that
we
replace
dozens
of
specialized
tools
and
consolidate
hundreds
of
features
under
a
single
experience,
and
this
is
fertile
ground
for
experienced
rod.
A
At
the
same
time,
gitlab
has
two
flywheel
strategies
that
reinforce
each
other.
The
open
core
flywheel
and
the
developments
planned
development
span,
flight
wheel
so
being
an
open
core
product
is
both
an
advantage
and
a
challenge
and
Advantage
for
us
is
that
it
enables
Innovation
from
git
lab
and
also
Innovation
from
The
Wider
Community.
That's
great.
Every
quarter,
as
we
know,
hundreds
of
improvements
are
contributed
by
our
customers
and
users.
More
contributions
can
lead
to
more
features
which
can
lead
to
more
users
in
this
virtuous
cycle.
A
The
challenge
is
how
well
we
can
manage
this
cycle
and
avoid
experience
right.
More
Innovation
is
great,
as
it
allows
us
at
the
same
time
to
cover
more
grounds
of
the
software
development
life
cycle.
We
go
beyond
developers
and
start
including
business
security
and
operations.
People.
We
all
know
this
right.
The
challenge
is
how
to
cater
to
many
personas
in
the
same
UI.
This
table
shows
how
personas
typically
use
the
stages
of
kitlab
in
some
stages,
serve
8,
11
or
even
15
personas.
A
At
the
same
time,
right
and
finally,
adding
to
this
challenge,
we
have
our
seed,
the
nurture
strategy
principle
and
just
very
quickly,
quoting
our
handbook.
If
you're
not
familiar
with
this
strategy
principle,
it
says
when
we
are
early
in
a
particular
area
of
the
product
we
will
plant
seeds
by
shipping
a
small
MVC
and
shipping
functionality
that
is
incomplete
to
expand.
The
scope
sometimes
goes
against
our
instincts.
A
However,
planting
those
seeds,
even
in
in
an
incomplete
state,
allows
others
to
see
our
path
and
contribute
and
with
others,
contributing
we'll
iterate
faster
and
will
accelerate
the
maturity
of
our
offering
faster
than
gitlab
could
on
its
own.
We
can
have
a
long
tail
of
categories
that
are
at
a
minimal
maturity
that
don't
get
investment
until
they
show
traction.
A
My
second
moment
to
breathe
together
this
was
a
lot
in
a
short
time,
breathe
in
breathe
out.
Okay,
let's
move
on
to
the
fix
it
Parts
I
guess.
So
how
can
we
address
this
complexity?
Tell
me
Pedro
tell
me:
how
can
we
do
this?
I
can't
take
it
anymore,
so
finding
experience
right
is
mostly
about
product
judgments
and
strong
leadership.
A
So,
first
of
all,
you
have
to
study
the
essential
features
that
users
care
about
and
maintain
a
vision
for
the
experience
that
only
includes
those
features
and
that
may
involve
removing
features
with
every
release
and
users
will.
Thank
you
will
thank
us
for
that
right
and
just
because
you
can
add
that
feature
or
make
that
change.
A
It
doesn't
mean
you
should,
as
Steve
Jobs
once
said,
you'd
have
to
be
carefully
I'm
actually
as
proud
of
the
things
we
haven't
done,
as
the
things
I
have
done,
Innovation
is
saying
no
to
a
thousand
things
and
product
designers
in
ux
researchers
play
a
key
role
here.
We
must
help
product
management,
make
informed
decisions
and
ultimately
say
no
more
than
yes.
A
This
is
all
beautiful
right.
This
is
sounds
great.
How
do
we
do
this,
so
we
can
try
to
use
the
tools
that
already
have
at
our
disposal
like
jobs,
to
be
done
where
we
understand
what
users
are
trying
to
achieve.
We
can
also
use
a
Kano
survey
to
understand
what
users
value,
what
are
the
basic
expectations,
the
performance
payoffs
and
the
excitement,
generators,
and
with
this
information
we
can
have
better
product
judgments.
But
how
can
we
make
this
actionable
after
we've
understood
our
users?
A
This
is
the
typical
roadmap
right
that
commits
teams
to
implement
specific
features.
It
is
oriented
around
Solutions
solutions
that
we
don't
even
know
if
they
are
the
right
ones
and
that
header
innovation
instead,
what?
If
we
replace
this
list
of
features
with
descriptions
of
the
jobs
that
people
are
trying
to
achieve
the
jobs
to
be
done
and
the
user
problems?
A
This
is
what
a
ux
roadmap
looks
like,
and
many
of
you
and
many
teams
have
already
gone
through
this
process
right,
it's
centered
around
the
user
and
their
problems
and
opens
up
exploration,
we're
committed
to
addressing
problems,
not
implementing
predetermined
Solutions,
and
so
with
the
the
ux
roadmaps
and
the
themes.
We
can
turn
the
information
we
have
from
the
jobs
to
be
done
and
the
Kano
survey
into
something
actionable,
and
this
is
the
bridge
at
the
link
between
product
judgments
and
design,
judgments
and
designers.
Designers
fall
in
love
with
the
problems.
A
They
don't
fall
in
love
with
the
solutions
and
when
you
fall
in
love
with
problem,
that's
when
you
can
aim
for
sophisticated
Simplicity,
which
is
something
that
many
of
you
may
have
heard
right
in
this
battle
against
complexity.
We've
seen
that
experience
rot
is
mostly
about
product
judgments,
avoiding
the
wrong
things
going
into
the
products
and
now
for
design
judgments.
A
We
look
at
sophisticated
Simplicity,
and
so
this
term
was
coined
by
Marcel
wire,
after
studying
the
work
of
Steve
Jobs
and
Robert
Heinlein,
an
American
science
fiction,
author
and
aeronautical
engineer,
and
there
are
three
levels:
the
first
one
naive
simplicity.
That's
your
first
attempt
at
solving
a
problem.
It's
a
simple
solution,
because
you
don't
fully
understand
the
problem
and
it
meets
the
minimum
expectations.
And
after
that
you
start
to
understand
how
complicated
the
problem
really
is,
and
you
get
into
sophisticated
complexity.
A
The
solution
becomes
much
more
complex
to
try
to
overcome
the
shortcomings
of
the
first
attempt
so
now
you're
compromising
the
experience
in
favor
of
complexity
to
meet
expectations,
and
it's
only
when
you
dedicate
yourself
to
understand
the
underlying
principles
of
the
problem
that
you're
able
to
reach
nirvana
right,
sophisticated
Simplicity,
that's
what
we're
aiming
for,
and
so
now
you
deeply
understand
how
things
work
and
the
most
important
parts.
The
solution
is
now
sophisticated,
but
not
complex.
A
It
is
simple,
but
not
basic
and
the
designated
gitlab
we've
come
a
long
way
and
we've
gone
through
a
Simplicity
to
sophisticated
complexity
and
every
day
we're
aiming
for
the
Nirvana.
The
sophisticated
Simplicity
and
particularly
relevance
to
the
topic
of
complexity
are
the
tenets
of
structure
and
capability.
So
if
we
focus
too
much
on
structure
and
capability,
we
get
sophisticated
complexity
wherein
everything
all
the
time
interface
provides
a
lot
of
functionality,
but
the
discovery
cues
that
lead
to
learning,
Association
and
understanding
cause
and
effects
on
presence.
A
So
let
me
repeat
that
to
you
Discovery
cues,
that
lead
to
learning,
Association
and
understanding
cause
and
effects,
and
that's
a
lot
of
the
feedback.
The
negative
feedback
that
we've
been
getting
from
our
users
that
it's
difficult
to
learn,
gitlab
it's
difficult
to
understand
the
cause
and
effect
and
to
associate
the
different
parts,
and
so,
on
the
other
hand,
sophisticated
Simplicity
is
an
interface
that
reduces
friction
that
provides
quick
access
to
powerful
features
and
helps
all
users
become
more
proficient
at
completing
tasks.
A
This
all
sounds
wonderful,
but
how
can
you
get
started
and
so,
in
our
handbook
we
have
a
few
questions
and
here's
just
a
glimpse
of
questions.
You
can
ask
yourself
when
designing
towards
sophisticated
simplicity.
So,
first
of
all,
does
this
content
or
functionality
need
to
be
visible
all
the
time
and
for
everyone?
A
Second,
is
the
structure
in
support
of
Discovery
and
use
of
advanced
capabilities?
And
third,
is
this
feature
in
our
capability
even
needed
or
used,
or
what
would
happen
if
it
was
removed?
You
you
might
notice
that
I
throughout
this
presentation,
I've
been
hitting
on
the
removal
part
a
lot
and
I'll
show
you
more
in
a
little
bit.
A
So,
let's
put
it
all
together.
First
of
all,
without
a
clear
understanding
of
your
users,
you're
stuck
right
jobs
to
be
done.
Tell
you
what
users
are
trying
to
achieve
and
the
Kano
survey
tells
you
what
they
value.
Remember:
basic
expectations,
performance,
payoffs
and
excitement
generators,
and
you
can
actually
start
already
start
looking
at
opportunities
to
prune
experienced
rot
by
removing
unused
features.
So
you
can
already
start
doing
that,
even
without
that
clear
understanding,
even
if
you
don't
have
data
to
back
that
up.
A
Third,
with
ux
roadmaps
and
themes,
we
shift
from
committing
to
features
to
committing
to
problems
which,
in
turn,
give
you
the
room.
You
need
to
understand
the
underlying
principles
of
the
problem,
so
that
you're
able
to
reach
sophisticated
Simplicity
and
finally-
and
this
is
something
that
I
didn't
talk
much
about
today-
because
we
don't
have
time
for
everything-
is
the
excitement,
generators,
the
design
for
the
lights
that
would
probably
warrant
another
ux
showcase.
A
So
for
the
time
being,
I
just
leave
you
with
these
two
links
in
case
you're
interested
in
learning
more
and
this
is
it
for
me:
I,
it's
I,
just
I,
think
I
kind
of
structured
and
repeated
a
lot
of
the
information
that
we
already
have
in
our
handbook
and
maybe
give
it
a
bit
more
of
of
the
body
but
I'm
looking
forward
to
your
questions,
so
add
them
to
the
agenda
documents
and
to
get
this
going
here
are
some
prompts.
A
How
are
you
struggling
or
dealing
with
complexity
today
in
something
that
you're
working
on
and
what
other
tools
and
practices
can
we
use
to
fight
experience,
rot
and
aim
for
sophisticated
Simplicity,
something
that
I
maybe
didn't
mention
today?
That
would
be
helpful
for
everyone
and
that's
it.
Thank
you.
So
much.
B
We
don't
have
a
huge
group
here,
but
I'm
curious
to
hear
what
y'all
think
about
those
prompts
that
you
posted,
because
it's
one
thing
for
us
to
realize
it
and
have
this
knowledge
another
thing
to
try
and
accomplish
it
with
the
our
counterparts
so
I'd
be
curious.
What
y'all
think
about
that,
if
you're
still
awake,
not
that
Pedro
was
boring,
I
found
it
very
interesting.
That's
not
what
I
meant
I
just
can't
see
in
his
face,
except
Erica's
fingers.
A
Yeah,
given
that
that
Jeremy's
on
the
call
I'm
gonna
put
you
on
the
spot,
Jeremy
in
case
you
have
anything
you
want
to
share
about
the
sophisticated
Simplicity
Parts
that
you
I
think
were
the
first
person
that
could
glad
to
to
talk
more
about
it
and
explore
it
more
so
yeah.
If
you
have
anything
else,
you
would
like
to
share.
C
It's
a
challenge:
I
could
say
that
I
know
that
one
thing
I
think
that
several
designers
are
feeling
is
that,
during
like
component
migrations,
for
example,
I
was
just
discussing
this
earlier.
C
The
concept
of
sophisticated
Simplicity
is
is
coming
up
kind
of
in
a
back
door
where
you're
migrating
and
existing
an
experience
to
a
new
component
and
the
old
experience.
Maybe
they
had
like
a
bunch
of
extra
complexity
or
content
or
interactions
that
the
new
component
might
not
support,
and
so
it's
an
opportunity
to
look
at
rethinking
that
experience
and
actually
aiming
for
something.
That's,
maybe
more
simple
or
more
more
boring
for
lack
a
better
term
and
and
so
I've
seen
it
come
up
there.
C
That's
just
top
of
mind.
So,
since
you
put
me
on
the
spot,
I'm,
not
sure
anything
else,
but
yeah
anything
specific
you'd
like
me
to
answer
more
specific
than
that
I
suppose.
A
Oh
no,
no!
No!
That's
that
that
was.
That
was
a
good
example,
especially
related
to
the
word
that
you're
doing
in
foundations
and
an
opportunity
to
to
aim
for
sophisticated
Simplicity.
It's
almost
like
an
ideal
I!
Guess
you
don't
ever
reach
it.
You
try
to
reach
it.
So
thanks
for
sharing
that.
C
A
C
Suppose,
as
a
follow-up,
maybe
I
can
take
a
prompt
to
as
part
of
those
migrations
to
as
we
we
don't.
We
don't
always
understand
all
the
use
cases
and
and
the
historical
decisions,
but
in
much
in
the
way
we
do
with
the
UI
kit,
when
we
update
a
component
Dan's,
really
good
about
saying,
okay,
here's
how
you
use
the
new
one
and
here's.
Why
and
here's
the
things
that
have
changed?
C
Perhaps
we
could
start
to
do
some
of
that
more
rigorously
with
component
migrations
to
say
you
know:
hey
we've
removed
this
complexity
in
this
component.
Here's
why
here's,
how
you
can
migrate
to
it
or
rethink
your
experience
to
adapt
rather
than
just
a
one-to-one,
you
know
flip
the
switch,
so
there
might
be
some
things
that
we
can
think
through
in
the
future.
So
I
think
that
that's
kind
of
a
helpful
prompt
for
foundations.
So
thank
you.
D
Yeah
Pedro
I
was
curious
to
get
your
thoughts
around.
Do
you
have
tips
on
how
I
might
be
able
to
accommodate
like
a
vocal
minority?
This
could
come
through,
like
hey
I've
submitted
a
merger
request
for
something
that
I
find
is
like
a
preference.
I
would
like
to
have
a
shortcut
option
here
and
on
the
surface
you
know
it
might
seem
like
this
is
an
innocent
change,
but
I
think
what
you're
getting
at
earlier
was.
D
That's
usually
where
I
run
into
like
oh
yeah
I
mean
this
seems
fine,
but
then
I'm
like
oh
did
we
does
this
help?
Everybody
is
this
helping
just
one
person,
I,
don't
really
know
I,
don't
know
this
area
super
well.
What
are
your
thoughts
around
that
when
we
see
those
kind
of
ideas
come
through
either
in
our
issue
of
backlog
or
emerge
requests
or
whatever
it
might
be?.
A
E
A
Either
it's
something
that
we've
entertained
in
the
past
as
part
of
our
you
know,
product
Discovery,
work,
I'm
thinking,
you
know,
for
example,
it's
not
something
small,
it's
actually
something
big,
but
it's
a
it's
a
feature
request.
We
have
for
blocking
approval.
So
it's
like
a
negative
approval
signal,
the
opposite
of
our
approve
button
in
Mrs,
and
that
has
been
Revisited
and
we've.
We've
touched
on
that
for.
E
A
Know
for
some
time-
and
we
have
kept
saying
no
to
that
and
we've
we're
able
to
build
a
specific
rationale
for
why
we're
not
doing
it.
We
were
able
to
distill
the
problem
and
understands
the
basic
parts
of
it.
A
So
I
think
part
of
that
is
just
finding
time
to
to
do
that
problem
valuation
and
if
it
is
really
something
important
or
if
it
is
like
a
small
user
preference,
but
maybe
you
see
that
we're
we're
probably
going
to
open
the
Pandora's
Box
like
it's,
it's
a
minimal
thing,
but
other
people
will
will
try
to
do
something
similar
somewhere
else.
I
think
it's
worth
to
pause,
and
maybe
it's
more
worthwhile
to
say
no
and
to
say
Yes
and
the
other
thing
is.
Maybe
we
can't
afford
the
time
to
do
it.
A
A
We
have
to
we're
doing
this,
but
we're
going
to
follow
through
and
we're
going
to
be,
like
the
police
of
new
features,
new
options,
new
settings,
new
preferences
and
if
it's
not
going,
it's
not
being
used
or
if
we
do
research
on
it,
and
we
realize
that
it's
not
helpful
that
it's
actually
deterring
us
from
doing
other
things.
We
will
be
bold
enough
to
remove
it
and
I'd
like
to
see
that
more
at
gitlab
and
again
that
goes
back
more
to
we
can
influence
it
as
designers
and
ux
researchers.
D
Yeah,
those
are
all
fair
points,
I
think
a
personal
reflection
of
mine
is
it
almost
feels
like
our
issues.
Backlog
is
a
representation
of
this
creep
that
we've
had
like
I
think
when
I
started
in
2020
our
issues
list
had
like
30
000,
open
issues.
Now
I
got
60
000
open
issues.
D
We
don't
really
take
a
strong
stance
on
won't.
Do
we
just
let
things
sit
there
and
I
think
that
can
sometimes
lead
to
confusing
conflicting
issues
like
different
preferences,
like
oh
I,
want
option
A
versus
option
b,
so
maybe
that's
for
a
place
we
could
start
is
even
when
those
it's
easier
to
say
when
some
merge
requests,
because
this
is
merging
in
or
it's
not
and
then
it's
closed.
But
issues
is
usually
where
it's
harder,
where
it's
like.
A
Yeah
yeah:
it's
it's
a
challenge
for
sure
you
know
it's.
It
may
seem,
like
you
know,
with
this
presentation
that
I
have
everything
figured
out,
but
I,
don't
I,
don't
think
anyone
has
and
everyone
struggles
with
this.
But
it's
it's
part
of
the
work
right
this.
This
tension
is
maybe
it's
it's
the
part
of
our
work.
That
will
be
the
last
thing
to
be
replaced
by
AI.
I,
don't
know.
D
B
Thanks
my
thinking
was
a
possible
answer
is
to
reference
the
tools
that
Pedro
bought
up
the
jobs
to
be
done.
The
Kano
we've
recently
revamped
our
our
processes
for
doing
jobs
to
be
done
and
we're
incorporating
a
second
step.
B
It's
it's
more
of
a
ODI
of
the
side
of
the
jobs
to
be
done
model
and
where
you
assess
what
users
actually
want,
which
is
sort
of
the
whole
Kano
part
of
it,
and
that
will
help
understand
how
to
use
those
jobs
and
and
assess
your
requests.
Your
feature
requests
you
know,
so
you
could
probably
take
that
information
and
then
go
back
to
your
backlog
and
start
to
prune
by
saying
well,
yeah.
No
one
actually
wants
this.
B
We
can
probably
close
this
and
maybe
even
reference
the
data,
so
it
might
be
a
question
of
going
back
and
and
looking
at
your
jobs-
and
you
know,
do
I
have
high
confidence
in
these.
Do
I
know
that
these
are
for
real
and,
if
that's
the
case
then
start
to
measure
them
against
the
backlog,
and
that
is
also
another
reference
to
what
Pedro
brought
up
where
he
mentioned.
B
A
Yeah,
just
just
to
add
to
what
you
were
just
mentioning,
Justin,
which
I
agree:
I
think
you
know
the
things
that
come
from
the
side
and
issues
that
are
created
and
ideas
of
adding
this
preference
or
this
option
I
think
if
we're
able
to
map
out
the
main
job,
the
small
jobs
and
micro
jobs,
you
know
have
this
job
map,
and
maybe
we
can
say:
oh
we're
actually
prioritizing
this
theme
here
and
this
theme
we're
not
looking
a
lot
here
or
here,
but
we've
mapped
this
out
in
a
way
that,
if
someone
has
an
idea
for
this
step
or
this
specific
micro
job,
we
can
immediately
say
if
it
aligns
with
our
understanding
and
what
we
want,
what
what
users
want
to
achieve.
A
As
part
of
this
is
this
job
or
not,
and
if
it
does
not
fall
into
that,
maybe
it's
not
something
we
should
do
right,
yeah
and
I.
Think
I
mean
we've
come
a
long
way
in
maturing
all
of
this,
so.
E
A
Much
better
than
what
we
were
when
I
joined
seven
years
ago,
but
the
issue
now
is
dealing
with
a
lot
of
Legacy.
E
D
Yeah
and
the
the
other
side
of
that
coin,
that's
been
challenging
at
times
is
I'll.
Sometimes
here
we
have
customer
XYZ
with
thousands
of
seats.
They
need
this
and
I
actually
thought
our
fireside
chat
with
one
of
our
customers.
A
few
weeks
ago,
they
had
an
insightful
thought
where
they're
like
we're
a
really
large
organization,
and
we
are
going
to
probably
request
things
that
maybe
don't
make
sense
for
smaller
teams
or
other
and
the
complexity
of
gitlab.
D
Is
we
try
and
serve
both
these
people
try
to
serve
very
small
teams
and
ones
that
are
very
large
and
then
who
do
you
give
the
ultimate
preference
towards
that's,
usually,
where
I
end
up
feeling
the
tension?
It's
like
yeah.
This
would
be
great
for
the
team
with
5000
Engineers,
but
it's
completely
overkill
for
the
team
of
five.
A
C
D
A
Think
that
was
kind
of
clarified
in
that
Mr
a
couple
of
weeks
ago
about
design
judgment
where
it
is
really
important
to
care
and
kind
of
worry
about
that
tension.
But
the
end
at
the
end
of
the
day,
the
as
designers
and
researchers,
where
we
should
focus
our
efforts
and
energy
is
on
showing
the
pros
and
cons
and
the
trade-offs
in
helping
the
product
make
that
informed
decision.
A
Camellia
I
think
you're.
Your
next.
E
Yeah
so
I,
just
like
I
found
this
really
interesting.
When
you
talk
about
the
question,
we
ask
ourselves
like
this
visible
for
everyone
and
I
think
like
we
can
maybe
just
add
a
little
bit
more
question
and
I
could
maybe
create
a
checklist
to
help
us
to
like
on
detail
like
in
this
for
everyone.
It's
just
for
Persona
and,
like
a
very
simple
example,
is
like.
E
Is
this
really
for
people
new
to
gilab,
or
is
it
people
for
people
already
use
gilab
for
a
long
time,
so
the
dimension
of
users
not
only
Persona
and
like
their
role,
so
sometimes
I
feel
like
if
we
use
personal
Network
really
focus
on
just.
E
He
need
this
job
to
be
done,
but
like
a
little
bit,
look
over
of
like
the
experience
of
this
user
in
this
job,
and
we
can
just
add
some
additional
question
to
help
us
like
to
say
that,
can
this
be
done
by
a
new
user
and
if
that's
simple
enough
for
a
new
user
or
like
a
can
be
determined
for
advanced
people
who
can
they
directly
found
what
they
need
of
advanced
people?
They
don't
need
to
go
over.
E
Wizard
of
something,
so
all
those
questions
can
help
us
to
go
to
the
simplified
goal
and
I
think
maybe
with
the
collab
Collective
effort,
we
can
make
a
question
least
like
just
generally
as
a
checklist
we
ask
for
ourselves
could
be
a
good
idea
for
this.
Like
a
methodology,
that's
lead
us
to
simplicity,.
A
Yeah
I
agree:
I,
think
we
try,
generally
speaking
to
when
we're
doing
solution,
validation,
to
try
to
include
novice
and
and
more
experienced
users.
A
The
thing
I
like
about
sophisticated
Simplicity
in
the
way
we
describe
it
is
the
more
you
understand
the
problem
and
the
fundamental
parts
of
the
problem.
It
allows
you
in
theory,
to
design
an
experience
that
is
under
sustainable
by
all,
of
course.
In
our
case,
we
have
a
lot
of
other
constraints,
and
maybe
we
have
to
deal
with
technical
knowledge
and
domain
knowledge
that
is
difficult
to
just
quickly.
You
know
replace,
there's
also.
You
know
in
that
Workshop
that
I
had
with
with
Dana
chisenal
and
Jared
spool.
They
talked
about
that.
A
They
talked
about
the
difference
between
these
kinds
of
users
and
how
can
we
bridge
that
Gap-
and
there
are
basically
two
things
you
can
do?
One
is
you,
invest
in
training
and
you
basically
have
to
teach
users
to
use
the
thing,
and
there
are
many
ways
to
to
do
it.
But
that's
the
most
effortful
thing,
like
that's
you're,
asking
a
lot
of
effort
from
users
to
learn,
and
then
the
other
thing
is
trying
to
bring
down
the
the
the
required
knowledge
to
use.
A
Sometimes
we
forget
about
a
maybe
if
we
simplified
all
of
this,
we
can
actually
solve
the
same
thing
simply
for
80
of
the
use
cases
and
even
for
experienced
users
and
novice
users
would
be
you
know
good
with
it
as
well.
So
I
think.
Sometimes
we
get
up
trapped
in
our
own
design
process
because
we're
we're
power
users
of
git
lab.
We
tend
to
design
for
the
worst
case
scenarios
and
we
tend
to
design
for
complexity
in
a
way
right.
A
E
Yeah
I
agree:
we
can
bring
it
down.
I'm
also
curious,
like
from
the
research.
Do
we
know
that,
like
when
user
actually
really
gets
the
learning
curve,
and
do
they
found
it
easy
or
not?
E
So
that's
also
like
compelling
as
our
effort
to
bring
the
feature
down
to
easier
for
everyone
and
also
like
to
balance
the
power
users,
like
I,
think
from
the
research
like
I,
barely
hear
about
like
how
power
user
thinks
or
how
do
we
design
defined
power
users,
like
maybe
that's,
also
approved
evidence
when
it
convinced
like
the
product
managers
or
give
them
more
informations
that
we
should
think
about
the
users
who
has
less
background
knowledge
about
technology
or
something,
but
that
could
be
something
we
serve.
E
Yeah
I
have
a
second
point
is
related,
so
it's
like
just
related
with
the
topic
like
we
use
a
lot
of
like
a
technology
like
Inky
love.
So
recently
in
the
government
in
the
policy
settings
we
place
the
thing
that,
like
each
time
you
create
a
setting,
create
something
you
need
to
go
through
Mr
review.
So
you
change
something.
Basically,
you
are
changing
the
yaml
code
because
you're
changing
the
yaml
file
and
it
goes
through
the
Mr
review.
But
then,
like
the
Mr
review,
is
designed
for
code
review.
It's
not
designed
for
settings.
E
They
might
not
know
all
the
code,
conflicts
and
all
the
aspects,
all
the
feature
we
bring
on
the
Mr
Page,
but
we
are
bringing
them
there
because,
like
there
is
a
potential
need
they
want
to
review
the
change
or
like
there
is
just
easiness
for
us
to
push
MVC
but
then,
like
we
increase
the
complexity
in
this
way,
and
we
have
this
like
subconscious
thing,
because
we
have
the
git
like
technology
there
for
us
easy
to
use
it's
easy
for
us,
then,
but
it's
more
complex
become
for
certain
users.
A
A
great
example
I
love
that
yeah
it's
and
that
goes
back
to
you
know.
If
we
really
understand
the
essential
parts
of
the
problem,
what
users
are
trying
to
achieve
and
what
is
essential
to
them.
A
We
can
better
show
the
different
options
right
in
this
case
hey.
This
is
the
Mr
route
and
it
has
these
benefits,
but
it
also
adds
these
cons.
You
have
this
impact
on
complexity
because
you
know
you're
shifting
to
somewhere
else,
and
you
lose
context
and
then
there's
this
other
option
that
maybe
is
not
the
most
powerful,
but
it
actually
gets
things
done
in
a
simple
way:
yeah
I,
I
think
your
your
thought
process
is
is
on
points
is
now
just
trying
to
see
how
you
can
visualize
that
and
help.
A
You
know
product
management
make
the
best
best
decision
because,
as
you
said,
it's
not
just
about
you
know
the
final.
You
know
outcome
of
the
user.
It's
also
how
quickly
we
can
get
something
out
in
you
know
using
a
boring
solution,
but
sometimes
the
boring
solution
ends
up
before
complex.
So
it's
that
that
trade-off.
F
People
just
want
to
see
if
a
scanner
is
turned
on
for
a
certain
project
or
for
a
group,
but
it's
just
not
that
easy
because
of
how
it
works
with
Git
and
yaml
files.
It's
it's
it's
just
too
complex,
so
we
want
to
deliver
something
really
simple
and
straightforward,
but
it's
just
not
how
it
works.
F
So
what
seems
like
a
really
straightforward
request
and
straightforward
UI
actually
can't
be
done,
and
if
anybody's
curious
about
what
I'm
talking
about
here,
there's
there's
two
issues
that
are
three
plus
years
old,
so
yeah,
sometimes
the
way
the
technology
works
on
the
back
end
can
prevent
us
from
doing
more
simple
things
on
the
front
end
too,.
B
Sharing
there's
a
truth
that
I've
come
to
realize
through
my
years
of
working
in
this
industry,
and
that's
it's
a
tough
one,
but
it's
a
I
think
it's
similar
to
what
everyone's
talking
about
is.
If
you
want
to
make
a
UI
that
is
super
usable
super
simple,
really
solves
the
problems
generally.
That
means
it's
going
to
be
really
hard
to
build
and
that's
hard
to
explain
and
to
communicate
and
get
your
counterparts
to
accept,
especially
when
we're
talking
about
our
speed
and
a
number
of
users.
B
And
how
do
we
collaborate
with
our
counterparts
to
explain
these
things
to
provide
the
data
that
we're
using
the
the
thought
processes
that
we're
using
and
help
them
come
along
and
understand
those
things
you
know
we
there's
there
can
be
a
adversarial
feeling,
sometimes
right,
because
we
all
have
these
different
perspectives,
so
we
as
the
ux
people,
have
to
figure
out
how
to
best
communicate
these
things
you
know,
so
we
can
get
everyone
to
understand.
B
Our
point
of
view,
while
also
trying
to
understand
theirs,
you
know
we
have
to
put
on
our
ux
hats,
even
when
we're
talking
with
our
counterparts.
You
know
that
part,
never
changes.
We
have
to
use
empathy,
but
I
think
that
that's
the
hard
part
and
I
think
what
Camellia
may
have
been
getting
at
is:
what
can
we
get
some
more
tools
that
we
can
use
to
help
those
conversations
and
have
those
conversations,
and
some
of
those
tools
is
research
and
data,
but
also
reminders
to
us
while
we're
going
through
it?
B
So
it's
an
age-old
problem
since
ux
has
been
started
where
we
have
a
higher
maturity
than
most
companies,
but
it
doesn't
mean
that
we
can
rest
on
our
Laurels
and
not
expect
to
have
to
continuously
push
that
perspective
and
educate
everyone
with
the
knowledge
that
we
have,
while
also
accepting
the
knowledge
they
have.
So
it's
a
tough
one.
F
F
F
Create
a
road
map
is
their
own
customer
calls,
and
you
know
not
just
that.
I
mean
they're,
aware
of
like
what
competitors
are
doing
and
where
strategically
we
should
move
in
in
the
space
in
general
compared
to
other
tools
out
there,
but
there
there
can
be
maybe
a
difference
when
it
comes
to
prioritizing
like
which
features.
Do
we
ship
or
do
we
ship
them
at
all?
F
Because
if
I
do
solution,
validation
on
something
and
I'm
just
recruiting
any
security
engineer
or
developer,
who
uses
security
tools,
I
mean
it
opens
up
the
door
to
a
maybe
a
lot
more
use
cases
than
just
the
customers
who
are
paying
for
ultimate
or
are
open
to
paying
for
ultimate
and
giving
them
what
they
want
right.
B
Yeah
there's,
and
that
goes
back
to
the
balance
thing.
You
know
we
ultimately
we're
we're
a
business
right,
but
we
have
to
there's
a
cop
a
lot
of
things
in
there.
We
have
to
balance
business
needs
with
user
needs,
but
then
there's
also
a
side
that
says
if
you
can
truly
make
a
product
that
is
built
for
what
our
users
really
need
and
want,
and
it
solves
the
goals,
the
problems
that
they're
trying
to
solve
you'll
kind
of
get
that
that
purchasing
customer
you
know
paying
benefit
sort
of
inherently.
B
E
F
F
Every
time
I
I
go
through
solution,
validation,
it's
always
a
question,
and
this
was
mentioned
earlier.
Do
I
do
I
talk
to
people
that
don't
have
gitlab
familiarity,
people
that
are
brand
new
to
it
or
do
I
just
go
with
the
people
who
are
familiar
with
gitlab
and
how
it
works
and
maybe
understand
why
we
can't
show
that
SAS
is
enabled
or
not
enabled
reliably.
F
Yeah
I
mean
of
course,
I
I
want
it
to
be
easy
for
a
first-time
user
and
I
want
it
to
be
easy
for
somebody,
who's
been
doing
it
for
10
years,
but
there's
it's
I,
think
it's
easier
to
design
a
product
for
for
the
expert,
because
otherwise
we
end
up
in
this
just
Minefield
of
info
icons.
What's
this
what's
this?
F
What's
this
nothing,
to
like
explain
every
little
thing
I
know:
we've
struggled
with
that
a
little
bit
in
secure
and
govern,
and
then
just
having
like
the
page
description
link
to
the
docs,
maybe
just
the
docs
can
explain
it.
F
So
we
have
to
try
to
describe
everything
on
the
page,
but
but
yeah
I.
Think
when
you
know
my
I
think
when,
when
product
management
is,
is
on
a
lot
of
those
customer
calls,
they
may
also
not
be
prioritizing
the
first
time
user.
They
may
be
hearing
feedback
from
people
who
are
using
it
on
at
the
earlier
weekly
basis
and
so
I
don't
know
I.
This
is
a
theory,
but
maybe
there
was
expert
users
are
the
ones
that
you
know
have
their
voices
heard
the
most
rather
than
newbies.
B
But
I
I
still
think
that
it
comes
down
to
collaboration
and
discussion.
You
know
we
all
have
different
points
of
view
and
different
types
of
knowledge
and
goals
for
our
own
roles.
You
know
from
our
from
from
the
ux
leadership
side
we're
saying
as
uxers.
We
need
to
help
explain
these
the
user
side
of
things,
whereas
PMS,
you
know
gold
might
be
well.
We
have
to
make
money,
we
have
to
build
users,
we
have
to
build
them
out.
You
know
and
to
prove
that
this
particular
feature
is
worthwhile.
B
So
someone
from
ux
doesn't
come
in
and
say
no
one's
using
this
feature.
Let's
remove
it.
You
know
they
they're
different
goals
that
everyone
has
and
I.
Think
that's
why
it's
important
that
we
all
have
that
conversation
together
out
in
the
open,
yeah
and
explain
these
things,
but
we
have
to
have
the
data,
the
jobs
to
be
done,
the
research
in
order
to
show
and
prove
that
what
we're
saying
has
is
valid
you
know,
and
then
you
have
to
come
to
the
right
conclusion.
Together
balance.
What
is
the
effort
impact?
E
Yeah
just
a
quick
thing,
maybe
it
just
sometimes
if
we
are
meeting
like
customer
for
a
long
time.
Their
expert
is
always
helpful
to
shift
the
man
to
say
that
can
make
a
new
customer
with
the
feature
like
what,
if
you
want
to
get
more
new
customers,
that's
also
like
kind
of
a
business
need
we
just
don't.
Maybe
don't
think
about
that
that
often-
and
maybe
that's
the
task
of
the
sales
people
not
ask
like,
maybe
they
can
like,
provide
some
data.
That's
also
some
data
point
we
can
use.
A
A
It
is
very
easy
for
us
to
fall
into
designing
for
the
power
user.
As
like
the
example
that
Camellia
was
giving
before
of
hey.
Do
we
go
the
Mr
route
or
just
like
a
very
simple
diff
thing
that
you,
you
know
just
for
the
settings
and
maybe
the
power
users
would
love
the
Mr
route
because
they're
already
using
Mrs,
they
can
make
the
best
advantage
of
that,
and
so
we
have
to
understand
for
this
Persona
how
what
is
the
like?
The
knowledge
threshold?
A
What
what
are
the
minimum
things
you
need
to
to
know
to
get
this
going
and
that
knowledge
will
probably
change
over
time,
I'm
thinking
about
AI,
where
we
have.
We
need
to
have
disclaimers
everywhere,
because
it's
it's
a
fairly
new
thing
for
most
people
and
especially
applied
in
in
the
devops
space.
So
we
need
to
have
disclaimers
everywhere.
Like
you
know,
you
designed
that
thing
for
the
security
you
know.
A
As
oh,
you
know,
but
those
are
new
users
like
it's
it's
normal,
that
they
don't
get
it
like.
Is
it
really
that
normal,
like?
What
is
the
I
mean?
We
have
to
pick
something
to
prioritize.
We
have
to
be
kind
of
user
to
prioritize
the
experience
for
well
I.
Don't
think
we
can
just
be
designing
modes
for
all
different
permutations
of
kinds
of
users,
so
it's
just
figuring
out.
What
does
the
typical?
A
You
know
security,
engineer,
engineer
knows:
what's
the
the
knowledge
that
they
have
about
this
topic
and
and
design
for
that,
while
trying
to
make
the
experience
as
simple
as
possible,
so
that
even
the
power
users
will
thank
you
for
being
able
to
do
the
same
things
or
the
most
common
tasks
in
a
much
simpler
way,
because
that's
that's
what
we
see
over
and
over
with
many
tools
is
that
they
begin
catering
to
more
and
more
and
more
and
more
power
users.
A
You
know
take
like
Photoshop
versus
figma
right.
You
could
do
UI
design
with
Photoshop
for
years
right,
but
you
couldn't
do
it
as
well
as
figma,
because
figma
really
focused
on
a
specific
set
of
visual
design
capabilities
that
photoshop
already
had
and
even
explored
others
and
power
users.
Thanks
for
that,
because
it's
much
simpler
to
design
uis
in
figma
that
it
was
in
Photoshop.
A
So
so
yeah,
it's
those
two
things
knowing
what
is
the
typical
knowledge
and
trying
to
design
the
simplest
experience?
But
for
that
you
really
need
to
understand
the
problem.
B
And
on
that
awesome
note,
thank
you
all
for
a
great
conversation
look
forward
to
the
other
recordings
once
they're,
posted
and
I
will
also
post
them
in
our
slack
channels
and
with
that
have
a
good
rest
your
day,
all
thank
you.