►
From YouTube: UX Showcase - Creating Tasks
Description
Manage & Plan
UX Showcase - Dec. 1st, 2021
B
Thank
you
so
much
so
hello,
everyone,
my
name
is
holly
reynolds,
I'm
the
senior
product
designer
here
at
get
lab
on
the
plan
team.
In
the
project
management
group,
you
may
have
gotten
a
sense
from
alexis's
presentation
that
work
items
is
a
very
big
project
with
a
lot
of
moving
parts,
and
our
groups
within
plan
are
working
together
to
ensure
that
we
create
one
one
deliverable
that
will
make
sense
to
the
user,
but
I'll
talk
in
a
moment
kind
of
about
the
the
parts
that
they're
working
on
versus
the
parts
that
we're
working
on.
B
So
today,
I'm
talking
about
creating
tasks,
and
I
just
wanted
to
give
a
little
bit
of
quick
background.
In
case
you
don't
recall,
I've
talked
about
work
items
before
at
showcases,
but
just
in
case
you
don't
recall
the
details
of
it.
B
The
value
of
work
items
are
that
we
believe
they
will
give
users
the
ability
to
customize
their
work
items
the
documentation
of
their
work,
such
as
issue
issues
and
features
and
incidents
to
best
suit
their
business.
This
includes
how
those
work
items
are
categorized
related
to
one
another
and
the
option
to
even
add
or
remove
functionality
or
widgets
for
the
type
of
work
item
that
they've
defined.
B
B
The
second
is
related
to
parker
needing
the
ability
to
easily
create
a
work
item
that
they
can
customize
the
functionality
for,
in
order
to
have
a
simplified
experience
through
only
being
exposed
to
functionality.
That's
essential
for
that
work,
item
type
and
again,
there's
more
to
work
items
than
just
these
things,
but
just
to
kind
of
touch
on
a
couple
of
key
points.
So
eventually
we
want
to
give
users
the
ability
to
choose
only
what
they
want
to
see
in
terms
of
widgets
and
metadata
for
work
item
objects.
B
We
believe
that
this
is
going
to
simplify
the
user
experience
and
ensure
the
most
relevant
information
is
visible
for
the
users,
depending
on
the
type
of
work
item
that
they've
selected.
So
as
nick
noted
earlier,
one
of
the
most
common
complaints
in
sus
is
that
we
have
a
really
busy
ui.
Another
is
that
it
feels
to
some
users
as
if
it
were
targeting
those
with
highly
technical
backgrounds.
B
I
watched
an
interview
with
a
product
manager
recently
who
had
a
very
telling
statement
that
they
felt
that
gitlab
was
a
tool
that
they
could
use.
That
was
made
for
someone
else,
so
they
felt
that
they
could
use
it.
They
had
to
use
it,
but
that
it
wasn't
necessarily
made
for
them.
It
felt
difficult
for
them
in
some
ways,
so
we're
hoping
that
this
will
also
help
them
with
that
experience.
B
So
for
nvc
of
work
items,
we're
moving
forward
with
the
first
work
item
type
of
task.
So
what
is
the
value
of
a
task?
Well,
users
need
to
have
the
ability
to
break
down
issues
into
smaller
chunks
of
work
that
can
be
assigned
to
individuals
and
allow
for
better
insights
and
accountability
at
the
member
level.
B
So,
by
providing
tasks,
users
can
easily
assign
multiple
people
to
pieces
of
work
within
a
single
issue
and
eventually
apply
weights
to
those
we've
actually
had
teams
internally,
and
I
believe
jackie's
team
was
one
of
them.
So
I
would
love
to
speak
with
you
all
about
this,
but
we've
had
teams
internally,
who
want
to
provide
a
ux
weight,
for
example,
and
in
some
cases
people
have
created
a
separate
issue:
that's
empty
and
just
has
a
weight
applied
to
it.
Just
to
be
able
to
accomplish
this
and
be
able
to
track
this.
B
So
tasks
should
eventually
eliminate
the
need
to
have
to
do
that
sort
of
odd
work
around
and,
as
you
can
see
there,
it's
a
very
popular
idea.
Users
really
really
want
this
particular
feature
and
it's
been
requested
several
times.
So
the
business
value
of
work
items
again
large
picture
just
to
keep
it
simple
for
time.
Time
constraints
we
want
to
increase
the
growth
rates
for
plan.
B
This
is
one
piece
of
the
puzzle
that
enables
us
to
be
able
to
compete
better
in
the
marketplace:
increase
retention
rates
for
plans
so
because
plan
features
will
be
able
to
grow
with
our
customers.
It'll
be
more
scalable,
it's
much
less
likely
that,
hopefully,
that
they
will
look
for
alternative
solutions
when
they
need
to
iterate
and
change
their
internal
processes,
and
then
also
it
helps
us
to
maybe
avoid
unnecessary
costs.
B
So
because
users
are
doing
this
sort
of
work
around
with
epics
and
issues,
we're
continuing
to
put
money
into
things
like
adding
assignees
to
epics
so
that
they
can
kind
of
build
on
that
workaround.
But
really
what
we
need
to
do
is
address
the
core
problem
and
not
necessarily
continue
to
build
on
a
band-aid
approach,
and
we
believe
again
that
tasks
will
help
with
that
and
therefore
reduce
some
of
these
unnecessary
costs.
So
I
want
to
just
really
quickly
show
a
couple
of
examples
be
mindful
of
time,
so
I'm
going
to
rush
through
this.
B
But
if
you
do
have
any
questions
and
want
me
to
go
deeper,
please
let
me
know
I
have
also
included
links
to
the
figma
files
for
work
items
and
tasks.
Tasks
is
newer
in
that
we
initially
were
going
down
the
path
of
focusing
on
creating
a
feature,
and
we
have
changed
that
to
a
task
which
is
really
kind
of
a
different
use
case.
So
the
focus
has
shifted
a
little
bit
and
I'm
still
kind
of
in
the
earlier
stages.
B
Now
of
doing
some
of
the
research
for
that,
but
the
thought
is
that
for
the
mvc
of
tasks
we
would
give
users
the
ability
to
convert
a
checklist
item
which
is
known
currently
as
a
task.
Yes,
I
have
concerns
about
the
terminology
there,
and
one
of
my
goals
in
the
research
is
to
understand
what
users
mental
models
are
of
those
things,
but
you've
got
a
current
concept
of
a
checklist
in
markdown
like
in
a
description
or
in
a
comment
field
within
the
product.
B
So
I
explored
several
ways
to
maybe
give
users
the
ability
to
interact
with
one
of
those
tasks
and
quickly
convert
them
to
this
official
task
object.
I
didn't
love
this
idea,
but
I
like
to
explore
even
sometimes
the
ideas.
I
don't
love
just
to
be
sure
that
I
kind
of
invalidate
them
as
a
possibility
in
my
own
mind,
so
in
this
case
having
an
explicit
make
task
button
that
displays
when
you
hover
over
one
of
these
items,
that
would
push
the
content.
B
I
don't
like
the
bounciness
that
would
happen
there,
so
I
went
ahead
and
skipped
that
one
another
is
to
have
maybe
a
make
task
button
that
displays
at
the
end.
That
begs
the
question
of:
does
it
consistently
display
at
the
end
of
that
section,
or
does
it
need
to
display
at
the
end
of
the
line,
in
which
case
there's
inconsistency
in
the
ui
and
the
interaction
there?
So
probably,
what
I
would
prefer
to
do
in
that
case
is
make
it
consistent,
regardless
of
the
length
of
the
content
of
that
checklist
item.
B
Another
is
an
option
to
just
have
an
icon,
and
when
you
hover,
you
have
the
ability
to
convert
to
task.
This
is
very
similar
to
one
of
our
competitors
and
what
they're
doing
so,
it
would
have
a
sense
of
familiarity
and
hopefully,
thereby
make
it
a
bit
easier
to
learn
more
quickly
for
people
that
are
coming
from
that
competitor
and
then
another
option
here
is
providing
an
ellipsis
menu.
This,
I
think,
is
going
to
be
more
scalable,
we'll
be
able
to
add
more
items
into
this
eventually.
B
I
don't
believe
this
remove
option
here
is
necessarily
in
vc,
but
giving
the
ability
to
convert
one
of
these
items
to
an
actual
object
that
can
be
tracked.
That
can
have
a
signees
that
can
have
weights
applied
to
it.
That's
what
we're
looking
to
accomplish
by
having
this
convert
to
task
option
and
then,
lastly,
having
this
option
on
the
left.
B
So
I
had
a
great
conversation
with
mike
nichols
about
this
recently
and
we
agreed
that
that
people
have
a
tendency
to
put
these
items
on
the
right,
but
it
does
create
kind
of
an
odd
sense
in
terms
of
the
the
interaction
because
you
either
have
to
ask
the
question
of.
Do
we
align
it
all
here,
in
which
case
there's
a
large
gap
between
the
checklist
item
and
the
button,
or
do
we
put
them
at
the
end
of
the
line?
B
In
which
case
you
know,
there's
kind
of
a
bounce,
and
it
makes
it
a
little
harder
for
the
user
to
know
where
to
find
those
things.
So
an
alternative
was
maybe
putting
the
ellipsis
at
the
start
of
the
line
on
the
left,
and
this
drag
and
drop
is
not
in
dc.
But
I
wanted
to
include
it
here
just
to
kind
of
see
how
those
two
pieces
may
look
together,
and
in
that
case
it
would
always
be
present
on
hover
always
in
this
particular
location.
B
B
First,
I
created
a
couple
of
user
hypotheses
based
on
some
conversations
with
a
pm
recently
that
theoretically
and
I've
seen
this
also
from
user
feedback,
that
people
want
the
ability
to
have
a
bunch
of
tasks
quickly
documented
and
then
be
able
to
eventually
convert
those
two
issues
when
the
time
is
right
to
do
so,
but
they
don't
necessarily
want
to
create
a
formal
issue
for
them.
B
Yet
another
option
is
that
people
again
want
the
ability
to
create
weights
and
add
weights
and
assignees
to
things,
but
maybe
they're,
just
doing
high
level
planning
right
now,
they're
not
ready
to
get
that
granular
yet
so
this
gives
them
the
ability
to
sort
of
create
a
placeholder
and
then
eventually
they'll
be
able
to
convert
those
tasks
to
an
issue
if
they
choose
to
some
additional
benefits
of
going
with.
This
approach
are
to
reduce
implementation
complexity
and
therefore,
hopefully
get
to
delivery
faster
and
to
reduce
the
impact
on
the
existing
user
flows
with
issue
tracking.
B
B
I
won't
go
through
these
in
depth,
but
you
can
see
some
of
those
options
include
showing
the
status
of
the
task,
the
title,
with
a
link
to
that
task,
as
well
as
the
fact
that
it
is
a
task
eventually,
you
may
see
instead
of
just
tasks
listed
here,
you
might
see
incident
you
might
see
bug
or
some
of
the
other
work
item
types
that
we
would
have
included
so
for
mbc.
The
thought
is
initially
that
one
of
these
tasks
when
something
has
been
converted
to
a
task,
it
would
show
as
a
related
item.
B
Eventually
it
will
not
be.
It
will
have
kind
of
its
own
separate
thing
from
what
I
understand
this
is
not
proposed.
Design
product
planning
is
going
to
be
handling
this.
I
only
include
it
here
just
to
kind
of
help
with
like
a
big
picture
concept
of
how
all
of
this
might
fit
together.
So
just
know
that
this
is
not
proposed
design.
This
is
just
me
kind
of
saying,
here's
kind
of
how
some
of
these
things
may
fit
into
the
current
issue
view
and
then
we're
also
exploring
again
with
work
items.
B
If
you've
been
following
this
at
all.
You
know:
we've
talked
about
going
mobile.
First,
we've
talked
about
ensuring
that
users
don't
lose
context
by
offering
this
information
in
a
side
panel
or
in
a
modal.
I
prefer
the
side
panel
approach
so
that
you
can
still
see
what's
happening
in
the
issue,
particularly
for
tasks,
because
they
will
eventually
be
kind
of
a
child
element
of
an
issue,
and
so
the
thought
was
if
they
click
from.
B
Maybe
this
related
items
list,
then
the
task
information
populates
here
there
are
some
questions
still
outstanding
surrounding
how
the
surface
is
in
the
ui.
But
let
me
go
ahead
and
wrap
up
because
we're
running
out
of
time
so
for
the
mvc
there's
goals
that
I
have
in
terms
of
research.
The
top
two
goals
are
to
have
better
understanding
of
existing
user
knowledge
and
experience,
as
well
as
to
test
and
validate
some
of
the
proposed
solutions.
So
I
have
questions
surrounding
mental
models.
B
Users
have
about
the
current
concept
of
tasks
as
well
as
mental
models
that
users
have
surrounding
tasks
versus
issues,
because
they
can
conceptually
be
kind
of
similar.
So
I
want
to
understand
that
we
also
have
questions
about
the
prefixes.
Do
we
use
the
hashtag
like
we
do
with
issues?
My
thought
is
no,
but
I
want
to
test
this
and
get
insights
on
it
as
well
as
the
differences
in
terms
of
the
detailed
view,
people
are
going
to
see
different
things
when
they
access
these.
B
So
how
does
that
impact
the
experience
and
the
opportunities
with
the
existing
solutions
as
well,
and
then
testing
some
of
the
proposed
solutions
so
validating
the
solutions
that
have
been
outlined
so
far
and
getting
feedback
on
those?
We
do
have
an
initial
road
map.
B
Adding
weight
is
going
to
be
one
of
the
first
things,
because
this
is
one
of
the
most
popular
reasons
why
users
want
tasks,
is
to
be
able
to
assign
a
weight
and
be
able
to
understand
who
is
working
on
what,
in
terms
of
an
issue
having
multiple
people
being
able
to
clarify
the
specific
parts
of
the
issue
that
those
specific
people
are
working
on
and
break
that
down
a
little
bit
further,
so
wait
will
be
one
of
the
first
things
and
I'll.
B
A
Great
showcase,
thank
you
so
much
holly,
we
do
have
a
question,
but
we
can
kick
it
to
async.
I
just
want
to
plug
two
different
things.
One
ask
your
questions
continue
to
ask
questions
in
the
agenda.
Our
designers
and
tech
writer
we'll
be
answering
them.
Please
continue
that
conversation
also
remember.
We
have
two
async
showcases.
Please
take
the
time
to
jump
in
on
those
as
well
from
daniel
and
from
austin
as
well,
and
thank
you
so
much.