►
Description
Scorecard issue: https://gitlab.com/gitlab-org/gitlab-design/-/issues/1676#note_674985741
A
A
A
This
is
it.
You
can
see
that
we
are
evaluating
how
the
user
might
actually
feel
which
stages
in
the
app
they're
going
through
mostly
screens.
These
are
the
steps,
what
they're
thinking
their
pain,
points
and
then
opportunities
for
us.
These
are
mostly
ideas
of
how
we
could
resolve
those
pain
points
and
just
notes
about
the
heuristic.
A
So,
let's
go
into
the
most
interesting
part,
this
journey,
which
is
the
screenshots
and
the
comments
user
thoughts.
Basically,
so
I
started
this
journey
right
on
the
project
overview
screen,
so
I
I
was
presented
with
okay.
You
created
this
project.
You
created
some
issues
for
it.
I
think
the
best
way
to
start
this
evaluation
was
on
the
project
page
and
here
the
user
might
be
thinking
right.
This
is
a
relatively
new
user.
A
They're,
probably
wondering
how
the
work
that
they
planned
for
the
mobile
app
can
be
completed
in
a
two-week
sprint
right.
How
can
they
create
something
that
would
guide
them
towards
shaping
this
two-week
sprint
and
evaluating
if
the
work
that
they
scheduled
for
it
is
actually
doable
in
such
a
period
or
not?
A
So?
Yes,
the
issues
were
already
created.
I,
as
a
new
user,
created
them
recently.
So
this
is
not
the
very
first
time
I'm
going
through
gitlab
and
I
already
applied
some
estimates
on
how
long
it
would
take
to
complete
the
work
on
these
issues.
So
the
user
here
might
be
thinking.
Okay,
these
are
all
the
issues.
A
I
have
the
estimates
I
don't
have.
I
don't
have
a
picture
of
how
long
all
the
estimates
together
will
take.
Is
it
more
than
four
two
weeks
or
two
weeks
be
enough?
These
are
the
types
of
questions
that
are
going
through
my
head
right
now,
but
just
based
on
my
estimates.
A
It
looks
like
there's
too
much,
because
if
I
do
a
quick
sum
of
the
estimates,
it
looks
like
there's
way
too
much
work
for
two
weeks
and
how
can
I
find
out
if
that's
actually
the
case
right,
and
so
I
navigated
to
an
issue
just
thinking.
How
can
I
group
these
issues
into
like
a
sprint
right
like
into
a
time
period
inside
gitlab
and
as
I
looked
around,
I
noticed
the
milestones
in
the
sidebar.
So,
okay,
I
thought
perhaps
the
milestones
is
the
way
to
do
it.
A
It
sounds
like
the
correct
word
sounds
like
a
feature
that
might
be
able
to
help
me
with
that.
So
as
I
clicked
to
assign
a
milestone,
I
noticed
this
drop
down
where
I
could
select
a
milestone,
but
I
don't
have
any
milestones
yet.
So
how
can
I
create
one
or
where
do
I
create
one,
because
it
looks
like
I
can't
create
one
on
this
page,
so
I
I
was
looking
around
on
the
screen.
Where
can
I
navigate
to
inside
gitlab
so
that
I
can
possibly
create
these
milestones?
A
To
be
honest,
it
didn't
take
me
long
because
I'm
quite
used
to
the
gitlab
interface,
but
I
assume
for
a
relatively
new
user.
It
could
take
a
while
for
them
to
notice.
Okay,
the
milestones
nav
item
is
actually
on
the
left
side
nav
after
the
issues,
submenu
is
already
open,
and
so
yes,
I
found
it.
I
clicked
it
and
I
planned
it
on
this
page,
which
is
an
empty
state
page.
A
I
was
a
bit
confused
by
some
of
the
ui
already
on
this
page,
for
example,
why
do
I
have
the
filter
option
and
the
sorting
option
if
there
are
no
milestones?
Why
do
I
have
these
tabs
there
and
then
the
the
empty
state
page
only
says
no
milestones
to
show
and
quite
nice
illustration,
but
as
a
relatively
new
user,
not
really
familiar
with
the
concept
of
milestones,
I'm
still
not
sure.
If
this
is
the
right
feature
for
me,
so
this
this
is
that's
going.
This
is
what's
going
through
my
mind
at
the
moment.
A
A
So,
okay,
I
need
to
put
in
a
title
I
need
to
put
in
a
start
date
a
due
date,
a
description,
and
here
I
started
wondering
you
know
having
my
new
user
hat
on.
Okay,
what
what's
the
right
way
to
do
it?
What's?
A
You
know
a
typical
title
that
should
be
used
for
this,
and
why
do
I
need
a
description?
It
wasn't
very
clear
to
me,
but
still
at
this
step
I
felt
reassured
because
at
least
I
learned
now,
okay,
the
milestones
feature
is
probably
the
one
that
will
help
me
here
and
okay.
So
then
I
started
populating
the
form.
A
I
came
up
with
a
naming
method
that
I
thought
was
okay
and
it
was
basically
the
the
year
the
number
of
the
month
and
sprint
one,
assuming
that
there
are
two
sprints
per
month.
One
right-
and
I
also
set
the
start
date
and
the
due
date
so
beginning
september,
beginning
of
the
september,
to
the
middle
of
september
and
for
description
still,
I
didn't
know
what
to
put
in
so
I
just
left
it
blank
leaving.
This
page
left
me
feeling
a
bit
unconfident,
you
know.
A
Could
there
be
like
some
guide
on?
What's
the
best
practice
for
naming
these
milestones
whatever
and
then
okay,
I
created
this
milestone
and
I
landed
on
this
page
and
just
you
know
the
first
thing
that
I
noticed
is
there's
so
much
going
on
on
this
screen.
I
felt
a
bit
overwhelmed.
A
I
mean
I'm
used
to
the
gitlab
interface,
I'm
used
to
the
gitlab
app,
but
I
still
felt
overwhelmed
landing
on
this
page.
So
I
assume
that
for
someone
who
is
relatively
new
to
gitlab,
that
would
be
even
scarier
and
let's
just
take
a
closer
look
at
all
the
things.
This
page,
we
have
the
upgrade
to
upgrade
your
plan
banner.
A
We
have
all
the
ui
to
manage
this
milestone
that
I
just
created.
We
have
a
sidebar
on
the
right.
Then
we
have
a
notification
message
like
an
alert
just
below
that
upgrade
banner,
which
is
telling
me
assign
some
issues
to
this
milestone,
but
not
actually
giving
me
an
option
to
do
something
from
here.
A
Then
I
have
what
seems
to
be
like
a
list
of
issues.
Merge
requests,
participants
labels,
so
I
can
navigate
through
this
and
unstarted
issues.
Ongoing
issues
completed
issues.
So
I
assume
that
once
I
add
issues
to
this
milestone,
they
will
be
sorted
in
these
three
columns.
Basically,
but
still,
how
do
I
add
issues
to
this
milestone?
A
A
A
So
I
clicked
on
the
new
issue
button,
because
that
looked
like
the
closest
thing
that
I
might
need,
and
then
I
noticed
I
landed
on
the
new
issue.
Page
which
wasn't
what
I'm
looking
for
so
I
did
notice
that
the
milestone
was
automatically
assigned
to
this,
to
the
one
that
I
just
created
and
the
one
that
I
came
from.
But
still
I
didn't
want
to
create
a
new
issue.
I
wanted
to
assign
an
existing
issue
to
this
milestone,
so
I
felt
lost
at
this
step.
A
A
I
was
feeling
hopeful
here,
because
most
of
apps
these
days
allow
these
types
of
things
to
be
done,
so
that
users
avoid
you
better
to
work,
and
I
found
the
edit
issues
button
and
I
was
hopeful
I
clicked
it.
It
opened
a
sidebar
and
it
also
showed
the
checkboxes
left
to
the
list
of
the
issues
and
also
an
option
to
check
them
all.
A
A
A
How
can
I
now
see
how
much
time
it
will
take
or
how
much
time
is
estimated
in
total
for
completion
of
this
work
right
for
all
these
issues
assigned
to
this
milestone
or
to
the
sprint
in
my
particular
case,
so
I
navigated
back
to
the
milestones
page.
I
noticed
okay,
there's
my
milestone
that
I
created
earlier
there.
There
are
five
issues
assigned
to
it.
I
clicked
to
open
it.
I
landed
again
on
this
page
and
in
the
sidebar
I
noticed
okay
time
tracking
estimated
120
hours,
okay,
so
that
seems
to
be
working.
A
A
A
So
next,
where
can
I
edit
the
estimates?
Maybe
you
know
I
can
lower
some
of
these
estimates
to
try
to
make
it
work
and
also
as
a
guide
right
how
much
time
should
be
spent
on
on
some
of
the
issues.
Maybe
I
can
get
some
time
back
and
try
to
make
it
work
so
that
it
actually
fits
a
two-week
sprint,
and
so
I
clicked
on
the
this
help
icon
with
the
question
mark
and
it
opened
this
section
which
tells
me
how
I
can
edit
estimates
and
how
much
time
was
spent
on
the
issues.
A
So
you
know
at
this
step
I'm
wondering
okay,
do
I
need
to
go
to
each
issue
separately
and
I
edit
the
estimation
there
and
then
I
okay,
I
realized
yes,
the
issues
are
actually
now
listed
in
this
milestone,
but
why
don't
I
see
the
estimates
here
on
this
list,
as
I
was
able
to
see
them
on
the
you
know,
general
issues
list
page
yes,
so
I
was
quite
annoyed
here
because
I
have
the
information.
A
Gitlab
has
the
information,
it's
just
not
giving
it
to
me
at
the
steps
where
I
would
require
it,
and
it's
also
not
giving
me
options
to
edit
this
estimates
in
a
in
a
in
an
efficient
way.
So
the
only
thing
that
remained
was
okay.
Let's
try
to
edit
all
these
estimates
separately
for
each
issue
separately.
I
felt
quite
annoyed
at
this
step
and
you
know
as
you
go
through
in
this
case,
I
had
to
go
through
five
issues,
but
sometimes
I
imagine
users
would
need
to
go
through
more
of
these
issues
and
so
yeah.
A
A
The
user
needs
to
do
them
through
quick
actions
which
is
through
comment
or
description
boxes.
Basically,
right
as
the
instructions
say,
and
I
wasn't
sure
how
actually
to
do
this-
you
know
as
a
new
user,
I
assumed.
Okay,
I
need
to
write
this
command
in
a
comment
box
which
still
feels
a
bit
odd
to
me.
It
feels
like
something:
an
advanced
user
would
want
to
do
as
a
something
like
a
shortcut
or
something,
but
it
feel
definitely
feels
like.
A
There
should
be
a
ui
for
more
basic
users
to
be
able
to
do
this,
so
I
decided
to
go
click
on
the
learn
more
button
here
in
this
widget
I
landed
on
the
docs
page.
This
was
somewhat
expected
and
this
page,
although
it
has
really
useful
content,
there's
quite
a
bit
on
it.
So
it
took
me
a
couple
of
minutes
to
get
to
the
section
where
it
explains
how
to
use
the
commands.
A
A
So
I
was
feeling
hopeful
at
this
step.
Yeah
and
eventually,
as
I
said,
you
get
tired
of
repetition.
Right.
Okay,
I
got
a
confirmation,
that's
the
set
time
the
estimate
was
set
to
24
hours
and
or
what
I
really
liked
was
also
that
it
was
immediately
reflected
in
the
sidebar
as
well.
Just
for
me
to
be,
you
know
to
confirm
that
okay,
the
estimate
was
updated.
I
felt
reassured
but
tired
of
repetition.
Definitely,
and
then
I
wanted
to
see
okay.
A
How
did
these
changes
of
estimate
times
reflect
on
the
milestone
overall,
and
I
had
this
tab
open
from
before
now
I'm
working
on
multiple
tabs
in
my
browser
right,
so
I
just
went
back
to
the
milestone
page
refreshed
it
and
okay.
I
saw
that
now
the
estimated
time
to
complete
all
these
issues
for
this
sprint
is
104
hours.
It
still
feels
a
bit
too
much
for
two
weeks,
but
it's
maybe
it's
doable
right.
A
So
at
this
step,
okay,
I
was
feeling
hopeful
a
bit
positive.
I
managed
to
do
this.
I
managed
to
find
out
okay.
We
can
actually
manipulate
the
estimates
in
gitlab
like
this
and
then
in
milestones.
We
can
see
if
it's
something
something
is
doable
or
do.
We
need
to
break
it
down
into
further
sprints
for
the
milestones
or
whatever,
and
then
I
wanted
to
see
what
happens
if
I
close
some
of
the
issues
in
this
milestone.
A
So
I
went
to
a
couple
of
issues
and
close
them,
and
then
I
navigated
back
to
the
milestones
page
or
I
just
you
know,
had
it
open
in
another
tab
went
back
there,
refreshed
it,
and
I
saw
okay.
Something
interesting
is
going
on.
Some
of
the
issues
were
actually
moved
into
the
completed
issues
column,
and
it's
actually
telling
me
now
that
40
of
work
for
this
milestone
for
this
sprint
is
completed,
and
this
is
also
a
useful
bit
of
information
which
tells
me
okay.
A
There
are
eight
days
remaining,
so
if
we're
40
done
and
there's
a
bit
more
than
half
of
the
sprint
remaining,
it
would
tell
me
okay,
there's
room
for
optimism
here.
The
work
can
possibly
be
done
in
two
weeks.
Two
weeks
in
this
two
week:
sprint
yeah
and
that's
basically
it
that's.
Where
I
ended
up.
A
I
still
felt
a
bit
confused
and
I
left
a
couple
of
comments
here
and
a
couple
of
ideas
for
improvements
as
well,
so
40
percent
of
work
is
completed,
but
how
many
estimated
hour
remains
right,
because
here
I
can
still
see
only
okay
104
hour
estimated,
but
that's
for
the
whole
milestone
for
all
of
the
work.
It's
not
telling
me
how
many
of
these
104
were
actually
completed.
A
It
only
says
40,
so
I
can
assume
like
okay
40
to
50
remain,
maybe
more
yeah
exactly
how
many
estimated
hours
in
maine.
I
can
only
make
an
estimate
based
on
the
info
about
40
completed.
So
will
our
team
make
it
until
the
end
of
the
milestone?
It's
still
hard
to
tell
I
it's,
I
can
make
an
assumption.
I
can
make
an
estimate,
but
it's
not
very
precise,
and
I
need
to
do
this
all
the
time.
Just
to
be
sure.
Okay,
our
team
is
on
track.
A
So
why
don't
we
tell
the
users
okay?
This
is
how
many
estimate
hours
remain.
You
have
this
many
days.
We
could
even
go
further
and
say
you
know.
We
know
that
a
working
day
has
eight
hours.
We
can
see
how
many
users
are
supposed
to
be
working
on
these
issues.
We
could
be
smarter
about
that
and
say
you
have
this.
Many
people
working
on
this
each
day
is
eight
hours
and
based
on
the
estimate,
number
of
hours
that
you
have
for
this
milestone.
A
It
either
looks
like
you
you're
on
track,
and
you
will
be
able
to
complete
this
work
or
it
looks
like
you
won't
be
able
to
complete
this
work
exactly
so
show
an
alert
when
it
looks
like
the
team
won't
make
it.
So
this
page
is
quite.
A
We
would
need
to
clean
this
page
up
a
bit
before
we
start
adding
more
information
to
it,
but
it
would
still
be
nice
if
I
landed
on
this
milestone
page
and
there's
like
a
section
telling
me,
it
looks
like
your
team
is
on
track
or
it
looks
like
your
team
won't
make
it
maybe
consider
making
some
changes
to
this
milestone
or
whatever,
and
we
could
possibly
even
send
out
email
notifications
when
it
seems
like
the
team
won't
make
it
like
it's
two
days
remaining
in
a
particular
milestone
and
there's
still.
A
A
Overall,
I
evaluate
this
experience
or
I
score
it
with
a
benchmark
of
c
a
grade
of
c,
which
is
average
and
the
heuristic
is
mostly
met.
Exceptions
could
require
final
work
runs,
but
the
completing
of
the
task
is
relatively
straightforward
and
overall
meets
expectations.
Usually
this
may
report
only
moderate
confidence
in
task
success.
I
think
that's
quite
accurate.
It
could
be
better,
so
I'm
thinking
c
or
c
minus,
maybe
even
because
below
average
looks
like
a
too
low
of
a
score.
A
The
heuristic
is
lacking
in
significant
ways
leading
to
frustration.
The
task
requires
workarounds
to
complete
or
otherwise
does
not
meet
expectations.
Users,
report,
low
confidence
and
task
success.
I
don't
think
that's
the
case,
so
maybe
somewhere
in
between,
I
would
say
c
or
c
minus
and
there's
definitely
room
for
improvement.
A
A
I
will
be
adding
recommendation
issues
on.
You
know
how
to
improve
this.
This
flow,
this
experience
I'll
be
collaborating
with
holly
on
that
and
yeah.
That's
it
for
now
stay
tuned
for
those
issues,
thanks
for
watching.