►
A
A
So
for
this
scorecard,
I
chose
the
persona
as
either
sasha
the
software
developer
or
devin.
The
devops
engineer
and
the
job
to
be
done
would
be
when
I
have
a
stable
development
and
operations
organization.
I
want
to
author
a
ci
pipeline
so
that
others
in
my
team
can
leverage
ci
to
increase
the
efficiency
of
their
tasks.
A
But
due
to
the
fact
there
were
many
ways
to
kind
of
like
author
a
pipeline
for
the
first
time,
I've
broken
this
experience
down
into
four
key
flows.
The
user
may
use
to
onboard
into
verify
so
the
first
one
is
creating
a
pipeline
from
the
widget
on
the
merge
request
page.
The
second
is
a
user
just
landing
on
the
empty
state.
Ci
cicd
page,
the
third,
which
is
an
actual
common
experience,
is
just
googling,
gitlab,
ci,
cd
or
similar,
and
the
final
one
is
just
the
user
starting
from
the
button
on
that
project
page.
A
So
the
first
experience
I
graded
was
user,
creates
a
pipeline
from
the
merge
request
page
and
to
walk
you
through
that
I'll
just
walk
through
my
mural
experience.
So
this
user
has
landed
on
the
merge
request
page
without
a
pipeline
and
sees
the
show
me
how
to
add
a
pipeline.
This
is
actually
pretty
straightforward.
It's
a
pretty
big
area
of
the
merge
request,
kind
of
catches,
their
attention.
A
Then
a
user
would
land
on
this
empty
new
file,
page
with
the
gitlab
ci
yaml
file,
pre-populated
up
there,
as
well
as
some
onboarding
tips
on
what
to
do
when
they
click
apply
a
template,
they
can
scroll
through
the
ci
templates.
We
have
there's
also
a
tip
in
that
onboarding
tip
up
top
so
well.
There
aren't
very
many
descriptions
on
which
templates
to
apply,
which
templates
these
mean,
which
means
some
kind
of
newer
users
to
ci
cd,
might
have
to
google
or
look
in
the
docs.
A
For
some
of
this
overall
fairly
easy,
you
can
choose
one.
So
then
a
user
can
choose
a
template
kind
of
edit
the
template
to
their
desire
and
then
there's
another
onboarding
pop-up.
That
kind
of
lets
cesar
know
to
now
commit
their
changes
when
they
hit
commit
their
changes.
We
actually
get
like
this
little
success.
A
A
It
catches
users
at
the
right
time
and
right
place
and
overall
you
can
get
through
it
fairly
quickly.
Some
potential
small
improvements
could
be.
Some
copy
could
be
tweaked
to
further
explain
the
benefits
of
pipeline.
On
the
entry
point,
the
onboarding
steps
could
carry
through
to
the
very
end
to
the
pipelines
page
or
we
could
test
them
out
in
more
subtle
ways
like
adding
text
stubs
to
the
file.
A
The
next
one
is
user
lands
on
empty
state
ci
cd
page-
and
this
is
where
the
user
kind
of
gets
this
empty
state
billed
with
confidence,
get
started
cicd,
so
they
would
click
here
and
this
actually
drops
them
into
the
docs.
So
this
experience
does
get
more
manual
here.
A
user
will
have
to
kind
of
read
through
the
docs
figure
out
what
they're
doing
they
potentially
could
click
here
kind
of
like
create
a
gitlab
cml
yml
file,
and
then
they
kind
of
get
pushed
to
this.
A
So
if
they
do
do
that,
the
inter
the
nice
thing
here
is
when
they
do
pre-populate
the
title
the
templates
do
show
up
here,
but
again
for
a
first-time
user.
We
don't
really
call
that
out
so
they'd
have
to
explore
and
find
that
on
themselves
or
go
back
and
forth
between
the
dogs
to
see
what
they
were
doing.
A
Once
they
pre-fill
that
out
again,
there's
no
onboarding
instructions
in
this
one.
It's
just
a
basic
file
where
they
would
then
commit
the
changes
and
from
here
they
have
the
pipeline
running.
So
they
could
then
go
check
what
the
pipeline
looks
like,
but
again,
no
onboarding
context
on
this
one
either.
A
So
for
this
I
scored
it
a
c
minus
which
is
average
leaning
below
average.
We
do
provide
the
user
with
all
the
information
they
needed,
but
there
are
some
gaps
in
this
experience.
It's
very
manual.
They
are
required
to
go
through
a
wiki
page
to
get
started.
There
isn't
much
onboarding
help
or
context
when
they
create
the
ci
yaml
file
for
the
first
time,
and
there
isn't
really
a
celebration
or
high
moment
in
this.
A
Look
for
the
information
that
they
needed,
so
kind
of
find
that
get
started
area.
And
now
this
is
similar
to
the
last
experience
where
they
would
go
through
that
similar
get
started.
Creating
that
gitlab
cieml
file
following
kind
of
like
the
doc
explanation,
but
as
there's
no
link
out
here,
they're
kind
of
set
doing
this
by
themselves
in
another
tab,
so
copying
that
sample
code
creating
a
new
file
where
they
can
apply
the
template
if
they
want
and
then
kind
of
like
editing
that
file
to
be
what
they
want.
A
Creating
that
merge
request
and
just
viewing
their
pipeline
running
so
again,
this
one
is
similar
to
the
last
one
where
we
land
them
in
the
docs.
They
have
to
go
through
the
manual
process
of
the
docks.
A
new
user
who's,
not
very
comfortable
with
ci
cd,
would
probably
get
lost
in
this
experience,
there's
no
real
onboarding
context.
A
That
being
said,
users
can
get
through
it.
You
can
get
through
it
if
you
can
read,
but
it
isn't
the
most
desired
experience.
So
this
one
again,
a
c
minus
we
do
provide
the
user
with
all
the
information
they
need,
but
it's
a
completely
manual
process
with
very
little
onboarding
help.
There's
lots
of
opportunities
here
to
help
for
a
first-time
user.
Coming.
A
A
So
this
is
where
a
user
kind
of
creates
a
new
project.
Has
nothing
really
set
up
yet
and
realizes.
There
is
a
set
up.
Ci
cd
button
here,
so
they
can
do
that
this
at
any
time
they
see
that
button
to
kind
of
get
ci
cd
started
on
their
project,
so
that
kind
of
brings
them
to
this
page.
That
lets
them
know
kind
of
what
this
is.
So
it's
going
to
create
a
new
gitlab
ciemo
file
at
the
root
of
the
repository.
A
So
you
can
go
here
to
create
now
this
one
lands
you
on
a
blank
page
again,
but
on
the
right
hand,
side.
There's
all
this
context
to
help
you
get
started,
explain
what
get
lab
ci
cd
is
how
to
run
your
first
pipeline
as
well
as
links
out
to
templates
a
user
could
use
and
such
it
is
more
manual
you
do
have
to
read
through
and
find
the
information
you're
looking
for.
A
So
if
they
click
out
to
the
examples,
they
can
look
through
certain
ci
cd
examples
and
choose
the
one
that
makes
sense
for
them
and
then
come
back
to
this
page
post.
Something
in
commit
those
changes
and
that's
where
their
pipeline
would
run
so.
Overall,
this
experience
gets
a
little
bit
better,
a
c.
It's
quicker
to
finish
and
has
a
lot
of
options
to
customize
the
pipeline,
but
the
original
entry
point
is
sort
of
hidden.
A
So
yeah
there's
a
lot
of
different
ways.
We
could
improve
these
experiences,
but
the
final
bonus
of
doing
this
scorecard
template
is,
with
the
help
of
mate,
we
kind
of
crafted
a
mural
user
journey
template
that
others
can
use
too.
So
I
can
link
that
in
this
presentation
also
can
be
found
in
the
issue
of
this
ux
scorecard
as
well,
but
yeah.
That's
about
it.
Thanks
for.