►
From YouTube: UX Showcase Planning Objects Discovery
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
I'm
holly
reynolds
senior
product
designer
on
the
plan
team
in
the
project
management
group.
Today,
I'm
going
to
be
talking
about
planning
objects,
discovery,
work
that
we've
done
recently.
This
is
an
unrehearsed
presentation.
I
normally
like
to
give
it
at
least
a
good
run
through
first,
but
just
ran
out
of
time
this
time.
So
I
apologize
for
ums
and
any
awkward
pauses
as
I
get
my
thoughts
together
and
also
for
the
kind
of
blandness
of
the
slides
there,
but
we'll
get
through
it.
A
A
A
In
that
we
have
issues
and
incidents,
but
converting
planning
objects
to
kind
of
expand
on
those
issue,
types
exploring
possibilities
surrounding
making
issues
extensible
so
that
customers
can
kind
of
customize
the
interface
and
add
and
remove
widgets
as
they
see
fit
and
then
finally,
creating
a
new
collaboration,
object
view
and
it
was
broken
into
four
iterations.
We
have
just
finished
the
second
iteration,
so
it's
currently
ongoing
work
and
in
this
particular
showcase
I'll
just
touch
on
what
we've
learned
and
kind
of
discovered
as
part
of
the
first
two.
A
So
to
summarize,
the
engineers
were
planning
to
refactor
the
issue,
view
into
a
single
view,
app
for
performance
reasons,
and
we
were
exploring
possibilities
to
maybe
improve
the
user
experience
and
add
in
some
additional
possibilities
surrounding
that
we
were
calling
it
a
collab
checked,
which
was
kind
of
a
tongue-in-cheek
term.
We've
defined
it
now
as
a
planning
object,
not
sure
if
that's
going
to
be
the
final,
def
or
final
label
for
it,
but
that's
what
we're
calling
it
currently.
A
Those
issue
types
that
I
had
talked
about
and
kind
of
expanding
into
offering
things
like
bugs
and
features,
and
some
of
the
other
types
of
issues
that
users
have
requested
before,
but
then
also
setting
us
up
to
make
those
extensible
again
and
finally
explore
child
elements
for
planning
objects
which
is
actually
going
to
be
part
of
the
the
upcoming
research
a
bit
more
than
what
we've
done
so
far,
and
actually
let
me
go
back
really
quick.
So
we
wanted
to
create
a
new
planning
object
and
explore
ways
to
improve
the
experience
again.
A
Part
of
it
was
engineering
focus,
part
of
it
was
ux
and
product
focused.
We
wanted
to
start
with
a
blank
slate.
That
was
something
that
was
kind
of
being
encouraged
throughout.
This
initial
process
was,
let's
take
a
large
chunk
of
time
about.
I
think
it
was
about
four
to
six
weeks
actually
closer
to
six
weeks
and
start
with
a
blank
slate.
If
we
had
a
blank
template
for
a
planning
object,
what
would
that
look
like?
A
We
wanted
to
understand
what
the
core
item
was,
that
everything
else
might
be
built
upon
what
its
purpose
was,
how
it
affects
other
objects
in
the
product.
We
had
a
lot
of
questions
come
out
of
this.
The
desired
outcome
was
to
converge
on
the
structure
for
planning
objects.
That
gets
us
close
to
the
goal
to
stand
out
amongst
our
competitors.
So
essentially
we
wanted
to
just
explore
ways
to
improve
collaboration
that
helps
to
set
us
apart
from
our
competitors.
As
part
of
this
initial
research
based
on
ux
opportunities.
A
With
this
new
planning
object,
we
already
knew
our
users
pretty
well
parker,
delaney
and
sasha
were
who
we
were
focusing
on.
We
already
had
a
lot
of
good
research
to
kind
of
help,
support
some
of
the
ideas
that
were
explored
here,
so
we
had
done
research
previously.
I
had
done
research
for
sticky
headers
for
the
jobs
to
be
done,
validation,
category
maturity
on
issue
tracking.
So,
as
a
result
of
all
of
that,
we
had
a
lot
of
feedback
from
users
about
what
works
and
what
doesn't
work
as
well
as
from
sus.
A
A
How
might
we
take
the
outcomes
of
threaded
discussions
and
efficiently
capture
them
in
the
description
as
a
single
source
of
truth,
and
how
might
we
reduce
the
amount
of
context?
Switching
between
the
sort
of
core
concepts
within
the
planing
objects,
such
as
title
and
description,
and
the
discussion,
as
well
as
between
the
planning,
object
and
other
planning
objects
or
other
parts
of
the
product
we
met
synchronously.
This
was
defined
up
front.
We
would
meet
synchronously
twice
a
week
and
present
design
ideas
for
each
session
again.
A
A
So
for
my
part,
in
these
first
two
iterations,
a
lot
of
the
focus
was
on
reducing
the
amount
of
context
switching
and
so
I
explored
a
lot
of
layout
possibilities
and
decided
on
testing
reducing
context.
Switching
is
kind
of
the
the
main
focus
and
I'll
show
some
examples
of
that
in
just
a
moment,
and
actually
let
me
go
ahead
and
share.
A
Am
I
sharing
my
whole
monitor
or
just
the
figma?
Can
you
still
see
everything.
A
You
great
thank
you.
I
know
it's
large,
it's
very
large
and
I'm
sorry
about
that
I'll
zoom
in
just
to
touch
on
a
few
key
points.
So
again
there
was
a
lot
of
exploration
and
I
also
referenced
and
the
agenda
some
user
flows
that
we
created.
There
were
a
lot
of
insights
that
I
had
pulled
into
an
affinity
diagram
and
grouped
that
I
didn't
include
in
the
agenda,
but
I'm
happy
to
share
that
too.
A
One
was
the
possibility
of
keeping
context
when
interacting
with
these
objects.
So
in
the
example
I
explored
here,
we
had
maybe
a
to-do
list.
You
wanted
to
perhaps
select
an
item
from
the
to-do
list
and
rather
than
leaving
that
context
and
going
to
a
different
page,
you
could
have
kind
of
a
portion
of
that
planning
object,
come
out
from
the
side
and
present
the
information
there,
as
well
as
having
some
of
the
same
features
that
we
currently
have,
such
as
viewing
assignees
accessing
labels.
A
If
anybody
wants
to
to
see
it
kind
of
one-on-one,
but
that
was
part
of
it-
use
of
progressive
disclosure
to
simplify
the
ux
and
reduce
clutter
so
going
more
to
an
icon
approach
here,
which
I'm
personally
a
big
fan
of
having
labels
with
icons.
So
I
did
include
tooltips
as
part
of
this,
but
that's
hover
only
and
not
necessarily
mobile
friendly,
so
still
opportunities
there
to
dig
deeper,
but
again
just
discovery
and
exploration,
initially
helping
users
to
establish
a
single
source
of
truth.
A
So
this
was
maybe
taking
something
that
we're
currently
doing
in
the
handbook
and
providing
the
ability
for
someone
to
maybe
select
a
portion
of
text
and
then
quickly
choose
to
add
it
to
the
description,
and
maybe
in
the
description
there
would
be
something
to
kind
of
visually
denote
it
as
being.
A
This
was
added
from
a
comment
so
again,
some
of
that
kind
of
high
level
exploration,
as
well
as
the
detail
view,
maybe
exploring
some
ways
to
have
a
side-by-side
layout,
so
maybe
having
the
title
and
some
of
the
key
meta
information,
as
well
as
the
description
on
one
side
with
comments
on
the
other
side.
A
So
you
could
see
both
at
all
times
together
and
not
necessarily
have
to
do
all
of
that
up
and
down
scrolling,
possibly
also
even
having
this
kind
of
bar
in
the
middle,
be
something
like
in
storybook
where
you
can
drag
it
left
to
right,
so
that
if
you
have
just
a
small
description
but
a
lot
of
dialogue,
you
can
kind
of
expand
that
to
see
more
of
that
information
and
and
have
that
kind
of
control.
So
those
were
some
of
the
things
that
we
started
to
explore,
and
this
is
just
a
portion
of
it.
A
For
this
view,
we
ended
up
narrowing
it
down
to
some
things
that
we
wanted
to
initially
test.
So
on
usertesting.com,
I
created
a
prototype
of
the
to-do
list
view
and
we
decided,
after
a
lot
of
discussion
on
presenting
a
modal
approach
as
well
as
a
side
part
approach
here
for
accessing
this,
and
then
also
this
sort
of
full
screen
view.
A
So
I
tested
with
seven
participants
and
had
them
kind
of
describe
what
they
see
with
each
interaction,
the
way
that
they
would
access.
This
would
be
through
the
ellipsis
menu
in
the
top
right,
so
they,
if
they
are
in
the
side
panel
view
they
can
switch
to
the
modal
view.
A
If
they
are
in
the
modal
view,
they
can
switch
to
the
side
panel
view
they
can
switch
to
full
screen
from
either
and
then,
if
they
are
in
the
kind
of
full
detail
view,
they
wouldn't
have
the
option
to
switch
necessarily
to
modal
or
sidebar,
because
obviously
we
would
need
to
understand
the
context
of
where
they
were
in
order
for
that
to
work.
So
that
was
some
of
the
initial
testing
that
was
done
as
well
as
getting
feedback
on
kind
of
this,
this
layout
showing
side
by
side
as
well.
A
So
our
let's
see
our
users
were
pretty
evenly
divided
on
which
approach
they
liked,
which
I
thought
was
a
good
thing,
because
that
helped
us
to
understand
that
people
find
value
in
each
approach
for
different
reasons,
and
I
think
context
also
matters.
A
lot
of
the
users
were
excited.
I'm
sorry,
they
exited
the
issue.
A
So
if
I
asked
them
in
the
instructions
to
show
me
a
couple
of
different
ways
that
they
might
want
to
view
this
particular
layout,
they
had
a
tendency
to
exit
the
modal
or
sidebar
view
and
go
back
to
the
main
to-do
view
as
if
they
were
expecting
kind
of
a
global
setting
and
one
person
actually
verbalized.
I
was
expecting
something
maybe
on
this
main
page,
that
kind
of
defined
a
layout
view
for
all
of
these
objects
across
the
board
or
even
potentially,
I
think
one
person
also
expressed
depending
on
the
context.
A
So,
if
you're
in
a
board
view,
I
might
expect
to
set
the
view
for
all
issues,
for
example
to
be
in
a
sidebar.
But
if
I'm
on
iterations
or
in
a
list
view,
perhaps
I
want
them
to
always
show
in
a
modal
view,
so
that
was
something
that
we
got
some
good
feedback
on
most
expressed,
that
the
information
felt
a
little
scrunched
in
the
sidebar
and
in
the
modal
view,
so
there's
further
opportunity
to
explore.
A
What's
going
to
be
most
valuable
in
those
views
and
why
that
is,
does
it
really
help
solve
the
problem
of
context?
Switching
as
well,
and
then
a
lot
of
users
interestingly,
tried
to
click
the
open
status,
thinking
that
it
was
a
button
and
verbalize?
Oh,
I
assume,
if
I
click
this
open,
then
it's
going
to
open
a
new
issue,
so
they
misinterpreted
that
which
I
know
is
a
separate
discussion
that
we've
been
talking
about
as
far
as
that
status
and
its
design.
A
A
What
I
should
have
done,
looking
back
was
step
up
when
I
saw
the
scope
growing
and
pushed
back,
and
I
didn't
necessarily
do
that,
because
we
had
a
lot
of
great
ideas
coming
in
and
and
everyone
felt
that
the
ideas
that
were
being
discussed
were
going
to
be
very
important
for
mvc,
but
the
scope
was
just
getting
bigger
and
bigger.
So
this
was
a
great
lesson
for
me
to
learn.
A
This
was
also
a
culmination
of
a
few
big
ideas,
so
we
started
big
from
this,
the
start
and
knowing
that
we
focused
on
high-level
discovery
and
not
necessarily
defining
nbc
initially,
but
time
passes
and
ideas
keep
growing
and
at
some
point
we
have
to
to
focus
on
something
that's
going
to
provide
value
so
establishing
a
north
star
vision
early
on
was
important
than
establishing
smaller.
A
How
might
we
statements
were
important
but
making
sure
that
those
were
measurable,
that
they
were
clearly
articulated
that
they
were
agreed
upon
was
also
really
important
to
to
do,
and
I
think
there
were
some
opportunities
there.
The
sync
meetings
and
demos
that
we
conducted
were
helpful
to
keep
us
on
track,
but
doing
that.
In
addition
to
async
and
the
issues
was
a
bit
harder
because
then
we
were
kind
of
doing
double
and
triple
effort
in
terms
of
documentation,
so
that
was
unfortunately
a
bit
lost.
While
we
had
it
recorded
and
documented
in
agendas.
A
It
was
not
necessarily
always
in
the
issues,
and
that
was
a
missed
opportunity.
Staying
focused
again
on
the
north
star
vision
and
smaller
statements
would
have
helped
us
to
stay
on
track
across
the
board
and
help
us
to.
You
know
ensure
that
we
were
focused
on
the
right
things.
As
priorities
changed
and
ideas
were
shaped,
we
should
have
acknowledged
big
ideas
and
tabled
them.
A
So
said:
yes,
that's
a
great
idea,
but
let's
create
a
follow-up
issue
and
then
explore
that
later,
rather
than
trying
to
explore
them
all
up
front
and
again,
I
think
setting
a
good
goal
would
have
been
helpful
for
that
too.
Write
down
the
agreed-upon
scope,
so
not
just
defining
it
and
agreeing
on
it
in
the
conversations,
but
also
putting
it
in
an
issue
and
saying
here's
what
we
have
defined,
which
we
did
in
some
cases,
but
I
think
there
was
still
opportunity
to
further
clarify
that,
as
with
austin,
better
cross-stage
collaboration
was
also
important.
A
There
was
a
concern
about
having
too
many
cooks
in
the
kitchen
too
early
on
before
we
really
had
some
semblance
of
the
scope,
so
we
didn't
pull
more
folks
in
sooner.
I
did
pull
a
couple
of
folks
in,
but
I
learned
that
it's
less
about
having
too
many
voices
too
soon
and
more
about
managing
that
feedback
and
managing
the
steps
associated
with
it,
which
is
partly
why
I
chose
to
share
this
today
to
go
ahead
and
get
it
out
there.
A
So
that's
something
that
alexis
and
I
will
be
working
on
together,
we'll
be
exploring
possibilities
of
establishing
and
servicing
surfacing
related
items,
not
only
from
the
perspective
of
related
and
blockers,
but
also
child
elements
for
planning
objects
and
then
looking
into
customization
for
these
items
again
still
very
big.
A
But
it's
it's
been
a
valuable
learning
experience
and
I
don't
think
the
work
was
throw
away
work
by
any
means,
but
I
do
think
that
there
were
a
lot
of
good
opportunities
that
I
understood
as
a
result
of
all
of
this,
to
improve
my
own
process
going
forward.
So
that
was
all
that
I
had
today
again.
I've
got
links
in
the
agenda.
If
you
have
anything
that
you
would
like
to
to
comment
on,
please
feel
free
to
do
so.
I
welcome
the
feedback.
B
Awesome,
thank
you.
Holly,
there's,
a
good
read
me
worth
or
read
only
that's
worth
reading.
Only
in
the
meantime,
christy
you
had
a
question.
A
A
C
D
A
A
Well,
honestly,
I
think
where,
where
I
feel
we
could
pursue
is
having
both
as
an
option
and
letting
the
user
choose,
which
one
is
going
to
be
more
useful
and
again,
I
think
there's
more
opportunity
to
validate
that.
A
Just
the
the
feedback
that
I
got
from
recent
testing,
though,
was
that
some
people
prefer
the
modal
view,
because
they
want
to
not
leave
their
current
context,
but
also
not
have
the
noise
of
the
page
around
them,
and
others
say
I
need
to
be
able
to
see
like
in
a
board
setting
the
information.
That's
on
the
page,
in
addition
to
the
information
that's
in
the
issue,
so
I
kind
of
like
the
thought
of
giving
them
the
choice
to
toggle
between
the
two,
but
in
terms
of
where
we
would
start.
A
C
D
Yes,
thanks
for
this
great
overview,
holly
really
good
to
see
your
process,
you
pretty
much
responded.
My
my
previous
question,
my
question
with
crisis,
but
yeah
beyond
usability
testing.
How?
How
do
you
see
yourself
prioritizing
between
these
different
options
for
users
that
might
prefer
one
option
or
or
maybe
their
use
case
means?
Another
option
is
different
from
them,
because
I
see
we,
we
we
frequently
bump
into
customization
as
a
topic
here
in
gitlab,
because
our
interface
is
so
so
heavy
and
so
broad.
A
When
you
talk
about
the
the
sort
of
options
for
the
users,
are
you
specifically
referring
to
the
modal
view
versus
the
side
panel
view
or
some
of
the
other
points
that
were
addressed.
D
Mostly
these
two,
but
but
another
thing
that
comes
to
mind,
for
example,
for
truncating.
The
description
right
like
at
which
point
do,
you
think,
is
more
relevant
to
turn
create
the
description
is
that
they
used
an
option
for
the
user.
Was
that
that's
a
choice
that
we
would
make
for
them.
A
The
the
default
states
yeah,
if
that's
a
yeah,
that's
a
great
question,
so
I
I
think
that
one,
the
usertesting.com
that
I
did
was
with
non-users,
but
people
who
still
fell
into
our
target
persona
group,
I
think,
there's
still
value
and
I
am
planning
to
pursue
getting
feedback
from
people
internally,
as
well
as
preferably
customers.
A
People
who
are
familiar
with
our
issue,
layouts
and
understand
kind
of
what
each
of
the
pieces
mean.
I
think
that
will
also
be
insightful
to
help
us
to
know
which
one
might
be
the
preferred
approach.
I
I
think
that
the
preferred
approach,
though,
is
going
to
depend
on
context.
That's
a
hypothesis!
I
have
that
I
would
like
to
validate,
because
I
think
that
there's
going
to
be
a
difference
in
how
people
want
to
interact
with
these
things
in
a
board
setting
versus
in
a
list
setting,
for
example,
that's
a
theory
that
I
have.
A
I
would
say,
though,
that
in
order
to
be
less
less
intrusive,
I
think
it
would
be
better
to
offer
the
side
panel
view
initially,
so
that
the
user
can
choose
to
view
it
alongside
the
other
content
or
not.
It's
also
a
pattern
that
I
have
seen
used
more
so
with
our
competitors,
so
I
did
look
at
several
different
competitors
and
a
lot
of
them
do
this
side
panel
approach.
So
it's
familiar
to
the
users,
it's
something
that
I
think
a
lot
of
them
already
have
an
expectation
for
in
terms
of
interaction.