►
From YouTube: Design for Users by Users: Intro to Design Thinking Sara Chizari Red Hat OpenShift Commons Briefing
Description
Design for Users by Users
Design Thinking at Red Hat
OpenShift Commons Briefing
Red Hat UX Research Team
Sept 12 2019
A
Well,
hello,
everybody
and
welcome
to
yet
another
OpenShift
Commons
briefing.
This
one
is
a
slightly
different
twist
we're
going
to
talk
about
UX
design
and
designing
with
users
for
users
and
a
little
bit
of
background
on
from
some
of
the
folks
at
Red
Hat
that
are
working
on
that
to
share
with
the
community
and
to
ask
for
for
your
feedback
as
well,
so
I'm
going
to
let
Sarah,
Chisari
and
Karl
Pearson
introduce
themselves
and
their
topic.
You
can
ask
questions
in
the
chat,
but
we'll
have
live
Q&A
at
the
end
to
so.
A
B
C
Yeah,
as
Sara
said,
my
name
is
Karl.
I
am
another
UX
researcher
on
the
team
and
I
work
quite
a
bit
on
openshift,
specifically
in
the
admin
console
and
doing
a
lot
of
research
and
interviews
with
actual
end
users,
so
talking
with
people
about
what
is
working
well
for
them.
What
isn't
and
what
they
want
to
see
in
the
product.
B
Cool,
so
yes,
as
Carl
said
what
we
do
is
basically,
we
just
mainly
are
focused
on
users.
We
work
with
users
to
understand
what
they
want,
what
our
expectation,
what
are
their
needs,
and
hopefully
translate.
There
is
information
we
gather
from
them
into
some
product
features
so
making
sure
that
the
product
that
we
design
is
actually
working
for
them.
So
we
do
a
lot
of
conversations
and
a
lot
communique
with
users
and
customers,
and
that's
what
we're
gonna
talk
about
today.
B
We're
gonna
talk
about
the
journey
that
we
take
to
bring
on
users
in
in
our
process
of
design
and
development.
So
here's
the
outline
we
can
tell
you
a
bit
about
ourselves
and
the
team
who
we
are
we're.
Gonna
talk
about
design
thinking,
which
is
the
framework
that
we
use
overall,
it's
just
it's
a
framework
that
we
follow
just
to
bring
alex
is
a
framework
to
bring
con
users
to
the
process
of
design
and
development.
B
They'll
tell
you
what
that
is,
we'll
talk
about
the
building
blocks
of
design
thinking
and
what
we're
going
to
do
is
that
we're
gonna
share
some
of
the
research
examples
that
we
have
recently
done,
and
the
studies
that
we
have
worked
with
the
users
to
get
their
feedback
from
different
perspective
and
through
different
activities
and
studies.
So
and
at
the
end
we
will
have
a
brief
discussion
about
how
you
guys
can
get
involved
in
this
process
and,
let's
get
started.
The
who
we
are.
The
team
we
have
is
is
a
group
of
different
roles.
B
B
What
we
do
is
we
there's
a
lot
of
interaction
between
us
and
we
also
have
new
access
developers.
That's
the
other
role.
I
didn't
include
here,
but
what
we
do
is
just
to
work
together.
We
use
research
as
the
backbone
of
everything
about
everything
that
we
do.
We
try
to
start
with
users.
We
try
to
understand
things
from
their
perspective
and
translate
those
ideas
to
to
the
designers
and
development
team
and
hopefully
design
something
that
works
for
everyone
for
our
end
users.
B
So
why
did
I'm
thinking
I
mean
this
decision
is
gonna,
be
Design
Thinking,
but
maybe
thought
we
were
going
to
talk
about
why
we
need
to
include
design
thinking
in
that
process,
so
design
thinking
is
basically
as
a
framework
for
including
users
in
the
process
of
design
and
development
and
I'll
give
you
the
standard
definition
of
it
in
the
next
slide,
but
why
we
need
to
do
this.
The
I
think
the
simple
answer
to
that
is
that
designers
that
we
have
like
every
designers
are
not
don't.
B
Love
do
love
farms,
we
have.
We
know
how
to
design
like
designers.
There
are
trained
to
design,
but
at
the
end
of
the
day
they
are
not
users,
because
users
are
coming
from
a
variety
of
backgrounds
of
languages
of
countries,
experiences
with
different
products,
so
there
are,
each
user
is
different
than
the
other
person
or
the
other
user.
So
because
of
this
diversity
between
the
user
is
we
will
definitely
need
to
work
with
users
to
make
sure
what
we
design
is
working
for
them,
though
designers
are
not
users
and
that
that's
actually
obvious.
B
So
that's
why
we
need
to
include
them.
The
other
reason
is
that
again
we
know
that
one
size
won't
fit
everyone,
so
we
definitely
need
to
include
everyone
in
the
process
of
design,
every
user
in
the
process
of
design
to
make
sure
what
you're
designing
is
working
for
them,
otherwise
designing
one
one
standard
application
and
hoping
that
that
will
work
for
everyone.
That's
not
gonna
work,
and
we
know
that's
not
gonna.
B
Everything
is
done
from
your
perspective.
So
here
is
the
actual
definition
of
design
thinking.
If
you
look
at
the
internet
like
if
you
look
up
design
thinking
on
the
web,
you
will
find
thousands
of
definition
of
this
framework.
There
are
so
many
different
ways
of
defining
this
framework.
There
are
multiple
framework
like
design.
Thinking
itself
is
a
term
it's
an
umbrella
term,
but
they
are
different
way
of
describing
that
one
of
the
famous
one
is
coming
from.
Ideo
is
the
company
that
does
design
thinking
as
their
core
processes
design.
B
Thinking
too,
it
seems
like
to
be
working
with
users
to
understand
their
problems.
It's
basically
the
problem-solving
method,
but
that
we
could
include
the
users
need
and
requirements
in
the
process
and,
at
the
end
of
the
day,
we're
looking
to
create
innovative
and
very
neat
ideas
that
actually
works
for
the
users.
So.
B
That
includes
all
the
needs
from
the
users
like
in
demand
and
the
requirements
they
have
and
translating
those
ideas
and
those
needs
into
some
something
innovative
and
creative
and
ideal
is
one
of
them,
but
we
have
other
design.
Thinking
like
frameworks
coming
from
Stanford
designer
school
is
one
of
them.
The
other
thing
Design
Thinking
framework
is
coming
from
IBM
as
well.
They
come,
they
call
it
loop.
B
What
are
the
prices
of
not
focusing
on
users
and
again,
these
are
the
reasons
that
we
don't.
We
do
want
to
have
users
included
in
the
process
of
our
design.
We
don't
want
to
design
features
that
don't
work
for
users
and
it
won't
solve
the
problems
for
the
users.
We
don't
want
to
design
things
that
are
not
user
friendly.
We
don't
come
on
a
series,
so
we
don't
want
any
of
this
happen
and
that's
the
reason
we
want
to
include
the
users
in
the
processes.
B
B
So
this
is
a
playground
and
we
have
slides
for
kids
to
play
with.
But,
as
you
see,
none
of
those
kids
are
using
their
slides
and
they
have
found
a
very
fun
other
way
to
to
play.
So
again,
this
is
a
very
extreme
but
again
very
interesting
way
of
showing
what
happens
when
you
don't
include
users
in
your
process
of
design.
Really
because
again,
you
might
have
some
ideas
that
we
think
it's
gonna
work
for
the
users,
but
until
we
work
with
the
users
and
talk
to
them,
we
won't
be.
B
Poor,
the
other
very
classic
examples
of
design
thinking
and
not
not
including
design
like
users,
a
process
of
design
is
this:
Norman
door
was
probably
most
of
you
have
heard
of
it,
the
one
the
picture
you
see
on
the
left.
This
is
called
Norman
door,
because
Don
Norman
is
the
person
who
actually
introduced
this
concept
today
to
the
world
of
user
experience,
as
you
say,
as
you
see
says,
push
on
the
door,
but
because
he
has
handles
people
expectation
is
that
they
can
pull.
B
So
that's
a
classic
example
of
not
thinking
about
users,
mental
models
and
not
thinking
about
the
users,
cognitive
behavior,
when
they,
when
it
comes
to
designing
stuff
for
them,
and
the
right
example
that
you
see
on
this
slide
is
is
a
video
for
cats.
The
top
example
is,
it
seems
to
be
just
working
it
just
like
is
a
feeder
that,
if
they
can
have
plates
for.
B
Reality,
that's
that's
what
happened
in
the
picture
in
in
under
that
you
see
they're,
not
actually
gonna
eat
what
they,
what
they
see
like
in
order
and
like
next
to
each
other,
and
one
by
one.
So
again
is
a
very
cute
example
of
not
including
the
users
in
the
design
I'm
going
to
talk
about
a
few
steps
that
we
take
in
design
thinking
and
in
our
processes.
Mainly,
the
steps
am
again.
These
are
design
thinking
steps.
The
first
step
is
to
to
to
do
empathy
to
have
empathy
with
users,
and
this
is
step.
B
We
are
trying
to
understand
our
users,
who
are
these
people,
who
are
the
target
users
of
our
product?
What
are
they
needs?
What
are
their
requirements
and
what
are
the
problems
really?
So
it's
really
sort
of
like
foundational
studies
or
research
or
activities
that
we
do
to
understand.
What
are
the
needs
of
our
target
users
and
we
call
it
empathy,
because,
basically,
we
are
trying
to
understand
them
and
the
Sun
everything.
B
We
include
users
in
this
process.
We
work
with
them.
We
go
through
different
variations
or
iterations
to
make
sure
those
designs
are
working
for
them.
So
experimentation
is
the
next
step.
Basically,
so
we
take
those
ideas,
we
work
with
users,
we
create
prototypes
mock-ups
and
things
like
that.
Again,
we
go
back.
B
The
what
they
think
and
again
the
end
product
of
this
process
is
basically
some
ideas
and
those
ideas
again
need
to
be
tested
and
iterated
on.
So
this
is
basically
basically
the
loop.
It's
not
is
never-ending
sort
of
process
where
we
start
with
with
users
and
standard
problems
and
need
id8
on
that
test.
Those
ideas
and
again
we
go
back
to
the
users
just
to
make
sure
those
things
that
we
designed
is
working
for
them
and
it's
a
constantly
you're,
not
gonna,
ever
stop
this
process.
B
B
Sj
is
one
of
the
designers
and
one
of
the
researchers
on
the
team
who
who
created
this
activity
to
create
personas,
so
persona
is
where
we
with
try
to
define
who
they
are,
what
are
the
characteristics
what
they
like
and
what
they
don't
and
stuff
like
that.
So,
as
you
see
on
the
board,
there
are
your
categories
for
for
developers.
Basically,
so
who
are
these
developers?
What
are
the
level
what
they're
specialized
on
what
they
work
in?
B
What
are
the
industry
they're
coming
from
what
they
want
to
learn,
so
a
lot
of
character
like
a
lot
of
characters,
characteristics
of
the
update
developers,
so
this
is
one
way
of
understanding
who
our
users
are
like.
Who
are
these
people
exactly?
What
are
the
characteristic,
what
they
want
to
learn
where
they're
working
from
who
are
these
people
exactly
so
I
like
this,
like
this,
this
activity,
we
did
this
activity
at
the
summit
at
the
Red
Hat
summit
and
recently
added
their
comp
in
Boston,
so
yeah.
B
This
was
an
activity
we
did
at
the
summit
where
we
wanted
to
instand
what
our
users
experiences
with
our
products
like
what
they
think
about
it,
what
they
feel
about
it.
What
are
they
pain
points
and
what
are
the
things
that
they
wish
for
the
product
and
activity
that
you
see
on
the
left?
So
you
see,
there
are
four
sections
on
the
board
and
that's
what
we
did
at
the
summit.
It
was
basically
very
very
interactive
session.
We
did
a
lot
of
system
admins
about
the
experience
with
with
rails.
B
Specifically
in
this
context,
the
other
activity
we
did
at
the
summit,
and
we
will
be
actually
doing
it
in
other
avenues
as
well.
Is
the
empathy
cart
that
you
see
on
the
right
side
of
the
of
the
picture,
which
is
basically
it's
a
very
simple
activity,
which
is
what
we
we
are
using
to
understand?
What
is
the
biggest
pain
point
for
our
customers
or
our
users?
So
we
want
them
to
tell
us
what
product
they
use
and
if
they
want
to
change
one
thing
about
their
product.
B
What
would
and
what
we
are
trying
to
understand,
mainly
in
the
UX
research
Ward
is
the
is
the
answer
to
why.
So,
if
something
is
wrong,
we
want
to
know
why
that
is
wrong.
That
doesn't
mean
focus
of
most
of
the
activities
that
we
do.
This
is
another
activity
that
called
it
so
I'm
just
gonna.
Have
him
talk
about
his
his
research
yeah.
C
So
this
is
another
kind
of
really
high
level
piece
of
research
that
is
kind
of
a
step
back
from
the
product
itself,
but
is
really
important.
So
this
is
a
technique
called
mental
model
interviews
where,
essentially,
you
start
with
a
series
of
interviews
and
you
comb
through
all
of
the
interviews
to
find
the
the
tasks
that
people
are
doing
every
day
and
you
group
them
all
together,
and
this
is
a
pretty
long
process.
Sifting
through
all
this
interview
data,
and
then
you
know,
grouping
things
one
by
one
with
each
other
with
something
else.
C
So
you
get
this
really
big
picture
of
the
landscape
of
what
people
are
doing
in
their
day
to
day,
and
this
was
built
specifically
around
the
sre
role
or
a
site,
reliability
engineer-
and
we
did
this
because
this
is
somewhat
of
the
newer
role
and
is
starting
to
gain
a
lot
of
traction
and
and
could
be
one
of
the
main
roles
that
might
end
up
using
openshift.
So
we
wanted
to
be
sure
that
we
were
designing
for
the
right
problem.
C
Essentially,
we
realized
that
we
didn't
necessarily
have
the
best
picture
of
what
they
did
day
to
day
and
before
we
started
just
jumping
into
design.
We
wanted
to
be
sure
that
we
were
going
to
be
designing
the
right
thing
before
we
design
something
right,
because
maybe
it
wasn't
what
they
needed.
But
this
is
really
recent
research
and
it's
still
sort
of
being
read
out
and
being
used,
but
we
learned
a
lot
about
the
context
of
their
use
and
come
some
of
the
bigger
overarching
strategy
is
involved
with
being
an
SRE
and
working
with
open
shifts.
B
Yeah,
the
activity
that
Cole
explained
is
is
a
type
of
activity.
We
call
it
generative
research,
which
is
basically
what
we're
trying
to
to
like
to
generate
many
more
ideas
from
it.
So
is
a
foundation,
a
very
foundational
research.
You
learn
so
much
from
the
user.
Is
that
you
can't
I
mean
there's
not
gonna,
be
only
one
Avenue.
You
can
use
that
there's
gonna
be
multiple.
Several
different
avenues:
you're
gonna
use
this
research,
which
is
quite
amazing,
it's
very
time
consuming,
as
as
Carl
said,
but
for
sure
it's
gonna
work.
B
Much
about
the
real
experience
of
the
users
about
the
product,
so,
as
I
said,
the
next
step
in
our
processes
is
ideation
or
I
da
ting
on
several
ideas.
So
a
lot
of
things
that
we
learned
in
the
empathy
sessions
will
lead
into
this
entities
from
into
this
step.
So
basically,
this
is
this.
One
is
a
very
interesting
example
that
one
of
our
designers
actually
did
called
it's
called.
The
activity
is
called
the
speedboat
activities,
which
is
basically
is
activity
to
understand.
What
are
the
challenges
and
problems
of
our
users
along
the
way
so
speak.
B
Basically,
you
want
to
get
started
with
login
gain
and
then
do
something
along
the
way,
and
finish,
though,
is
a
journey
that
you
want
to
take
on
and
the
speed
30
it's
within
your
immediate
product,
but
most
probably
there
are
a
lot
of
obstacles
or
a
lot
of
problems
along
the
way
that
you're
facing
and
in
order
to
achieve
your
goal.
So
we're
using
this
metaphor
basically
for
people
to
to
think
of
the
challenges
they
may
they
may
face
during
the
the
process
of
finishing
something
using
a
product
or
an
application.
B
B
Thinking
we're
very
basically
are
testing
our
ideas
and
and
prototypes.
So
after
the
first
two
steps,
we
most
probably
came
up
with
some
sort
of
design
or
a
mock-up
that
we
want
to
understand
so
now
that
we
have
this
sort
of
a
solution.
Is
that
working
from
a
user
perspective?
So
right
is
one
of
the
method
that
really,
but
that
we
try
is
called
rapid
iterative,
testing
and
evaluation,
which
is
basically
is
really
iterative
and
very
rapid.
B
B
You
test
that
next
design
with
another
participant
for
another
users
and
then
use
those
feedback
to
use
it
for
the
next
iteration.
So
it's
very
iterative,
and
sometimes
it
takes
like
say
10
to
12
or
even
20
iterations,
to
come
up
with
something
that
you
are
currently.
We
can
be
kind
of
confident
that
it's
gonna
work
for
most
of
the
users,
so
this
activity
was
done
at
DEFCON,
not
this
year,
again
in
2018
by
Tiffany
and
Gina,
very,
very
iterative
and
hands-on
activity
very
interesting
and
very
engaging
as
well.
B
B
So
basically,
the
idea
was
just
to
get
feedback
on
a
mock-up
that
we
had
so
the
mock-up
I
don't
know
if
you
can
see
it,
but
in
the
back
of
this
picture,
there's
a
mock-up
that
we
had
for
open
shift
console
and
we
just
wanted
to
see
what
people
reaction
to
the
visual
design
of
the
application.
So-
and
this
is
what
we
did-
we
just
took
the
mock-up
like
printed
it
on
a
board.
B
B
But
the
highlights
of
them.
We
just
wanted
to
show
some
of
them
to
you
to
see
what
we
really
do
at
uxd
team
and
how
we
work
with
the
users
to
do
design,
thinking
or
gather
feedback
from
them.
What
I'm
going
to
talk
about
now
is
that
if
any
of
these
things
that
I
mentioned
today
is
it's
sounding
interesting
to
you
or
you're
excited
about
it.
There's
opportunity
for
you
guys
to
get
in
the
world.
We
have
Design
Thinking
workshop
happening
at
the
at
the
open
ship
comments
happening
on
October
28th
in
San
Francisco.
B
So,
if
you
guys
are
looking
for
an
engaging,
exciting
and
hands-on
activity
during
the
open
chef
comments,
please
make
sure
you
sign
up
for
this.
For
this
workshop,
the
the
major
theme
of
the
activity
or
the
workshop
is
going
to
be
around
troubleshooting
in
OpenShift
and
gonna,
go
through
multiple
hands-on
activities
for
inspiration,
ideation
and
iteration,
and
you
guys
are
done
experience
of
what
what
it
means
to
do
it
Design
Thinking
and
most
probably,
you
will
learn
a
lot
about
some
of
those
activities
that
you
can
apply
to
your
own,
your
own
workspace
and
workflow.
B
That
you
have
so,
if
you
guys,
are
interested,
make
sure
you
sign
up
for
this
for
this
workshop.
We
have
a
link
here
too,
for
you
guys
to
sign
up.
I
can
share
the
link
in
the
chat
as
well.
If
you
guys
want
I
think
that
would
be
even
easier,
but
I'm
gonna
pause
at
this
part
at
this
part
just
to
make
sure
we
are
fine
and
if
you
guys
have
any
questions
about
anything
that
I
talked
about.
B
A
Well,
we
we
had
one
question
and
there's
been
a
little
bit
of
chat
going
on
in
the
in
the
and
the
chat
section
and
Peter
was
asking
in
terms
of
I'm
thinking,
he's
talking
about
open
shift
if,
whether
or
not
we've
implanted
any
kind
of
metrics
within
the
apps
to
measure
user
responses
to
a
specific
design.
So
I
know
people
do
a/b
testing
and
all
kinds
of
fun
stuff
like
that.
But
is
there
anything
the
UX
folks
are
getting
back
and
Carl
had
started
to
answer
that.
B
C
So
I've
actually
just
been
learning
about
this
I'm
at
a
face-to-face
meet
up
with
the
openshift
design
team
right
now,
so
they're
talking
a
lot
about
this
kind
of
stuff.
There
are
some
stuff
we
have
implemented
that
looks
more
in
configurations
and
builds
and
upgrades
to
help
with
our
insights
product
and
that
is
less
related
to
actual
user
behavioral
data
such
as
you
know
what
page
do
they
access
the
most?
Does
this
button
ever
get
clicked
things
like
that?
C
There
has
been
discussion
about
enabling
some
features
like
that,
but
it
also
includes
conversations
about
buying,
and
you
know
how
would
customers
feel
about
giving
giving
this
data
back
to
us?
So
there
isn't
any
plan
right
now
to
implement
that
data
as
a
UX
researcher.
I
would
love
to
have
it,
but
it's
obviously
a
pretty
complicated
conversation
we're
talking
about
getting
data
back
from
users
clusters,
even
if
it's
anonymized
and
not
necessarily
looking
at
any
private
information,
so
we
haven't
implemented
any
classic
sort
of
analytics
within
OpenShift.
At
this
point,
yeah.
A
That's
kind
of
what
I
thought
so
in
the
workshop
that
you're
planning
on
doing
on
the
28th
is
there
going
to
be?
Is
it
going
to
be
more
Legos
and
and
boards
and
whiteboards,
and
things
like
that?
Are
you
actually
going
to
do
some
hands-on
watching
how
people
use
the
console
and
do
troubleshooting
in
the
console?
It's.
B
Gonna
be
like
it
is
like
a
lot
of
example
like
the
Rings,
the
things
that
I
talked
about
in
the
previous
slides
back.
It's
gonna
be
very
similar
to
these.
It's
gonna
be
really
hands-on.
We're
not
gonna
show
you
any
like
we're,
not
gonna
yeah
I'm,
not
gonna.
Have
you
guys,
sit
in
front
of
a
screen
and
have
you
test
something
we
want
you
to
like
the
participant
to
be
to
be.
B
There's
gonna
be
a
lot
of
hands-on
right
wording,
drawing
like
maybe
like
we
haven't
thought
about
Legos,
but
there
were
some
other
fun
activities
that
they
have
in
mind,
but
yeah
a
lot
of
hands-on
and
let's
let
the
screen
less.
It's
not
gonna,
be
a
usability
testing
per
se.
There's
gonna
be
more
of
a
discussion
like
problem
discovery
and
problem
solving
through
a
lot
of
hands-on
activities
and.
C
If
I
can
jump
in
quick
too
to
say,
we
also
have
a
lot
of
opportunities
open
in
that
and,
of
course,
anyone
that
join
this
workshop.
We
would
be
happy
to
talk
with
them
more
and
we
have
a
lot
of
more
one-on-one
kind
of
you
know,
sit
down
and
actually
do
stuff
in
the
interface
type
of
research
that
we
do.
It
tends
to
be
again
more
one-on-one,
because
it's
hard
to
keep
track
of
you
know
what
everyone's
doing
when
they're,
just
a
few
people
running
the
workshop
and
maybe
a
lot
more
people
attending
the
workshop.
A
A
Question
and
it
sort
of
it's
sort
of
a
higher
level.
One
is
how
do
you
know
when
a
design
works,
so
you
know
you
get
good
feedback.
You
get
people
to
you
know,
do
you
know
their
their
feedback
book
and
you're
iterating
through
that?
So
how
do
you
know
and
how
do
you
make
that
judgement
when
some
one
of
features,
working
or
or
functionality
in
your
design
is
working
there.
C
C
But
you
lose
a
lot
of
context
when
you
look
at
data
like
that,
you
don't
know
if
they
don't
see
the
button,
because
their
color
is
not
very
salient
and
it
just
doesn't
pop
out
on
the
page
or
maybe
they
don't
know
that
that's
the
way
that
they
need
to
go
they're
not
concerned
about
adding
that
type
of
kubernetes
resource.
So
we
do
a
lot
of
qualitative
testing
on
a
smaller
scale,
where
we're
looking
at
a
specific,
perhaps
like
wizard
flow.
C
If
it
is
involved,
something
like
that
or
how
they
would
maybe
add
a
project,
and
you
can
evaluate
pretty
quickly
if
there
are
any
major
problems
in
your
design
by
testing
just
a
handful
of
users.
So
we
do
a
lot
of
this
sort
of
tactical
level.
Research
where
we're
watching
people
actually
go
through
the
interface
and
getting
qualitative
input
from
them
on.
You
know
why
something
might
not
have
worked
if
we
observe
that
they
didn't
didn't
complete,
something
that
is
kind
of
a
major
task
in
the
interface
and
at
times
we've
also
done
larger
scale.
B
Yeah,
as
Carl
said,
our
I
think
our
major
metric
to
understand
whether
or
not
a
feature
is
working
is
is
to
observe
the
behavior
like
in
context,
so
yeah
analytics
it'll
tell
a
lot
about
what's
happening.
What
people
are
doing
in
our
in
our
in
our
application?
God
it
won't
tell
us
why.
So
that's
that's
the
idea,
so
we
want
to
know
if
something
is
not
happening.
If
it's
not
something
working,
we
want
to
understand.
Why,
like?
What
was
the
reason
for
that?
So
that's
that's.
B
And
what
will
you
usually
do
is
that
if
we
have
these
sessions
running
like
say,
we
have
some
usability
testing
running,
we'll,
definitely
invite
the
product
team,
the
design
team
to
to
watch
and
observe
decisions.
So,
even
because,
even
if
we
report
like
say
10
pages
of
a
lot
of
data
to
them
and
unless
they
see
it
in
person,
is
not
going
to
be
as
impactful,
so
what
what
we
do
whenever
is
any
sessions
like
usability
testing
is
going
on.
B
Everyone
we've
broadcast
those
sessions,
so
everyone
can
see
like
it
mean
the
design
teams
like
can
CD
the
experience
from
from
their
own
side
and
just
feel
the
build
experience
for
themselves.
So
yeah,
I,
think
observation
and
watching
the
behavior
of
the
users
is
what
will
tell
us
if,
if
this
design
is
working
or
not
great,
I
hope
that
answered
that
question
I
think.
A
It
did
I
think
I
was
a
very
good
good
way.
Those
of
us
who
are
developers-
and
you
know
we
tend
to
you-
know-
make
fixes
and
then
deploy
it
see
if
it
works
and
get
feedback
there,
but
I
think
the
we've
always
said
we're.
The
observation
is
that's
really
how
you
get
people
to
understand
how
people
are
actually
using
the
software.
So
I
think
that's
a
great
point.
A
Get
you
to
send
me
your
slide
deck
too
and
we'll
add
that
in
and
we'll
post
that
on
the
mailing
list,
as
well
as
link
it
into
the
landing
page
for
the
open
ship,
Commons
gathering,
that's
happening
in
San
Francisco
on
the
28th
and
we
hope
you'll
join
us.
And
then
we
hope
that
Sarah
and
Carl
that
you'll
come
back
and
talk
to
us
a
little
bit
more
about
what
you
found
out,
because
I
think
that
would
be
interesting
too.
B
A
And
we're
doing
in
the
morning.
So
if
you
want
to
come
and
join
us
for
the
rest
of
the
afternoon
at
the
open
ship,
Commons
gathering
itself,
you're
welcome
and
invited
to
do
so.
So
because
we're
we're
looking,
you
know
we're
looking
really
for
some
folks
who
are
will
volunteers
some
of
their
time
or
bring
the
people
who
are
from
their
companies
that
are
interested
in
this
topic
and
users
to
help
us
keep
innovating.
On
the
UX
floor
for
OpenShift
and
related
in
integrated
pieces.