►
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
So
I'm
gonna
set
a
little
bit
of
background
context
as
to
sort
of
what
you
know
the
context
of
this.
This
research
is
all
about
so
earlier
on
a
couple
months
back,
we
set
a
okay
arm
for
ourselves
like
a
little
self-imposed
okay,
our
for
ourselves
and
managed,
and
what
we
wanted
to
do
was
to
update
a
component
design
documentation
within
pajamas,
using
solution,
validation
and
as
well
as
doing
this
process
test
with
user.
A
So
what
were
the
research
objectives
so
in
the
context
of
this?
Okay?
Are
the
research
objectives
were
to
test
the
usability
of
new
and
existing
designs
for
tables
in
the
context
of
code
review
analytics,
which
is
a
new
MVC
feature
that
we
shipped
in
the
last
couple
of
milestones?
So
in
this
we
wanted
to
test
one
the
the
existing
functionality
within
tables,
so
how
the
the
relationship
between
search
and
tables
works
as
well
as
pagination,
is
to
make
sure
that
that's
understood
well
by
users.
A
New
functionality
is
so
chunking
in
a
couple
of
new
things
like
sorting
using
columns,
integrated,
pagination,
expandable
rows,
user-defined
table
columns
a
lot
of
good
stuff
there
and
also
testing
out
some
new
styles
as
well
around
like
stripes
and
and
row
padding,
and
we
tested
these
with
five
I'm.
Sorry,
six
engineering,
managers
or
team
leads
the
way
we
prioritized
and
came
to
these
companies.
Bits
of
functionality
that
we
wanted
to
add
to
the
table
was
through
this
little
prioritize,
a
prioritization
exercise
in
mural
right
here
and
that's
just
a
little
demo
of
it.
A
So
in
our
approach
we
set
the
user
as
a
scenario
and
we
gave
them
three
tasks
so
as
an
engineering
manager
they're
looking
to
see
how
they
could
unblock
different
mr-s
in
their
code
review
process,
the
first
task
we
actually
used
the
live
code
review
analytics
feature
testing
the
existing
functionality.
Second,
one
we
used
a
sketch
prototype
testing.
A
It
was
the
issue
for
the
planning
and
we
also
have
the
the
research
planning
and
discussion
guide
and
notes.
All
in
one
google
talk,
we
worked
as
a
team
to
analyze
and
synthesize
the
the
outputs
of
the
research
in
mural,
which
was
really
useful
and
I
thank
Katherine
and
Mike
and
Dan
a
lot
for
helping
with
that
and
and
then.
Finally,
we
summarized
it
up
as
a
as
an
epic
with
little
sub
insight
things
as
we
should
do
normally
and
you
can
access
those
all
through
the
links
there.
A
A
So
we
need
to
test
this
with
with
bigger
organizations,
but
with
the
users
that
we
did
test
it
with
there
wasn't
too
much
utility
users
didn't
really
differentiate,
much
between
the
code
review
process
and
Amar's
in
general.
This
was
sort
of
hinted
at
by
the
fact
they
were
willing.
They
wanted
to
see
a
lot
of
pipelines
in
context
of
this.
They
wanted
to
understand
whether
the
EM
ours
were
open
or
closed
we're.
If
it's
code
review
probably
would
be
open
anyway.
A
So
there's
a
there's
a
little
bit
of
stuff
room
there
and
users
also
wanted
to
see
more
advanced
filters
and
find
get
fine-grained
controls
in
order
to
manipulate
the
data
within
the
table.
These
are
just
some
of
the
top
insights
and
the
recommendations
that
came
out
of
the
back
of
it
where
the
reframing
this
tactical
type
of
code
review
analytics
where
you
have
a
number
of
tables
in,
are
looking
to
unblock
different
M
ours
to
M
our
analytics
and
and
then
having
different
views.
A
To
give
you
better
access
or
understanding
of
what
the
M
R
is
is
going
through.
So
code
review
could
potentially
be
a
specific
view
of
that.
Having
a
more
aggregated
or
strategic
view
of
code
review
analytics
within
our
value
stream,
analytics
framework
could
be
a
new
way
of
going
about
it
and
thinking
about
and
using
this
as
a
method
of
finding
patterns
and
spotting
patterns
and
filtering
a
rate
filtering
away
data
to,
under
an
unknown
sorry
to
understand
a
little
bit
more
about
your
process
and
how
you
may
improve
it.
A
There
is
a
recommendation
for
having
or
creating
a
pattern
for
toggling
labels
on
and
off.
So
they're
not
too
obstructive
in
the
view
within
the
table
and
then
finally
reevaluate
and
on
our
definition
of
code
review
is
a--
is
a
bigger
group
definition
as
well
table
components.
Some
of
the
key
insights
and
recommendations
we
have
here.
The
relationship
between
search
and
filter
is
very
well
understood
with
the
audience
that
we
pitch
to,
but
there's
room
for
more
clarity,
especially
if
there's
more
components
on
the
page.
A
Users
wanted
more
functionality
from
tables
as
well,
I
think
there's
an
expectation
just
default
expectation
for
table
sorting
and
being
able
to
hide
rows,
especially
in
the
context
of
unblocking
Amar's
and
then
zebra
stripes
were
where
a
head
as
well.
I've
been
made
fun
of
before
for
pronouncing
a
zebra,
so
I'll
say
zebra
for
the
the
american
audience
their
top
recommendations
table
sort.
I
think
that's
a
given,
embedded
pagination.
This
is
a
new
design
which
I
showed
a
little
bit
earlier.
A
Implementing
that
that
sort
of
made
sense
to
users,
especially
when
pages,
get
a
little
bit
more
complicated
as
well
filter,
signifier,
so
having
some
sort
of
visual
relationship
between
a
table
and
the
thing
that
has
actually
filtered
it,
such
as
a
searcher
or
filter
bar
influenced,
zebra,
stripes
or
zebra
stripes
and
advanced
filter
as
well,
and
exploring
how
we
may
go
about
with
that.
So
we
did
a
little
mini
retrospective
on
this
on
this
research
approach.
A
What
went
well
there's
a
lot
of
good
learnings,
in
my
opinion,
at
least
from
the
table,
components
and
and
the
the
feature
itself.
So
I
was
really
happy
with
that.
Really
happy
to
be
able
to
collaborate
with
the
rest
of
the
team
and
dan
was
great
as
well,
because
he
helped
come
in
and
take
notes
and
stuff
on
the
interview
sessions.
A
I
think
this
is
a
useful
way
or
useful
researcher
approach
which
can
potentially
be
templatized
for
refining
the
content
within
pajamas
and
then
really
grateful
for
the
broader
support
from
from
the
rest
of
the
manage
team
and
Emily
and
Catherine
as
well.
They
are
really
useful
in
this
and
then
what
didn't
go
so
well,
since
this
was
sort
of
like
a
side
activity
for
me,
I
didn't
give
the
scenario
planning
and
the
tasks
enough
focus
and
thought.
I
could
probably
done
a
lot
more
work
in
the
prototypes
themselves
to
maximize
learnings
but
yeah.
That's
that's!
A
A
The
process
is
laborious,
so
I'm,
looking
forward
to
death
dovetail
for
sure
learning
goals.
Try
not
to
cram
too
many
things
into
one
project
which
I'm
very
guilty
of
use
cases
being
able
to
see
how
the
component
fares
within
more
use
cases
would
also
refine
refine
the
component
itself
and
then
also
want
to
try
out,
like
this
rainbow
notes,
approach
that
I
saw
before
so
that's
some
of
the
learnings
from
our
retrospective.
A
So
next
steps,
as
I
said
before
this
is
in
the
context
of
the
broader
okay,
are
so
there's
the
other
aspects
that
we
want
to
be
tested
and
what
we're
gonna
be
doing
now
is
taking
these
recommendations.
Taking
these
insights
and
starting
to
feed
them
back
into
pyjamas
is
a
design
system,
so
yeah
we're
coming
to
the
design
phase
of
this
now.
So
some
questions
I
have
for
you
and
feel
free
to
provide
this
feedback
either
to
me
in
slack
or
just
on
this
and
comment
within
within
the
the
Google
Doc.
A
Any
critique
on
this
content
or
processed
like
to
talk
to
us
about
getting
the
designer
a
developer's
perspective
from
this
okay
are
as
well,
and
is
anyone
interested
in
sort
of
replicating
this
feature
plus
components
approach
together
and
if
so,
how
can
we
assist
special
thanks
to
all
these
people
right
here
for
all
their
help
throughout
this
and
all
their
their
inspiration
and
collaboration?
So
I'm
really
appreciative
of
the
team
and
really
happy
to
work
with
everyone.
Special
thanks
to
all
of
you
for
putting
up
with
me
as
well.