►
From YouTube: CI/CD UX Meeting 2019-11-15
Description
By-weekly CI/CD UX Team Meeting to go over important updates, discussion items, feedback, etc.
A
A
Holly
would
be
really
nice
to
hear
yeah
like
how
certain
things
that
I
place
an
agenda
are
being
done
in
your
section
as
well
yeah,
so
I
would
suggest
you
go
through
the
agenda
that
I
put
out
for
today's
session
and
I
discussed
few
questions
over
there
and
if
anyone
has
anything
to
add,
please
feel
free,
and
so
the
first
thing
I
wanted
to
kind
of
like
announce
and
discuss
and
collect
the
feedback
from
you.
Is
you
probably
seen
the
changes
to
the
UX
design
review
sessions?
A
So
you
can
see
when
each
of
the
stage
groups
are
participating
and
when,
when
are
you
scheduled
to
present
so
the
attendance
for
the
UX
showcases
meetings
going
to
be
managers,
stakeholders
and
just
everyone
who
wants
to
be
there
as
far
as
I
understood,
we
won't
be
giving
feedback
to
to
each
other.
It's
just
like
a
product
design,
your
showcases
for
for
awareness,
like
the
research
projects,
the
product
design
work
just
to
showcase
what
was
done
to
the
company
on
the
design
level
and,
however,
there
is
another
sessions
that
are
being
set
up.
A
That's
gonna
be
the
design
reviews
and
that
in
that
invite
for
CICU
everyone,
you
guys
have.
You
have
already
received
it's
going
to
be
starting
from
the
next
week
on
Thursdays,
and
this
is
the
sessions
are
for
us
to
present
our
work
UX.
What
research
work
discuss,
processes,
how
we
use
them
in
the
in
the
stage
groups
and
get
give
and
receive
the
critiques
between
dust
between
our
stage
tool.
So
it's
like
it's
me
and
you
guys
and
in
the
future.
Maybe
everyone
else
who
wants
to
join.
It's
basically
we're
going
to
be
using
this.
A
As
a
general
check-in
kind
of
like
to
give
each
other
help
and
advice
and
feedback
on
any
question
from,
as
we
discussed
with
meeting
hey
I
use
this
icon,
do
you
have
any
other
ideas
up
to
what
kind
of
a
process
do
you
use
to
solve
that
problem?
I'm
curious?
What
do
you
think
about
these
two
changes.
B
Have
two
questions
about
it?
Actually,
the
first
one
is:
what
level
of
presentation
do
you
think
will
be
expected
for
that?
I
was
speaking
with
Alexis
yesterday,
and
we
were
talking
about
how
the
design
reviews
previously
were
a
little
less
formal,
and
so
people
felt
that
they
could
just
bring
whatever
and
present
whatever,
and
it
seems
like
this
might
be
a
little
more
formal
considering
the
audience,
but
maybe
not
so
I'm
just
curious.
What
everyone's
thoughts
are
on
that
that's
the
first
question
and
the
second
is
I
had
heard
for
the
very
first
one.
B
A
Yeah,
so
about
the
showcases,
there
is
a
template
for
the
presentation
as
optional
suggestion
and
it
being
split
up
into
the
four
sections,
like
the
business
case,
the
the
goals,
the
customer
problems
and
then
the
actual
solution.
You
are
free
to
use
whatever
you
want,
but
that
one
was
just
created
to
help
you
get
up
to
speed.
That's
one
and
I
am
I,
am
not
sure
if
the
participation
participants
for
the
first
session
will
be
any
different
from
any
further
right.
A
Yeah
I
would
not
expect
that,
because
for
the
first
session
we'll
have
one
group
stage
group
and
for
the
another
one
we
will
start
the
schedule
you
know,
so
it's
going
to
be
changing,
so
I
would
expect
it
to
be
the
same.
Okay,
thank
you
in
your
body.
In
your
stage
group,
do
you
have
the
design
reviews
for
your
stage
group
already
set
up
as
well?
We.
B
Have
not
officially
set
those
up
so
currently
it's
just
Alexis
and
I
on
my
team.
Annabelle
is
also
on
the
team
but
she's
facing
out
now
moving
over
to
secure,
so
we've
both
been
in
kind
of
a
catch-up
stage
where
we've
just
been
trying
to
kind
of
get
on
top
of
some
things
and
we've
had
a
lot
of
changes
to
and
that
we
had
three
new
project
managers
and
now
Shane
is
leaving.
So
we've
been
in
a
little
bit
of
a
state
of
chaos,
not
crazy
chaos,
but
my
health
chaos.
C
Really
like
that,
I
think
it
makes
a
lot
of
sense.
I
think
that's
probably
a
great
way
to
get
more
like
in,
like
in-depth
feedback
like
about
our
work,
because
we
know
why
how
our
work
Lee
will
it's
what
other
people
are
doing?
Even
our
continuous,
like
the
you
know,
like
the
DevOps
process,
it's
probably
more
fruitful
when
you
get
feedback
from
people
who
are
like
affected
by
your
work,
you
know
so
I
think
that
makes
sense.
Yeah
I
think
it's
a
good
change.
D
A
Yeah
exactly
and
for
the
design
we
use
in
our
group
stage.
I,
like
you
know
it,
we
can
discuss
what
at
any
stage
where
somebody
is
starting
and
hey:
I
need
an
advice
or
for
somebody's
finishing
and
hey.
This
is
what
I
designed
give
me
a
feedback.
You
know
like
I
need
to
brainstorm
some
ideas,
it's
anything
and
for
that
we
don't
even
have
a
template.
It's
just
kind
of
a
genuine
friendly
environment
for
us
to
share
our
projects
and
get
a
help
and
feedback.
Basically,.
E
E
We
grow
as
a
group
and
get
more
familiar
with
each
other.
We
can
be
friendly
and
not
feel
you
know,
like
you'll,
open
to
present
that
without
the
stress
that
comes
along
with
that
and
then
the
other
thing
I
think
it's
great
about
doing
it
amongst
our
team
is
kind
of
saying
the
same
thing
that
the
wand
was
saying
that
a
lot
of
those
sessions.
Previously
you
had
to
provide
so
much
context
that,
by
the
time
you
were
done
presenting
the
context,
there
was
almost
no
time
to
talk
about
the
actual
design.
A
Awesome
all
right,
yeah
I'm
super
happy
to
share
that,
because
this
is
what
I
was
thinking
as
well
and
I
scheduled
those
sessions
to
be
on
Thursday
one
hour
every
week,
open
for
a
discussion-
maybe
too
often,
maybe
too
much
but
I-
think
that
should
be
about
right
and
also
I.
Think
I
wrote
there.
Someone
here
suggestion
approximately
we
can
have
like
two
designers
presenting
it's
also,
not
a
rule.
A
We
will
see
how
much
we
can
do
work
in
that
hour,
or
maybe
we
want
to
make
that
shorter
in
the
future
and
in
the
beginning,
I
know
it
probably
would
be
a
bit
like,
like
you
know,
I'm,
not
sure,
if
I'm
on
a
presen.
So
if,
if
nobody
will
be
assigning
themselves
up
to
24
hours,
I'll
be
kind
of
like
asking
hey,
you
know,
I
think
that
case
is
interesting.
A
You
know
we
can
discuss
that
because
everyone
can
learn
from
you
or
you
know
you
could
ask
for
feedback
so
if
I
won't
be
seeing
like
I
will
actually
make
them.
I
already
made
the
document
with
the
agenda
where
people
can
subscribe
themselves
to
the
sessions.
It's
in
the
invite.
So
if
no
one
will
be
like
subscribing
in
that
day
before
I
would
be
just
saying:
hey,
you
are
the
well,
not
the
wheel
team
I'm
joking!
A
D
A
A
A
So
I
placed
here
couple
of
links.
You
can
see
the
schedule
for
the
New
York
showcases
I
will
be
reminding
you
guys,
one
like
your.
Your
stage
group
is
coming
up,
I'll
be
saying:
hey,
you
know
like
next
week.
You
should
be
presenting
in
the
big
scale.
So,
let's
think
of
something
and
for
the
design
reviews
is
really
something
that
we
should
be
taking.
Care
of
cells
often
is
really
informal,
and
just
for
us
to
to
mine
one
of
the
things
that
I
will
thought
like.
A
Maybe
you
can
place
your
thoughts
afterwards
mature
if
you
want
to
go
into
too
much
discussions
this
guy,
these
kind
of
questions
like
what
kind
of
feedback
do
we
want
to
get
in
these
sessions?
In
what
situation
should
you
be
asking
for
feedback?
You
know,
how
would
you
would
we
like
to
give
to
receive
it,
etc?
I
think
it's
not
very
necessary
questions
to
discuss
to
think.
As
we
start,
we
will
probably
look
fall
into
some
pattern.
D
A
You
actual
places
actually
replaced
the
design
review
meetings,
the
one
that
Ireland
was
always
asking
to
sign
up
for
and
you've
seen
that
that
meeting
was
removed
from
the
agenda
already
and
from
your
calendar,
it
lights.
Well
then,
in
place
you
have
like
two
meetings
to
you
actual
cases
and
then
design
reviews
for
the
group
suction.
A
All
right
awesome,
the
next
topic,
actually
that
came
more
from
Ian
and
I,
feel
a
little
bit
bad,
that
he
is
not
intercession,
and
so
that's
up
to
us.
We've
been
having
a
lot
of
the
discussions
around
the
jobs
to
be
done,
experiences
and
how
we
are
using
them
for
the
UX,
scorecards
and
I
wanna
just
bring
this
topic
and
see
if
there
is
any
discussion
to
be
done
around
that,
do
we
want
to
like
share?
Does
anyone
has
any
like
well
challenges
with
jobs
to
be
done?
A
C
I
actually
have
had
discussions.
I
had
a
discussion
with
with
Becca.
She
lives
here
in
Austin
in
like
working.
We
talked
about
these
and
we
I
think
the
conclusion
that
we
arrive
to
is
a
job
to
be
done
here
in
each
lab.
They
mean
something
that
not
it's
not
actually
what
it
means
in
the
outside
world
when
you're
talking
about
a
job
to
be
done,
so
you
know
I,
think
that's
and
that's
right.
That's
totally
fine!
You
know,
but
I'm,
but
I
think
it's.
C
He
will
be
good
for
us,
so
clarify
exactly
like
what
job
to
be
dance,
meaning
the
context
of
a
club,
mostly
because
I
think
here
they
feel
like
user
stories,
and
when
you
read
literature
about
job
to
be
Don's
like
that
you
find
online,
they
can
focus
a
lot
on
like
the
deep
motivations
of
the
user.
You
know
like
that.
Coke
beyond,
like
in
mediate,
need
and
I
think
that
that
might
be
confusing
for
new
comers.
C
It's
not
confusing
for
me
anymore,
I,
understand
but
like
it's
like
for,
like
people
who
are
just
getting
on
board
and
I,
think
that
board
I
think
that
could
be
confusing
and
for
anyone,
who's
ringing
the
hand
blue
clay,
and
he
he
sees
that
terminology
I
think
it
would
be
important
to
define
what
it
means
to
us.
You
know
I,
don't
know,
that's
that's
the
top
that
I
have
about
that.
D
Is
it
correct,
like
the
way
that
you
want
to
think
about
jobs
to
be
on
is
that
you
would
like
to
change
that,
or
is
it
that
you
know
the
current
concept
of
jobs
to
be
done?
Is
you
know
completing
the
need
we
have
for
them?
So
like
do
you
agree
with
the
current
process,
or
do
you
think
like
hey?
We
are
still
like
I
start
to
go
so
that
we
eventually
aligned
with
the
externally
facing
expectation
of
jobs
to
be
done.
No.
C
B
No
again,
we've
been
in
kind
of
a
strange
state
in
my
group,
so
it's
been
really
interesting
to
watch
how
you
all
are
handling
some
of
these
conversations,
because
we
really
haven't
talked
about
it.
Much
again,
we've
just
been
kind
of
keeping
our
heads
above
water
a
little
bit,
but
I
will
get
there.
It's
just
a
lot
of
transition
and
change
on
our
team
for
the
past
month
or
so
I.
A
What
what
Ian
actually
was
sharing?
He
was
saying
like
that
to
him
jobs
to
be
done
is
feeling
like
when
he
makes
this
job
to
be
done
for
a
UX
scorecard.
It
feels
like
it's
a
huge
one
thing
that
later
you
can
break
into
wardrobe
jobs
to
be
done,
and
this
was
his
confusion
as
far
as
I
understood
and
remember
it,
it's
like
that.
You
could
go
much
more
deeper
that
this
first
job
to
be
done.
We
create
the
UX
for
part.
C
Level
of
details
later
I
I
think
I
should
have
explained
something
when
I
was
giving
my
my
thoughts.
I
didn't
explain
like
what's
there
like
a
larger
concept
of
jobs
to
be
done,
and
why
I
think
it's
kind
of
different
from
what
we
do
here
internally,
so,
like
a
very
simple
example
like,
if
you
think
about,
if
you
actually
read
the
job
to
be
done
paper
or
like
the
harbor
business
review
paper
on
jobs,
to
be
done
like
what
he's
talking
about
there?
C
Is
there
like
a
job
to
be
done
for
someone
like,
for
instance,
like
testing
Reilly
someone
who's,
doing
testing
continuous,
integrated
testing?
They
don't
want
to
test
things.
You
know,
that's
not
the
job
to
be
done.
The
job
to
be
done
is
like
I,
don't
wanna
have
box
I,
don't
want
to
have
errors
like
testing
should
be
like
a
second
pod.
You
know,
like
my
actual
job
to
be
done,
is
to
like
produce
code
that
is
buckless.
C
You
know
my
job
to
be
done
is
not
to
write
tests
or
you
know,
create
testing
environments
or,
like
that's,
not
my
job
to
be
done
so
I
think
that's
where
I
find
I,
like
the
discretion
because,
like
if
I
think
about
it,
like
the
job
to
be
done,
like
it's
more
I
will
say
like
more
esoteric,
but
also
like
a
little
bit
more.
You
know
like
vague
and
try
to
like
be
more
is
fear
rational
if
you,
if
you
will
I,
think
what
we
do
here
is
like
we
actually
describe
like
embrace
specific
stories.
C
E
Yes,
but
I,
guess,
let
me
qualify
it
first,
because
it's
gonna
sound
negative,
but
I
don't
mean
to
be
so
I,
especially
love.
What
Vaughn
is
saying
about
getting
to
the
deeper
root
of
like
you
know,
stop
trying
to
do
what
someone's
trying
to
do
it
get
to
someone
you
know
it's
that
whole
like
I,
can
make
you
this
great
app
or
I
can
just
have
the
one
button
that
that
solves
the
problem.
Right
like
at
the
end
of
the
day,
you
want
the
one
button
that
solves
a
problem.
E
If
you
can't
so
I,
I
love
the
process
and
I.
Think
it's
a
super
valuable
thing
where
I've
struggled
with
it
a
little
bit
is
I
think
we
need
to
match
the
maturity
level
of
the
particular
feature
to
the
to
the
effort.
So
my
point
is:
is
the
negative
part
that
I
got
out
of
jobs
to
be
done?
Was
there
was
a
lot
of
overhead?
It
took
a
lot
of
time.
E
It
absorbed
a
lot
of
resources
and
I,
don't
necessarily
see
the
payoff
of
that,
whereas
some
other
efforts
that
are
along
the
same
lines,
particularly
like
feature
flags,
was
just
more
directly
like
here's,
where
this
experience
was
broken.
Let's
just
go
fix
that
and
get
that
on
track
and
get
that
that
done
without
the
the
Granger
of
the
of
the
process
was
able
to
produce
more
results
with
the
same
amount
of
effort,
it's
not
to
discount
the
the
jobs
to
be
done.
I
do
think
it's
a
valuable
thing
and
give
an
infinite
time
and
resources.
E
D
D
So,
for
example,
what
Quan
was
saying
is
it's
either
you
know
I
don't
want
to
have
bugs,
which
I
would
say
is
very
up
no
up
at
the
top,
where
I
need
to
write
tests,
which
is
a
step
lower,
but
if
the
design
maturity
level
of
the
feature
on
you
know,
writing
tests-
and
you
know,
test
support-
is
not
yet
at
that
lovable
state.
It
makes
more
sense
to
step
in
at
at
level
as
to
pay.
The
user
is
motivated
to
write
tests.
D
E
And
that's
where
I
think
that
Wan
has
hit
not
a
great
point
because,
like
when
a
feature
is
very
unsure
if
the
early
stages,
it
is
very
important
to
think
about
the
end
goal
right
like.
Where
is
this
thing
going
to
make
you
make
sure
you
start
off
on
the
right
path?
I,
don't
feel
like
that's
what
we
were
doing
to
Towanda.
What
we
were
doing
is
basically
re-evaluating
experiences
and
doing
it
more
at
the
actual
level.
You
know
like
I'm,
trying
to
accomplish
this
thing
in
gitlab
and
I
guess.
E
My
point
is
that,
if
that
is
what
we
are
doing
doing,
that
exercise
on
a
very
raw
rough
feature
produces
nothing
but
obvious
answers,
and
that's
what
I
felt
like
I
got
out
of
my
experience
was
all's.
I
did
was
wrote
down
obvious
things
that
I
knew
at
the
beginning
of
the
process,
yeah
and
that
that
makes
it
a
waste
of
time.
E
C
I
agree
with
Mike
it's
like
because
you,
because
we
do
it
that
way,
like
I
I,
almost
filled
it
like
what
you're
saying
is
that,
like
the
air
for
like
that
day,
food
is
too
large
and
the
outcome
is
too
little
right
like
it's
like.
You
have
to
do
like
all
these
kind
of,
like
analyses
of
what's
going
on,
like
the
features
be
rough
and
then
the
outcome
is
like
oh
yeah.
F
E
E
A
D
Say
that
it
is
kind
of
related
to
where
we
are
stepping
in
with
the
UX
scorecards,
you
know
we're
just
I,
just
I
would
say
we
just
passed
the
first
generation
of
score
cards
which
were
marginally
influenced
by
product
management
and
we
reward
their
as
a
you
know,
kind
of
evidence,
taste
for
future
jobs
to
be
done.
It's
like
hey.
We
can
provide
value
this
way
now,
let's
take
it
to
the
next
step,
which
maybe
the
second
generation.
D
If
you
like,
scorecards,
where
we
can,
you
know
bill
with
more
ambitious,
but
that
requires
more
input
from
product
management
into
those
jobs
to
be
done,
which
I
think
is
yet
to
be
done.
It
please,
when
I
talk,
for
example,
about
CI
I'm
positively,
looking
forward
to
the
next
effort.
In
that
sense,
even
though
it
will
not
be
pushed
forward
by
an
OPR
I
think,
but
you
know,
the
values
should
be
clear
now
to
product
management
that
you
know.
E
Yeah
and
I
think,
like
every
conversation,
seems
to
come
back
to
you,
know
more
discussions
with
product
managers
about
vision
and
strategy,
and
to
me
this
plays
perfectly
into
that
right.
This
is
a
if,
if
we
are
having
the
vision
and
strategy
conversations
and
then
we
are
aligning
the
jobs
to
be
done
in
our
UX
scorecards
with
those
products,
you
know
vision
categories
then
it
all
plays
together.
It
all
works
together.
E
It
reinforces
each
other
as
opposed
to
how
it
seemed
to
play
out
the
first
one
where
it
was
the
vision
and
the
features
that
were
at
least
in
my
area.
The
vision
and
the
strategy
items
that
were
at
the
forefront
were
not
what
the
jobs
to
be
done
was
executed
against.
So
I
think
that
tighter
coupling
of
let's
talk
about
vision
and
strategy
on
things
and
then
see
where
the
next
job
to
be
done
should
focus
on,
should
love
it.
Align
with
that
area.
D
C
C
You
know
so
and
that
kind
of
makes
sense
to
me
as
we
get
more
complex,
that
we
have
like
the
the
mini
score
car
you
know
or
like
the
you
know
like
alright,
could
be
called
something
else.
You
know,
but
it's
like
a
different
way
to
evaluate
and
like
go
on
like
approach
these
things
and
then
like.
Perhaps
we
we
just
make
it
in
such
a
way
that,
like
it's,
for
ready,
kinda
like
box
up
in
in
like
sighs.
C
A
Putting
like
too
much
effort
for
a
thing
that
could
be
like
well
easier
accomplished
and,
like
kind
of
like
also
comebacks,
it
comes
back
to
what
Mike
was
saying
that
it's,
it
seems
like.
We
are
kind
of
like
doing
doing
a
big
process
to
document
something
that
we
already
know
without
through
all
of
the.
E
No
but
Mike
I
think
it's.
You
know
it's
using
the
right
tool
for
the
right
job
right.
You
know,
there's
there's
a
I,
don't
know
what
a
regular
hammer
it's
called,
but
it's
a
regular
hammer
and
there's
a
sledgehammer
right,
there's
a
time
to
use
a
regular
hand
when
there's
time
use
a
sledgehammer
and
I
think
if
we
try
to
use
jobs
to
be
done
for
certain
situations
it
will
produce.
You
know,
it'll
make
the
process
harder
and
if
we
use
it
for
the
right
situations,
it
will
produce
the
job.
E
D
That
I'd
had
like
part
of
the
reason
for
this
case
using
the
sledgehammer
if
I
call
it
correctly,
the
big
one
I
would
say,
is
to
have
be
a
little
bit
more
data-driven
and
have
evidence
for
the
heuristic,
basically
University
evaluation
of
certain
experience
to
discuss
and
get
things
prioritized
from
aux
contacts
into
the
roadmap
of
product
management,
because
I've
had
conversations
in
the
past
with
product
management
like
hey.
These
things
are
important
and
product
management
basically
said
like
yeah
sure,
but
like
these
other
things
are
important
as
well.
E
E
So
that's
when
I
think
it
is
right
right
like
if
it's
the
kind
of
thing
that
needs
to
be
moved
forward
like
that
time
to
pull
out
the
big
hammer
and
use
it
yeah
I
think
I,
just
mistakenly
used
it
on
a
small
thing
that
didn't
need
it
right.
So
I
was
I
just
wore
myself
out.
So
when
you're
a
bigger
hammer
than
I.
A
E
Mean
to
me
the
only
one
will
be
made
at
that
point
of
matching
the
that
this
isn't
this
isn't
a
tool
that
can
solve
all
problems.
This
is
a
tool,
that's
should
be
used
in
these
cases
and
maybe
flesh
out
what
those
cases
are.
You
know
what
makes
so
both
from
a
product
side,
because
to
me
where
the
process
fell,
apart
was
in
selection
of
jobs
to
be
done
that
that's
where
it
fell
apart,
because
we
just
kind
of
chose
things
and
granted.
E
None
of
us
had
really
done
this
before
neither
as
product
designers,
at
least
here
at
get
loud
or
the
product
management.
So
the
selection
process
of
what
we
were
going
to
do,
the
jobs
to
be
done
on
was
largely
just
random.
You
know
it
kind
of
just
suggested
some
things
that
was
I
can't
work
on
that
there
wasn't
as
much
thought
put
into
it.
Maybe
if
we
tightened
up
the
criteria
for
choosing
a
jobs
to
be
done
area
focus,
we
could
improve
the
process.
A
Okay,
that's
a
good
point:
I
wrote
them
yeah.
Maybe
we
can
also
highlight
this
in
the
Yaak,
sweetie
or
even
I.
Don't
know
like
that
design
management
or
something
like
that.
Someone
has
any
thoughts.
Please
add
them
here.
I'll
definitely
come
back
to
this
topic
on
the
next
one
and
to
see
open
yeah.
How
could
we
go
further
with
that?
But
maybe
we
should
also
they
stopped
at.
They
stop
it
to
T
who
acts
quickly
or
something
like
that.
D
D
A
E
E
E
D
A
D
F
D
A
E
A
E
To
me,
the
only
argument
for
sketch
is
they
keep
promising
that
they're
gonna.
Add
all
this
stuff
that
figma
already
has,
and
maybe
they
will
someday,
and
maybe
they
ultimately
do
win,
but
like
I,
don't
think
we
should
I,
don't
think
we
should
waste
our
time
waiting
for
them.
If
they
do
become
the
superior
tool,
we
can
move
back
to
them.