►
From YouTube: UX Showcase — Simplifying Resolvable Comments
A
Can
you
all
see
my
screen
excellent?
Thank
you
so
much
so
I'm
holly
reynolds,
I
am
senior
product
designer
on
the
plan
team
specifically
focused
on
the
project
management
group
and
today
I'm
going
to
share
with
you
about
a
recent
issue.
I
worked
on
collaborating
collaborating
heavily
with
the
create
group
regarding
simplifying
resolvable
comments,
so
I
want
to
actually
kick
this
off
initially
by
saying
this.
A
A
So
when
doing
reviews
on
mrs
the
user
expressed
that
their
main
use
case
was
to
create
a
discussion,
but
when
creating
a
discussion
in
mrs,
we
have
a
dual
purpose
button,
which
is
shown
here
in
this
example
for
creating
a
comment
or
starting
a
thread.
The
default
state
is
to
create
a
single
comment
so
because
the
user
wanted
to
create
a
new
discussion
or
thread
more
often
than
a
single
comment.
A
They
were
asking
if
we
could
just
flip
the
default
state
of
that
button
to
start
thread
as
the
current
default
state
caused
them
to
frequently
find
themselves
accidentally,
creating
the
wrong
type
of
comment
for
their
need
and
having
to
delete
that
and
start
over
so
by
default.
It
would
have
this
comment
single
comment.
Option
selected
people
would
accidentally
just
hit
that
when
creating
a
new
comment,
but
what
they
really
wanted
was
the
ability
to
create
a
thread.
A
A
The
reason
that
the
user
wanted
this
button
to
default
to
starting
a
thread
is
because
of
the
option
to
resolve
that
discussion
as
part
of
that
review
process.
They
don't
have
that
option
with
a
single
single
comment.
They
have
to
actually
create
a
thread
to
have
that
resolvable
option,
so
it
wasn't
going
to
be
quite
as
easy
as
just
you
know,
flipping
this
button,
because
we
had
all
of
these
other
processes
to
consider
so.
Internal
discussions
revealed
that
the
dual
purpose
button
was
confusing
to
many
users.
A
Some
didn't
understand
why
we
had
both
options,
particularly
engineers,
who
primarily
just
wanted
to
have
a
way
to
start
a
discussion
that
could
be
resolvable
also
in
other
cases,
they
were
creating
a
comment,
whether
a
threat
or
not.
So
the
verbiage
was
kind
of
confusing
too.
They
thought
either
way.
I'm
making
a
comment.
So
you
know
why
do
I
necessarily
have
to
have
two
different
options?
A
There
needs
to
be
a
better
way
to
do
this,
so
we
realized
we
had
an
opportunity
to
further
simplify
the
experience
for
the
users,
so
pedro
gabe,
daniel
grusso
and
a
handful
of
wider
gitlab
community
users-
and
I
heavily
discussed
this.
If
you
go
to
the
original
issue,
which
has
now
been
converted
to
an
epic
you'll,
see
a
lot
of
collaboration
about
this
particular
problem
and
we
talked
about
removing
the
start
thread
option
and
then
defaulting
to
comment
because
they
are
creating
a
comment
either
way
to
simplify
the
flow.
A
But
users
would
still
need
a
way
to
make
those
items
resolvable
that
that
critical
piece
of
functionality,
and
also
sometimes
they
did,
in
fact
just
want
the
ability
to
just
start
a
single
top
level
comment,
but
we
were
proposing
the
removal
of
this
start
thread
option.
So
we
wanted
to
be
sure
that
we
didn't
lose
discoverability
of
having
the
option
to
start
the
thread,
so
we
decided
to
potentially
offer
a
reply
box
on
all
top
level
comments
and
I'll
show
an
example
of
that
here
shortly.
A
So
one
of
the
reasons
we
wanted
to
prioritize
this
was
that
it
was
a
very
popular
issue.
You
can
see
some
of
the
comments
here,
I'm
not
going
to
go
through
all
of
them,
but
people
were
just
expressing
a
lot
of
frustration,
even
though
it
seemed
like
a
really
small
thing.
This
problem
was
causing
a
lot
of
regular
friction
for
engineers
and
code
reviewers,
primarily
when
conducting
their
day-to-day
tasks.
A
A
We
talked
about
removing
the
start
thread
button
altogether
and
providing
a
make
resolvable
checkbox
option
for
top
level
comments
considered
whether
or
not
all
comments
should
be
resolvable
or
just
top
level
comments
which,
interestingly,
after
doing
some
internal
research
users
seemed
a
bit
split
on
this,
some
felt
that
all
comments
should
be
allowable
to
be
made
resolvable,
but
some
felt
that
just
top
level
comments
needed
to
qualify.
As
that,
we
also
talked
about
showing
the
reply
box
on
all
top
level
comments
again
to
help
with
discoverability.
A
If
we're
removing
that
start
thread
option,
how
can
we
ensure
that
users
still
realize
that
they
can
start
a
thread?
There
is
a
little
chat,
icon,
of
course,
and
that
isn't
changing
at
all,
but
we
were
concerned
that
maybe
we
would
lose
some
discoverability,
so
we
wanted
to
explore
other
options
there
and
then
simplifying
the
ui
further
by
maybe
removing
some
redundancy
specifically
surrounding
the
author
avatars.
A
So
again,
this
was
some
of
the
discussion
and
I'll
talk
about
how
we
address
some
of
these
kind
of
side
points
in
just
a
moment.
But
to
that
point
there
is
an
issue
I
believe
out
there,
where
someone
had
said
you
know
I'm
kind
of
tired
of
seeing
myself
every
time.
I
create
a
comment
or
every
time
I
reply.
I
feel
like
I
see
my
own
picture
so
many
times,
and
I
know
that
I'm
the
one
commenting
or
the
one
replying.
So
why
do
I
need
to
see
my
own
avatar?
A
So
this
was
something
else,
as
we
were
kind
of
addressing
this
comment
box
issue
that
we
talked
about,
maybe
looking
to
improve
on
and
then,
of
course,
we
also
wanted
to
consider
how
these
decisions
could
affect
issues
and
other
issuable
objects
that
used
commenting
within
the
product.
So
again,
there
were
a
lot
of
iterations
surrounding
the
design.
A
If
you
go
to
the
original
issue
which
I've
provided
a
link
for
here,
you
can
see
design
management
has
several
different
ideas,
including
some
of
the
ones
I've
just
touched
on
and
and
how
we
kind
of
iterated
and
collaborated
on
those.
We
talked
again
about
replacing
the
existing
resolve
thread
with
a
make
resolvable.
So
currently
you
can
do
resolve
thread
and
it
is
a
check
box
that
falls
below
the
comment
box
itself.
We
talked
about
maybe
taking
advantage
of
that
positioning
and
having
make
resolvable
there,
but
then
there
was
the
question
of.
A
If
you
choose
to
make
it
resolvable,
you
know:
where
do
you
then
show
the
resolve
thread?
Do
you
swap
the
two?
Do
you
add
a
separate
check
box
off
to
the
side,
so
we
kind
of
went
through
some
iterations
surrounding
that
discussion
again
also
talked
about
separate
buttons.
You
know
for
starting
threads
and
comments
and
how
to
address
that
and
internally
I
conducted
five
just
quick
interviews
with
engineers
to
kind
of
validate
the
primary
expectations
and
needs
of
start
thread
versus
comment.
A
Many
expressed
again
a
feeling
that
the
dual
purpose
button
was
unnecessary.
Several
echoed
the
issue
that
the
author's
pains
or
of
the
author's
pains
rather
of
kind
of
accidentally
hitting
the
wrong
button
because
of
the
default
state
there
and
again
they
were
divided
on.
If
all
comments
should
be
resolvable
in
threads,
as
opposed
to
just
that
top
level.
So
we
got
some
really
good
insights
from
just
talking
with
folks
individually
as
to
kind
of
where
our
starting
point
needed
to
be
and
what
the
larger
problems
were
that
we
needed
to
address
there.
A
So
there
were
a
couple
of
things
that
we
were
striving
to
accomplish
in
terms
of
use
cases,
we
wanted
to
improve
the
overall
user
experience
by
reducing
the
opportunity
for
user
slips,
which
nielsen's
heuristics
identifies.
As
you
know,
an
unconscious
error
caused
by
inattention,
so
just
people
kind
of
doing
that
quick
workflow
every
day
and
accidentally
making
that
wrong
selection.
We
wanted
to
reduce
that
opportunity,
reduce
friction
in
the
code
review
process
through
a
more
clearly
defined
label
in
terms
of
the
button
labels
start
thread
versus
comment
versus
reply.
A
So
for
the
nbc.
We
converted
this
to
an
epic
and
spawned
off
three
separate
initial
issues
as
kind
of
starting
points.
The
first
was
to
have
a
make
resolvable
check
box
option
when
creating
a
new
comment
to
the
bottom
of
the
comment
box
and
when
editing
an
existing
top-level
comment.
I'll
show
an
example
of
that
in
just
a
moment,
as
well
as
to
change
that
dual
purpose.
A
So
just
a
few
examples
here
of
what
those
look
like
in
this
case,
we've
got
just
kind
of
a
new
comment
box.
It
doesn't
have
the
avatar
off
to
the
side
same
with
the
reply
box
over
here
again,
we
would
just
remove
those
avatars.
We
also
have
this
make
resolvable
check
box
here.
This,
interestingly,
spawned
off
again
a
separate
conversation
about
the
structure
of
the
comment
box
and
whether
or
not
we
should
perhaps
consider
moving
attach
file,
perhaps
up
into
this
top
level
kind
of
tools.
A
A
I
have
to
admit,
I
don't
necessarily
love
the
placement
of
it
here,
because
I
think
that
it
kind
of
feels
kind
of
smooshed
in
there
at
the
moment,
but
we
have
a
lot
of
discussion
around
it
and
it
seems
like
this
is
kind
of
the
best
place
to
start
to
get
feedback
on
the
value
of
this
particular
approach
and
then
explore
other
ways
and
separate
issues
to
kind
of
clean
up
this.
This
part
of
the
ui.
We
also
now
have
just
the
single
comment
box,
as
well
as
opposed
to
that
dual
comment
box.
A
You
know,
without
necessarily
having
to
go
into
an
edit
view
for
those
comments.
So
for
the
future.
Again,
we
talked
about
four
issues:
how
we
can
again
consider
the
dual
purpose
button.
In
that
particular
case,
we
find
that
it
doesn't
necessarily
add
nearly
the
value
in
the
case
of
issues,
because
we
don't
have
resolvable
comments
as
it
does
for
merge
requests.
A
However,
we
do
want
to
talk
about
resolvable
comments
for
issues
that
is
a
future
consideration,
so
we
we
have
started
thinking
through
how
we
want
to
approach
this
in
that
particular
scenario
as
well,
and
then
revisiting
again.
The
design
of
the
comments
section,
considering
whether
or
not
we
should
move
attach
file
to
a
different
place,
whether
or
not
there's
a
better
place
for
this
make
resolvable
concept,
and
if
we
can
move
that
markdown
and
quick
actions
line
to
another
place
that
might
make
a
little
bit
more
sense
in
terms
of
not
interrupting
the
user's
flow.
B
So
let
me
start
by
saying:
I
have
also
always
wondered
about
the
dual
purpose
comment
button.
It
never
made
sense
to
me,
so
I'm
excited
to
see
you
working
on
this.
This
is
an
excellent
example
of
a
feature
enhancement
where
we
have
something
in
place.
We're
looking
at
we're
going.
The
experience
of
this
just
isn't
what
it
needs
to
be.
You've
talked
a
lot
about
decluttering
and
in
the
context
of
merge
requests,
that's
a
really
top
priority
for
us,
because
we
hear
our
users
saying
you
got
to
declutter
these
things.
So
good
focus.
A
I
would
say
that
if
it
stays
in
plans
hands
yes,
I
think
we
definitely
should
if
it
goes
into
create,
I'm
not
sure
how
they
want
to
handle
that.
I
think
last
last
gabe-
and
I
talked
we
were
going
to
try
and
see
if
create,
would
want
to
take
the
actual
engineering
portion
of
this
and
kind
of
build
out
these
options.
A
C
A
That
is
also
a
great
question,
and
that's
one
that
we
have
talked
about
a
lot
personally.
We
are
we're
not
yet
on
the
same
page,
I
think
as
to
what
the
problem
is
that
it
resolves.
I
I
personally
feel
that
resolvable
comments
should
be
something
that
is
part
of
an
approval
type
of
workflow,
and
we
don't
necessarily
have,
I
think,
always
a
need
for
an
approved
process
when
it
comes
to
issues.
Some
issues
can
just
be
an
idea
they
can
just
be.
A
You
know
a
collaboration
opportunity,
not
necessarily
something
that
I
think
needs
a
formal
review
and
approval
type
of
process.
So
I
think
that
there
needs
to
be
a
larger
discussion,
first
and
foremost
surrounding
whether
or
not
there's
value
in
that,
and
if
there
is
value
in
that,
then
I
think
that
there
could
be
a
true
value
in
having
this
resolvable
option
for
issues,
but
whether
or
not
that
currently
exists,
I
think
still
is
outstanding
as
far
as
questions
go.