►
From YouTube: CI/CD By-weekly UX Meeting | 6th March 2020
Description
By-weekly CI/CD UX Team Meeting to go over important updates, discussion items, feedback, etc.
A
Yeah,
okay
cool,
so
it
I
have
the
feeling
that
we
haven't
had
the
sessions
in
a
while.
Well,
at
least
for
me,
it's
that
feeling
again
these
couple
of
Friday's
but
yeah.
Let's,
let's
just
go
through
this,
which,
through
the
agenda
I,
think
and
for
the
first
F
way,
I
read
on
the
item:
I,
don't
see
anyone
needing
backup
or
like
no
times
of
land,
all
of
them
contribute
clamps
and
travels
are
getting
canceled.
A
B
B
You
know
we
left
overs
from
our
job
to
be
done
from
last
year
and
we're
continuously
iterating
on
top
of
it
so
yeah
after
getting
the
feedback,
now
we're
putting
the
prototypes
in
front
of
people
and
getting
quite
some
interesting
feedback,
because
the
personally
the
users
are
like
very
different
for
the
same
category.
So
it's
very
interesting
because
the
ice
release
managers
or
their
pop
DevOps
engineers
that
do
release
management
and
some
of
them
really
want
to
do
everything
through
the
API
and
not
touch
a
single.
B
You
know
button
on
the
interface
while
others
are
super
exciting
with
the
prototypes
and
they
really
want
to
have
this
capability.
We
it
lab.
So
it's
been
interesting
to
see
different
opinions
from
you
know.
We
consider
like
then
the
same
personas.
They
just
have
different
needs
and
I
just
linked
here
this
this
effort.
So
if
you're
curious
yeah,
we
can
go
check
it
out,
I'm
still
documenting
the
the
user
interviews,
but
I
think
this
would
definitely
help
us
frame.
B
A
Curious,
it
may
be
a
quick
question
here
Hana,
so
a
user
mentioned
that
you're
testing
the
prototypes
and
there
are
users
who
wanna
use
the
UI,
and
there
are
some
users
who,
like
prefer,
use
common
line
interface
or
something
like
that.
What's
the
reaction
of
the
people
when
you're
suggesting
them
to
test
the
prototypes
and
they
like
willing
to
use
the
code,
for
example,
instead,
they.
B
Just
say
the
first
reaction
is
I.
Don't
want
this
I
just
want
to
be
able
to
do
every
three
everything
to
this
UID
and
I,
wouldn't
even
think
about
going
through
the
UI.
So
it's
really
like
these
power
users
that
are
very
technical
and
that's
something
that
we
already
support
and
yet
lab
at
least
for
release
management
is
that
you
can
do
mostly
things
through
the
through
the
code
for
the
API
wish
is
awesome,
but
still
they
would
like
to
see
how
that
is
presented
in
the
UI.
B
A
Gonna
be
like
Christie
gonna
hold
it
until
somebody
says:
kidding
torture,
you
people,
let's
go
to
the
next
items.
Well,
actually
any
challenges
that
anyone
wants
to
share
like
anything
happening.
That
may
be
any
help
needed,
or
you
want
to
just
share
something
challenge,
a
challenge
that
you
overcome.
B
B
You
know
what
Caitlyn,
maybe
one,
once
we
move
to
figma
that
can
become
a
bit
easier,
but
I
really
saw
myself
spending
hours
doing
prototyping
to
make
it
like
pixel
perfect
in
a
way
and
I
still
got
quite
some
feedback
from
people.
Oh,
this
is
not
how
it
is
in
the
product,
or
this
is
misaligned
and
I.
Honestly,
don't
want
to
spend
my
time
polishing
prototypes
because
you
know
they're,
not
an
actual
deliverable,
so
I
think
every
designer
at
some
point
struggles
with
that.
B
C
Sadly,
I
have
found
that
I've
had
the
exact
same
experience
where
it
takes
me
five
times
longer,
just
to
make
the
prototype
and
it
does
to
put
the
test
together.
I
have
never
found
a
better
way
around
it.
Unfortunately,
unless
you
partner
with
developers
and
try
to
like
build
it
into
the
products,
but
that
can
even
cost
way
more
than
what
it's
worth.
B
Yeah,
exactly
what
I,
what
I
think
and
to
be
honest,
I
think
I
just
put
the
the
proposal
and
the
discussion
guide
ready
in
like
half
an
hour
and
then
I
spent
the
next
two
days
prototyping.
So
it
feels
come
to
productive
but
yeah
I.
Guess
we
have
to
figure
out
something
at
that
in
the
future.
If
we
need
to
do
more
like
design
evaluations
or
at
least
plan
for
the
proper,
like
the
amount
of
work
that
we
need
to
to
face.
D
I
have
a
very
vastly
different
opinion
on
this
than
most
designers
I
personally
dislike
low
fidelity,
because
visual
is
visuals
matter,
so
I
just
live
in
a
world
where
high
fidelity
is
the
fidelity,
and
now
that
sounds
crazy
right.
There's
the
point
of
little
fidelity
I
mean
I,
do
like
low
fidelity
in
the
sense
of
like.
If
you
want
to
abstract
the
visuals
out
of
it
right,
sometimes
it's
very
important
to
think
like
UX
versus
like
actual
mock-ups,
so
it
is
valid
in
my
opinion,
to
have
like
that
separated
out.
D
But
then
there's
that
other
argument
of
like
low
fidelity
is
faster.
That's
where
I
kind
of
disagree
like
if
you
live
in
a
high
fidelity
world
all
the
time
and
you
develop
that
skill
and
you
have
like
design
files
that
are
high
fidelity
that
allows
you
to
prototype
at
a
speed.
I
would
say
that
I
can
prototype
as
fast
as
most
people
can
in
low
fidelity
in
a
high
fidelity
thing.
So
when
I
produce
mock-ups
and
things
like
that
for
usability
tests,
I
do
not
have
that
problem.
D
I,
bang
them
out
and
it's
fast,
but
it's
because
I
live
in
that
world
all
the
time.
So
it's
a
skill
right.
It's
a
skill
and
it's
a
commitment
to
like
be
in
that
world
right.
So
if
you're
gonna,
if
you're
gonna,
maintain
that,
then
it
pays
off.
But
if
you
don't,
then
it's
like
a
big
deal
to
get
up
to
that
high
fidelity
things.
So
like
everything
in
life,
it's
a
trade-off
right.
So
I
just
I
like
to
think
in
high
fidelity
and.
B
I
think
that's
the
right
exactly
that
should.
My
next
point
is
that
I
need
to
just
build
those
things
from
scratch.
There
is
no
like
ready,
like
an
asset
for
the
releases
page,
for
example.
That's
all
right
there
that
I
can
just
reuse.
I
have
to
completely
build
the
whole
thing
and
yeah
we
do
have
in
the
design
library,
that's
fine,
but
still
I
need
to
manually
I
just
wish.
We
could
automate
that.
A
So
what
what
do
you
both
Hannah
and
my
green-
that
if,
for
example,
if
hi
Anna
would
be
like
everything
designing
everything
in
high
fidelity
the
she
would
make
over
here,
she
would
have
these
parts
for
the
release
management
that
you
could
who
use
in
the
future.
Is
this
your
secret
Mike
that
you
kind
of
like
working
so
often
there
that
you
have
every
part
of
the
page
to
be
used?
Yeah.
D
A
low
fidelity,
the
wouldn't
actually,
because
the
final
mock-ups
were
delivered
at
that
fidelity
so
now,
I
have
this
library
drive
draw
from
you
know
so
I
mean
that
that
did
come
in
a
cost,
but
mm-hm
it's
upfront
and
it
pays
off.
Now
there
is
I'm
not
saying
we
should
go
to
that
route
for
everything
because
get
live,
changes
so
much
and
so
fast
that
maintaining
a
high
fidelity
library
of
everything
would
be
insanity,
and
it
would
just
be
divergent
over
time
but
like
there
are
times
in
life
and
design
where
you
can
like.
D
A
Curious,
like
isn't,
is
the
case
where,
like
the
design
system
in
this
kind
of
like
a
atoms
molecules,
templates
and
all
of
those
like
levels
can
come
in
place
like,
for
example,
couldn't
cry.
Anna
reused,
Italy
some
of
the
parts
for
her
work
from
what
you
were
using
today,
Mike
like
is
there
any
solution
for
us
like
to
share
and
speed
up
each
other's
work?.
D
A
D
Like
the
stuff
that
I'm
building
in
high
fidelity
I'm,
not
building
much
I'm
like
organizing
the
components
from
our
design
library
right
like
the
drop
downs
and
things
like
that,
like
in
general,
there's
not
like
at
the
atom
and
molecule
level,
I,
don't
I
rarely
produce
those
things
I'm,
just
using
those
things,
so
yeah
I
think
using
those
and
leveraging
those
is
a
or
cut
to
this
and
I
think
that
actually
gets
better
in
figma.
Because
that's
that's
where
figma
shines
right
is
having
a
shareable
library
and
not
have
to
download
it
and
resave
it.
D
E
D
E
D
D
B
Like
I
just
write
everything
down
and
then
when
I
have
to
prototype
I'm,
like
my
god,
I'll,
have
to
start
over
again.
So
you
know
we
it's
nice
to
live
in
this
high
fidelity
world,
because
it's
like
what
you
just
say.
You
have
your
your
own
library
and
that's
what
I
did
exactly
which
releases
I
just
built
this
one
file
and
broke
it
in
our
course
with
the
issues
and
all
the
different
versions
with
the
symbols
inside,
because
I
don't
want
to
go
there
anymore.
G
Okay,
yeah,
so
we're
still
in
the
challenges
right,
because
it's
actually
an
interesting
challenge
that
I'm
dealing
with
right
now.
So
we
have
okay.
I
need
to
provide
some
context
first.
So,
as
you
guys
know,
when
you
do
a
merge
request,
there's
this
area
in
the
merge
request
view
that
has
what
we
call
the
merge
request,
widgets
and
those
mush
request.
Widgets.
Also
you
tell
what
they
inform
the
user
is
if
the
pipeline
asked,
if
he
has
with
warnings
if
it
fail.
G
G
G
The
biggest
priority
for
everyone
is
making
sure
that
the
changes
are
passing
the
pipeline,
because
that
that's
what's
basically
matters
at
the
end
of
the
day
when
it
comes
to
making
those
those
mushroom
quests,
that's
just
a
little
bit
of
context
of
what
what
I'm
working
on
so
basically
those
em
are
widgets.
They
testing
my
group
basically
owns
about
80%
of
them.
I
mean
we
own
a
lot
of
them
right.
So
so
we
have
been
dealing
with
this
thing
that
they
are
not
very
usable
anymore
anymore,
because
there
are
a
lot
of
them.
G
I
think
they
were
well
be
signing
in
in
their
moment,
but
now
they
are
not.
They
already
reach
this
usability
ceiling,
but
they
are
not
useful
anymore,
because
there's
so
much
information
in
that
patient.
Everything
that
is
in
that
page
is
competing
for
attention
every
it's
very
verbose.
It's
a
it's
a
very
complex
view
already
right.
So
we
have
an
initiative
in
my
group
start
working
on
those
improving
them
and
funny
enough.
G
Yesterday,
BEC
I
posted
in
the
US,
the
UX
channel,
that
her
team
was
planning
to
do
a
change
from
the
security
widget
them
our
widget.
So
basically,
I
had
to
interject
fast
and
say:
hey,
don't
touch
it
right,
but
we're
working
on
these.
We
know
that
it's
a
problem,
but
what
was
interesting
about
that
issue
is
that
their
solution
was
a
little
bit
bias.
G
It
was
all
we
need
the
attention
from
the
user,
because
these
are
security
threats
that
we
want
to
make
sure
that
the
user
is
in
and
I
completely
agree
with
that
sentiment,
but
that's
a
little
bit
too
opinionated,
especially
because
not
every
persona
that
comes
in
consumes
the
em.
Are
you
has
the
same
goals
on
the
same
responsibility?
So
you
if,
if
I'm
a
product
designer
I'm,
like
about
accessibility
right,
if
I'm,
seeing
that
mr
widget
so
for
me,
seeing
that
in
context
as
the
most
important
thing
matters?
G
So
how
to
interject
fast
and
say,
basically
bring
my
thoughts
and
explain
that
we
already
have
thought
about
these
and
that
first
of
all,
I
thought
that
that
was
competing
for
attention
and
most
likely
what
we
were
gonna
do
as
testing
since
we
own.
So
many
of
them
is
follow
suit
and
try
to,
for
the
sake
of
consistency,
then
make
ours
orange
as
well.
G
G
Kind
of
interesting,
because
I
already
had
this
meeting
plan
with
Pedro
next
week.
We
actually
had
it
this
week
where
we
had
to
reschedule,
but
I
had
this
meeting
with
Pedro
to
talk
about
how
we
are
gonna
approach,
this
right,
because
mr
widgets
are
such
an
interesting
thing.
They
are
part
of
create
as
an
entity
I
think
they
are
owned
by
create
because
they
are
part
of
the
EM
our
view.
However,
the
biggest
client
of
our
markets.
G
It's
the
testing
group,
my
group,
so
we
have
a
lot
of
stakes
on
them,
but
there's
other
teams
like
security
who
also
have
mistakes
on
these,
and
they
have
this
issue
in
which
they're
saying
we
need.
Customers
are
saying
that
they
are
not
seeing
the
security
issues.
What
should
we
do
so
they
want
to
kind
of
put
a
bandaid
on
it
right.
So
we
have
this
crossroad
situation
where
everyone
wants
to
fix
them
and
they
are
not
owned
by
those
groups
that
want
to
fix
them.
E
G
So
the
idea
is
that
we
we
meet
I
added
back
hair
to
the
so
this
is
what
I'm
trying
to
do.
Of
course,
I
want
to
hear
some
thoughts
on
how
to
fix
it,
but
my
approach-
and
this
is
a
completely
new
thing
for
me
here
in
gillip,
so
my
approach
is
gonna-
be
meeting
with
Pedro
I
added
back
up
to
the
meeting
I
didn't
my
product
manager
as
well
and
I.
Think
what
we
and
we
have
the
issue
already
open
right.
G
So
I
think
what
what
I
want
to
do
is,
first
of
all,
a
line
on
responsibilities.
Who
is
responsible
for
what,
of
course,
I
I
remember
that
there
was
a
leadership
directed
early
lady
last
year
whenever
you're
gonna
touch
things
on
em
are
be
very
careful
right
because
that's
a
core
functionality.
If
you
break
it,
then
you
break
it
lap.
If
you
break
it
lap,
then
we
lose
clients
right.
So
it's
we
need
to
be
very
careful
with
with
touching
those
very
core
views
right.
So
I
think
my
first
idea
is
just
a
line.
G
Everyone
who
is
involved
with
em
our
widgets
and
try
to
find
who
is
responsible
for
what,
because
I
really
don't
know
you
know
we
consumed,
consume
them
as
components,
the
components
likely
of
any
kind
I,
don't
think
they
are
actually
it
WI
components,
but
there
are
some
sort
of
component
even
in
in
groovy
or
something
so
we're
consuming
them.
So
I
want
to
make
sure
who
is
responsible
for
what
and
define
first.
That
then
I
think
the
next
step
is
we
have
that
issue
and
I
think.
G
I
lied
for
my
group
from
for
my
for
all
the
things
that
my
group
Serbs,
but
I
understand
that
Mr
widgets
are
not
a
binary
thing.
It's
not.
This
is
good
for
everyone
or
not
they're
slightly
in
many
cases.
So
that's
what
I
want
to
bring
someone
like
Becca,
hey,
bring
me
your
give
me
your
thoughts,
let's
see
if
we
have
to
break
them
apart,
create
different
sections
for
the
aim.
Our
widget
start
thinking
more
out-of-the-box
in
terms
of
this
particular
area
of
the
product.
G
B
I
think
that's
a
great
approach
like
first
identifying,
where
everyone's
responsibility
kind
of
exists
because
yeah
here's
the
agenda
that
I
also
often
touch
merge,
requests
and
I,
don't
feel
like
I
have
ownership
over
it
yeah
much
information
that
we
need
to
add
to
the
merge
request
and
I
think
just
to
kind
of
raise
a
flag
that
sometimes
it's
challenging
to
even
as
a
designer
to
identify
that
the
merge
request
page.
We
need
to
change.
We
can
work.
E
B
B
Interesting
so
I
think
it's
a
great
approach
in
I
would
also,
if
we
decide
to
expand
this
to
something
that
it
can
be
more
cross-functional
I
think
would
be
interesting
to
get
designers
that
have
some
ownership
on.
We
just
like
merge
request
to
have
work,
because
I
know
for
a
fact
that
I'm
gonna
change
things
and
you
have
yeah
recently
that
I
had
to
add
information
just
something
in
the
security
vulnerability,
section
yeah,
yeah.
G
Exactly
exactly
no
I
think
I
again:
I,
don't
have
full
a
full
pair
ahead
for
these,
but
I
think
as
I
go
I
I'm
document.
All
these
things
make
sure
that
what
goes
well
it's
documented
and
what
doesn't
go
well.
It's
also
documented
I
think.
Ideally,
we
should
write
a
a
handbook
page
for
these
type
of
issues.
How
to
press
collaborate
with
other
stages
because
cross
collaboration
with
you
guys
in
in
this
particular
section
I
think
it's
very
well
solved.
You
know
we,
we
know
we
are
continuous.
We
meet
often
we
know
each
other.
G
So
it's
very
easy
for
us
to.
You
know
collaborate,
but
when
it
comes
to
this
type
of
issues,
which
is
a
designer
that
I
rarely
talk
to
you
know,
I
mean
I,
see
them
in
the
meetings
and
I
see
them
on
and
I
talk.
Maybe
you
ask,
charts
or
Becca
happens
to
be
here
in
Austin,
so
I
know
her
well,
because
we
we
meet
for
the.
G
A
G
So
what
do
you,
when
your
feature
or
issue
impacts
another
section
or
group
that
it's
not
within
your
section
right,
so
create
a
handbook
page
that
explains
how
to
approach
that
so
first
create
an
alignment
meeting,
make
sure
that,
from
the
aligning
meeting
you
come
up
with
the
who
is
the
direct
responsibility,
blah
blah
blah
blah.
You
know
Cal
top
document,
all
that
stuff.
So
whoever
faces
this
problem
in
the
future,
you
already
have
something
to
look
at
and
say:
oh
that
makes
sense.
You
know
they
need
in
full
get
love
fashion.
G
D
To
me,
I
hear
what
I
hear
is
not
a
problem.
It's
an
opportunity
because
I
think
one
of
our
one
of
the
struggles
that
we're
going
to
have
as
we
grown
as
a
team,
is
having
multiple
designers
and
people
spread
out
people
get
in
silos
and
we
try
to
do
things
like
us
showcase.
We
used
to
do
like
talk
about
you
know
in
the
kickoff
meeting
what
you're
working
on
and
those
are
all
efforts
to
like
bring
that
back
in.
D
So
when
I,
when
I
come
across
something
that
I
feel
like
it's
going
to
impact
another
designer
to
me,
it's
like
an
opportunity
to
reach
out
that
person.
Work
with
them
get
to
know
them
understand
what
they're
working
on
dive
into
their
world
a
lot
and
then
also
build
that
relationship
to
have
like
you
know,
knowledge
of
what
they're
working
on
what
we're
working
on
so
like
I,
don't
disagree
that
it's
not
difficult,
but
I
like
to
look
at
these.
It
operates
right.
G
Right,
no
there's
there's
the
point
opportunity
there
I
agree,
I
think
where
I
got
a
little
bit
kind
of
like.
Oh,
my
god.
This
is
not
good
he's
the
fact
that,
like
he,
Becca
doesn't
post
that
on
the
UX
Channel
yeah
he
just
you
have
changed
that
and
I
wouldn't
have
ever
found
out
about
that.
You
know
yeah,
which
is,
which
is
what
we
need
to
solve
everyone
every,
because
that
they
were
gonna
impact,
something
that
impact
me
and
I
was
not
gonna.
G
A
E
D
Me
the
process
will
be
I.
I
would
be
to
document
too
much
of
a
process
because
it
would
be
as
far
as
like
how
the
designers
collaborate
right,
because
that's
going
to
vary
so
much.
You
know
there's
two
to
fold.
Every
designer
works
a
little
bit
differently
and
you
put
two
together
then
that's
four
times
variance
of
you
know
how
that
process
working
between
the
would
be,
but
what
I?
What
I
do
believe
should
be
documented
is
what
we
just
talked
about
there
like.
D
If
you're
going
to
touch
area
X,
you
must
reach
out
to
designer
Y
right
and
I.
Think
I
own
and
I
talked
about
this
a
little
bit
even
in
the
CICE
stage
of
like
you
know,
establishing
I
know
we
have
that
page
of
like
this
designer
is
responsible
for
this,
but,
like
that's
so
hard,
sometimes
to
go
in
there
and
figure
out
who's
working
on
what?
If
we
have
like
a
clear
like
if
you're
gonna
do
this,
you
need
to
talk
to
this
person,
or
at
least
ping
them
make
them
aware
of
it
to
me.
D
B
But
to
me
this
is
really.
The
biggest
problem
is
not
even
figure
out
how
to
collaborate
with
people
but
to
spot
those
opportunities
ahead
of
time,
because
by
the
time
that
I,
for
example,
identified
that
the
meeting
is
doing
some
feats
in
you're
probably
happening
out.
You've
won
right,
you
Becca
is
gonna,
stop
and
it
one's
gonna
have
they're
gonna
have
to
have
this
conversation,
and
that
takes
more
time
and
that's
a
whole
different
different
cycle.
So
I
think
solving.
This
is
problem
one.
But
to
me
and
I
think.
B
What
would
make
me
super
happy
is
to
identify
the
areas
that
are
shared
by
default,
like
what
Mike
just
say
and
have
a
way
to
validate
this
ahead
and
I.
Gotta
hear
this
handbook
page.
That
talks
about
in
this
case
is
right
for
when
customers
want
to
do
XYZ
and
they
want
to
do
it
through
merge
requests
or
blah
blah
blah.
B
So
I'm
not
sure
if
we
can
use
this
or
personas
or
whatever,
to
kind
of
build
these
knowledge
bases
across
the
UX
department,
where
you
know
that
when
you're
working
with
merge
requests,
you're
gonna
impact
one
Mike,
hi,
Anna
and
Ian-
and
you
need
to
know
ahead
of
time
that
you
need
to
validate
with
them
your
proposals.
So
it
should
be
easy.
She'll,
be
part
of
the
process,
just
a
conversation
and,
in
my
point
of
view,
not
necessarily
along
like
handbook
page
with
all
the
steps.
B
D
I
think
a
lot
of
that
gold
isn't
evangelizing
the
idea
that
assume
there
is
impact
by
default
right,
never
assume
that
it's
not
going
to
affect
someone
like
that's
one
of
the
ones,
one
of
the
first
things
I
always
do
I
just
had
this
yesterday,
where
somebody
was
the
issue
was
adding
to
do,
and
my
first
thought
was
like
I.
Don't
do
to
do
is
let
me
go
find
the
designer
who
does
and
I
took
a
little
bit
right.
D
I
didn't
even
know
who
it
was
because
of
a
shuffle
I
had
to
talk
to
manager
with
the
manager
involved,
but
it,
but
it
worked
right.
It
was
a
day
process.
I
got
the
right
person
and
now
they're
in
the
issue
and
all
they
did
was
say
yep
that
looks
good,
but
at
least
now
Holly
knows
that
a
to-do
was
impacted.
B
I
do
have
a
open
issue,
maybe
by
Nadia
the
other
Nadia
about
like
a
UX
template
for
issues
or
something
like
that.
This
is
definitely,
in
my
opinion,
like
an
acceptance
criteria.
It's
a
check.
You
know
the
same
for
pajamas
is
check
if
this
is
has
dependency
or
if
it's
gonna
have
an
impact
in
a
different
product.
There
yeah,
because.
A
B
Because
it
really
proposes
that
that's
a
UX,
template
and
I
think
it
should
be
a
feature
template
right
if
you
know
that
this
feature,
for
example,
I'm
working
with
progressive
delivery
and
I'm
impacting
my
requests.
It's
already
not
my
area
right.
It
should
be
something
in
the
acceptance
criteria,
that's
also
worse
for
the
developers,
because,
if
TPM
can
identify
that,
we
can
already
say,
hey
I
need
more
time
to
check
this,
because
I
need
to
check
with
these
many
designers,
but
also
on
this
capability.
D
That's
a
great
point:
we
just
had
that
in
where
engineers
would
benefit
from
this.
This
share.
First,
you
know
where
we
had
something
where
we
were
about
to
rebuild
something
in
view
and
turns
out.
The
verify
group
was
working
on
the
very
same
area
of
rebuilding
and
view,
and
if
it
wasn't
for
a
little
design
collaboration,
we
would
have
not
known
about
that
so
yeah.
This
isn't
just
a
u.s.
problem.
This
is
an
engineering
problem.
P.M.
problem
is
everybody
problem,
so
a
forced
check,
point
I
think
would
be
great.
G
Yes,
I
just
had
a
random
thought.
It's
a
it's
a
little
stupid
thing,
but
I
wouldn't
be
great
if
there
was
something
that
you
have
like
crumb
extent
where
you
hover
over
something-
and
it
tells
you
oh,
this
is
owned
by
these
p.m.
this
designer.
This
engineering
manager
I'll
be
amazing,
as
you
navigate.
Your
Lobby
tells
you
who
owns
what.
D
D
You
know
I
do
think
the
counterpoint
to
this
would
be,
though,
like
you
know,
I
can
see
Nadia's
wheels
turning
over
there
and
like
let's
go
propose
this
and
let's
make
a
company-wide
change
on
this.
I
can
already
hear
the
resistance
to
this.
We
do
have
like
be
the
DRI.
You
know
do
things
quickly.
You
know
there
is
that
counter
argument
to
this,
that
adding
this
checkbox
slows
down
every
single
issue
that
gets
made
and
I
think
that's
the
counter-argument
to
this
that
we
are
likely
going
to
encounter
I'm.
A
Merge
request:
let's
do
it,
yeah
I
think
that's
a
good
idea.
Well
at
least
there's
gonna
be
a
nice
reminder.
If
that's
not
gonna
come
into
anything
tangible
thanks
man,
all
righty.
We
have
like
10
minutes
left
of
official
time.
Should
we
move
on
to
the
next
items,
because
we
have
quite
some
to
discuss
okay,
cool
so
about
the
process
section
so
they've
been
quite
a
process
updates
as
you've
seen
I've
gone
wild
in
this
section
and
I
just
wanted
to
share.
A
So
I
know
that
Keanu
and
one
will
probably
be
affected
by
this
first
and
Jeff
and
Sarah
been
drafting
this
process
pronounced
even
Omar,
but
I
think
it's
almost
ready
to
be
an
official
change
to
the
handbook,
so
I
encourage
everyone
to
go
I'm
sure
some
of
you
have
seen
this
already
go
through
the
process
provide
a
feedback.
If
you
have
any,
it
sounds
like
it
seems,
it
was
quite
a
people
already
added
to
that.
A
This
wood
was
what
was
coming
out
with
some
of
the
people
that
we
already
got
delivered.
So
if
you
will
have
any
questions
or
any
suggestions,
let's
or
discuss
it
there
or
let's
bring
it
up
in
other
meetings
like
this
or
in
one
wants,
and
then
the
official
changes
that
already
have
been
merged.
That
was
a
slight
updates
to
the
problem
validation
process
and
to
the
solution,
validation
process
and
updates
to
these
two
processes
been
mostly
caused
by
the
head.
Complaining
news
that
also
been
recently
announced.
A
So
the
biggest
change
in
the
problem
validation
was
that
the
official
day
arrived
for
that
right
now
is
the
p.m.,
and
so
if
you
follow
up
the
steps
most
of
the
items,
the
management
should
be
triggering
and
together
in
a
cooperation
with
the
UX
researcher.
So
by
default
the
burden
of
the
product
designers
work
it's
kind
of
like
falling
off,
so
we
are
being
released
in
there.
I
know,
that's
not
necessarily
a
good
thing
for
some
of
us.
A
B
Thought
this
change
was
quite
interesting,
because
the
way
that
we've
been
conducting
problem
validation,
at
least,
is
that
PM's
and
researchers
are
the
DRI
all
right.
So
the
designer,
at
least
for
my
understanding,
was
not
really
necessarily
the
owner.
The
DRI
of
this
is
initiative
and
I
found
quite
interesting,
because
Jackie
and
I
have
been
conducting
validations.
Both
problem-solution
validations
quite
smoothly
in
the
last
couple
of
months
and
I
wondered
like
how
this
changed
like
this
step
of
research.
Now
it's
lady,
so
we
open
the
request
and
then
we
have
to
follow
all
the
steps.
B
How
that's
going
to
affect
us
because
principal
Jackie
just
knows
people,
and
then
she
just
schedules
calls
with
them
informally,
and
then
we
conduct
the
interviews
kind
of
an
on-the-fly
and
I
wonder
how
this
change
will
affect,
like
teams
that
are
already
in
a
way
driving
with
the
process.
The
way
that
it
is.
If
this
is
more
like
a
suggestion
and
a
recommendation,
then
you
know
a
hard
guideline
for
how
do
we
want
to
conduct
but
yeah
I
kind
of
overkill
in
all
these
steps,
precisely
like
that
for
something
that
we
already
do
the.
B
Think
what
I
miss
from
this
merge
request
is
saying
that
yeah,
if
you
can
do
this
yourself,
then
just
go
ahead
and
do
it
that's
kind
of
missing,
because
is
that
gonna
be
it?
Is
the
research
coordinator
coordinator
necessary
because
they
need
to
look
at
the
budget
or
they
need
to
allocate
I,
don't
know
resource
resource
from
the
researcher
when
evaluating
our
insights
dadada
or
is
it
just
for
the
sakes
of
the
process?
That's
kind
of
like
my
question.
C
My
name's
mines
kind
of
attached
and
now
I
feel
a
little
awkward
and
not
quite
as
hash,
but
I've
noticed
as
as
we've
kind
of
filled
out
the
problem,
validation,
installation,
validation,
Sam
and
I
were
doing
a
really
good
job,
I
think
in
the
beginning,
like
just
doing
the
research
and
going
for
it
and
recently
it's
turned
into
a
lot
of
paperwork.
I
feel
like
I'm
writing
the
same
thing
multiple
times
now
so
I
guess
along
iona,
has
kind
of
the
same
question.
A
Yeah
well,
these
are
very
good
points
and
I
think
they're
worse
to
be
delivered
to
Jeff
and
Sarah
to
the
UX
research
team,
because
they're
responsible
for
this
process,
I
felt,
like
we've,
been
bringing
some
of
this
similar
feedback
and
then
again
the
yeah.
This
is
kind
of
like
the
suggestion.
I
take
this
as
a
suggestion
for
the
process.
A
This
question
in
the
research
UX
research
channel
and
just
ask
them
there
or
if
you
want
to
control
on
that,
but
I
think
like
the
best
will
be
if
research
team
would
hear
the
feedback
and
these
types
of
questions
from
the
product
designers
themselves,
because,
as
I
was
saying
to
some
of
you
earlier,
you
are
the
people
who
are
driving
this
process
and
going
actually
through
that.
So
you
are
the
best
people
to
talk
about
that.
From
your
day
to
day
experience.
A
A
More
people
will
see
that
and
maybe
more
people
say
hey
plus
one
plus
one.
You
know
because
I
feel
like
yeah.
This
is
what
I'm
saying
that
I
feel
like
we
had
the
similar
discussions
before
and
because
it
maybe
didn't
get
so
much
+1
balls,
because
maybe
it
wasn't
feasible
to
the
wider
audience.
This
is
why
I
didn't
get
so
much
attention,
so
I
think
the
best
thing
would
be
to
do
that
here.
E
A
Validation,
space
and
the
biggest
change
was
that
a
product
designer
should
leverage
at
that
time
and
the
help
of
the
yucks
managers
to
help
with
the
validation
process
to
help
like
yeah,
maybe
pick
the
way
of
the
testing
that
the
type
of
the
testing
yeah
and
help
solving
any
issues
that
could
come
up
there
so
like
the
UX
manager
should
be
the
first
person
that
product
designers
can
ask
help
for
in
this
type
of
process.
There
are
more
details
described
here
as
well
as
in
any
solution.
A
Validation,
I
think
you
have
to
assign
it
also
to
the
yourself,
but
also
to
New
York's
manager.
I
would
be
happy
to
be
more
to
be
more
involved
in
this
process.
I
miss
this
part
of
work
until
now.
I
wasn't
very
much
involved
would
be
happy
just
to
be
as
fYI
in
the
beginning.
If,
if
anyone
needs
help,
they
happy
to
help
solving
that
as
well
curious
to
hear
feedbacks
as
well
as
we
go
trying
that
process
and
yeah
and
I
know
that
a
you
put
some
comment.
A
One
of
a
collective
swamp,
Lana
you're,
talking
about
solution,
elimination
like
you,
settle,
oh
that's
different,
so
yeah.
Let's
give
it
a
try
and
again
always
open
to
you
tonight.
If,
if
we
need
it,
okay
and
I
noticed
that
we
are
three
minutes
through
minutes
over
at
the
time.
So,
if
I
know
it's
Friday
and
it's
later
for
some
of
us,
if
I'm
hoping
to
stay
for
5-10
minutes
more,
if
we
feel
like
that,
if
not,
we
can
just
move
the
items
to
the
next
session
who
wants
to
who
needs
to
go.
A
B
Then
quickly,
Ayanna
to
your
point,
yeah
go
quickly
over
this
one.
I
think
I'm
sure
I've
mentioned
this
before,
but
I'm
not
using
issue
boards
anymore
and
I.
Think
other
designers
are
doing
something
similar.
But
I
just
wanted
to
show
you
here
how
Jackie
and
I
are
prioritizing
the
issues
for
the
upcoming
milestones
and
then
that's
with
an
epic
where
she
just
throws
there
everything
that
I
need
to
look
at
that.
B
It's
still
open
and
that's
also
kind
of
like
provides
me
guidance
so
that
I'm
not
in
the
context
of
the
plainly
or
dev
boards,
because
the
priority
change
is
quite
a
lot
there
yeah
and
I
just
linked
in
epic.
Here.
If
you're
curious,
it's
been
working
very
well
because
yeah,
it
gives
me
just
a
single
point
to
focus
on
rather
than
having
to
ask
what
the
priority
is
or
having
to
check
with
the
p.m..
B
So
that's
super
cool,
because
when
I'm
done
well
I
kind
of
scoping
the
issue
I'm
over
the
issue
to
its
proper,
like
the
proper
epic
instead
of
the
UX
needs,
you
actually
view
epic
and
we
can
really
see
like
yeah.
Things
are
a
movie
and
if
they
come
back
and
I
need
to
risk
oak,
so
that's
what
I've
been
doing
and
yeah
it's
been
working
for
me.
B
Cool
tank
I'll
definitely
check
interesting
approach
and
I'm
gonna
quickly
jump
to
my
next
point,
which
relates
to
the
previous
topic
about
the
maturity
scorecard.
Yeah
and
I
have
been
chatting
about
this,
but
I
just
wanted
to
know
from
the
other
side
from
my
kin
who
want
what's
your
plan
and
have
you
guys
like
thought
about
it
or
you
have
an
idea?
How
are
you
going
to
tackle
this?
Pokey
are
ya.
Maybe
we
can
have
awesome
ideas
and
support,
or
in
this
challenge.
G
D
To
create
a
plan
actually
talked
about
this
yesterday
and
our
feet,
have
you
asked
them?
We
need
to
create
a
plan,
so
I
made
a
issue
for
myself
and
my
personal
board
to
create
a
plan.
So
that's
where
our
plans
out
I
do
think
like
it
is
enticing
to
kind
of
like
see
if
we
could
do
some
cross
stuff,
but
I
do
think
that,
ultimately,
these
are
probably
going
to
have
to
be
like
somewhat
siloed
right.
A
A
A
So
yeah,
hey
you,
like
my
plan,
my
suggestion
for
a
plan
here
it
seems
like
hi,
Jana
and
Ian
will
be
the
first
people
to
try
and
a-one.
If
you
have
any
already
plan
for
jobs
to
be
done
for
the
maturity
change,
let's
stay
on
in
close
think
and
let's
raise
issues
as
they
come
in
yeah
again
this
is
an
OK
or
even
if
we
will
miss
it,
it's
nobody
gonna
die.
We
will
learn
from
it,
but
let's
give
this
process
a
try.
So
then
we
see
clear
steps.
A
D
Mean
that's
seem
a
little
bit
unrealistic
that
they
haven't
even
finished.
The
process
merge
request
that
this
you
don't
saying
you
never
do
design
and
in
engineering
in
the
same
milestone
I
you
never
define
the
process
and
and
expect
the
process
to
be
followed
in
the
same
quarter.
That
just
seems
I
don't
know,
because
we
talked
about
that
yesterday.
So
in
my
plan
to
create
a
plan
we
discussed,
we
probably
can't
implement
the
plan
until
the
merge
request
defining
the
process
is
in
place
before
we
can
execute
against
said
process.
A
A
very
fair
comment-
and
you
know
what
I
think
I'm
gonna
be
not
I,
think
I
will
schedule.
We
have
one-on-ones
with
Jeff
and
I'll.
Just
gonna
say
that
we
have
these
discussions
in
in
the
in
CI
CD.
So
then
they're
at
least
like
where
maybe
he
yeah.
Maybe
he
has
something
to
suggest.
It's
very,
very
fair
comment:
you're,
saying
like
that,
it's
like
March,
it's
almost
well
it's
middle
of
the
order
and
it
seems
like
the
process
was
just
finalized.
A
B
That
I
also
want
to
make
a
suggestion
here.
Cuz,
the
scope
is
very
broad
at
this
point,
with
the
whole
suggestion.
I
think
if
we
want
to
have
some
sort
of
deliverable
for
this
quarter,
given
that
the
quarter
is
already
I,
don't
know
already
started,
I
see
two
things:
one
is
changing
the
OPR
to
be.
You
know
defining
what
the
OPR
is
during
this
quarter
and
whatever
things
we
decide
to
do,
break
it
down
to
smaller
deliverables.
So
the
first
you
don't
have
to
do
everything
at
once
right.
B
We
have
all
those
priorities
as
well,
so
maybe,
instead
of
conducting
all
this
research
and
talking
to
all
these
users
and
looking
at
all
the
clicks
that
they
do,
we
break
the
first
part
is
identifying
what
workflows
you
need
to
validate.
Second
part
is
plan
the
research,
the
artists
conduct,
the
research
evaluate
blah
blah
blah.
Instead
of
making
this
a
big
deliverable,
that's
gonna
be
very
challenging
to
to
tackle
at
once,
cuz
yeah.
Have
you
been
having
discussions
with
the
Jacqui
and
we're
just
a
bit
concern
that
this
might
take
more
time
than
you
know.
B
D
Yeah
and
playing
off
that
a
little
bit
like
I
would
I
would
like
to
see
us
do
like
everybody
try
to
do
one
of
your
categories
and
then,
let's
see
how
the
process
went
and
like
you
got
a
user
test,
the
process
before
you
try
it
like
this
is
the
process
and
do
it
across
everything.
It
would
be
nice
to
do
like
a
pilot
like
pick
one.
Try.
The
process
see
how
it
like
works,
user
feedback
gain
that
and
then
let's
use
that
to
define
the
process
right.
Like
user
research
works
for
everything,
including
this.
A
A
A
G
A
G
G
G
We
don't
have
anything
in
lovable,
I.
Think
I
think
that
it's
a
really
there's
some
that
are
close
to
like
being
reevaluated,
but
we
have
performance.
We
have.
We
have
accessibility,
we
have
you
need
testing,
so
we
have
so
many
right
so
again,
I
want
to
take
that
back.
I'm,
not
saying
that
he's
coming.
For
me.
It's
likely
that
at
least
one
my
based
on
things
are.
We
are
gonna,
be
shipping
soon
on
12,
9,
12
10.
It's
slightly
that
one
might
be
on
a
state
in
which
we
say
like.
Let's
see
what
happens
in.
A
D
D
Really,
you
know
we're
not
able
to
meet
yesterday,
so
we're
hoping
to
utilize
this
time.
It
is
a
slight
unfortunate
thing
that
the
way
our
agenda
is
set
up
that
sometimes
the
first
point
added
is
the
last
one
discussed
but
I
don't
know
Ian.
What
do
you
think?
Is
there
a
quick
blurb
we
can
give
here
and
not.
D
C
Optimistic
think
big
is
next
week.
This
is
really
exciting,
we're
bringing
p.m.
and
you
Xers
together.
You
all
know
this
lovely
magic
I
recently
went
through
the
agenda
and
made
some
adjustments.
What
we
could
use
from
you
guys
is
you
all
correction
is
to
add
point
similar
to
what
I
had
done
per
package
and
what
Ayane
had
done
for
CI,
where
it's
like.
We
have
this
insight,
here's
a
question
we
have
and
we
want
to
get
to
about
four
of
those.
C
So
we
can
go
through
the
think,
big
and
have
these
conversations
so
that's
kind
of
what
we
need
from
everyone
else
to
move
it
forward
is
to
basically
create
those
discussion
points
I'm,
gonna
start
off
with
an
easy
one
for
package.
That's
just
really
easy
to
understand.
It's
easier
relates
to
and
has
a
pretty
wide
net
go
through
some
brainstorming,
we'll
move
on
to
the
next
one.
I
think
I
did
that
in
under
a
minute,
I'm
really
proud
of
myself,
but
I
actually
have
to
go
so
I'm
going
to
do
really
mean
and
say.