►
From YouTube: UX Showcase: Error Tracking
Description
Amelia shares UX work on Error Tracking in GitLab Monitor
A
So,
as
Erin
mentioned,
I'm
Amelia
and
I'm,
one
of
the
monitor
product
designers,
I
work
alongside
Nadia
and
Matt
on
the
to
monitor
teams
which
are
EPM
and
health,
and
today
I
wanted
to
walk
through
the
updates
with
me,
get
your
tracking.
You
can
get
one
up
over
the
past
couple
of
milestones,
and
this
work
in
particular
was
done
with
a
health
team,
and
we
worked
closely
with
Sarah
Walder
who's,
the
product
manager
for
that
team.
A
To
do
what's
your
score,
you
see
in
order
to
set
that,
like
context
a
little
bit
just
wanted
to
talk
a
little
bit
about
why
air
tracking
is
important.
If
something
is
broken
on,
your
application
developers
or
support
engineers
or
Sarris
will
need
a
way
of
digging
into
what's
got
going
wrong,
so
they
can
restore
service
quickly,
but
also
for
proactively.
Like
every
time.
You
push
your
code.
If
you
see
that
a
bunch
of
errors
are
popping
up,
you
can
look
into
them
and
see
if
they're
expected
or
not
and
taken
to
them
as
needed.
A
So
that's
a
little
bit
about
how
air
tracking
is
used
and
why
it
might
be
important
area.
Tracking's
relatively
new
and
get
lab
a
year
ago,
we
didn't
have
any
air
tracking
of
any
kind,
but
last
December
the
monitor
team
gathered
together
in
real
life.
Just
shocking,
forget,
laughs,
I
know
what
we
did.
A
number
of
facilitated
design
exercises
together
and
built
a
simple
version
of
air
tracking
in
just
a
couple
of
days
and
I've
added
the
the
obligatory
team
working
with
post-its
picture
in
to
prove
that
we
were
all
there
and
it
really
happened.
A
The
MVC,
which
you
can
see
here
was
very
simple.
It
was
an
integration
with
sentry,
which
is
an
existing
air
tracking
tool
and
it
relies
on
the
century
API
to
populate
basic,
a
list
view
within
get
lab,
so
it
linked
this
existing
century
instances
to
get
lab
and
lifted
the
Sentry
errors
in
get
lab,
but
in
order
to
get
any
additional
information
about
those
or
to
act
on
them
at
all,
you
had
to
go
back
to
century.
A
So
we
provided
a
link
back
to
century
to
investigate
further,
so
you'll
notice
that
this
is
not
like
a
read-only
list
of
errors
and
that
users
would
need
to
go
back
to
century.
To
do
anything
remotely
useful
with
this
list,
for
instance,
to
see
more
details
about
the
errors
to
create
an
issue
from
the
errors
to
assign
someone
to
investigate,
there's,
essentially
to
do
any
of
the
other
wonderful
things
we
can
do
with
get
wicket
luck
with
the
errors.
A
A
This
is
something
we
obviously
wanted
to
remedy
as
quickly
as
possible,
but
in
monitor
we're
working
on
a
number
of
separate
product
features.
So
often
what
happens?
Is
we
work
on
something
we
get
an
MVC
out,
and
then
we
have
to
kind
of
go
on
to
the
next
thing,
so
our
our
error
checking
and
receipts
a
little
unused
and
a
little
unloved
for
about
six
months,
but
a
few
milestones
ago
we
started
revisiting
or
checking
in
the
team
and
our
goal
in
revisiting.
A
A
Conducting
user
interviews
and
mapping
the
results
of
those
interviews
to
consolidate
our
insights
and
after
this
work
was
completed,
the
plan
was
to
create
issues
to
improve
air
tracking
and
a
base.
Those
plans
on
what
we
discovered
during
our
research
and,
to
be
honest,
this
was
a
big
change
in
process.
For
us.
A
As
a
team
and
past,
we
were
more
likely
to
ship
something
whatever
it
was,
or
get
feedback
and
approval
on
it
like
in
a
spirit
of
iteration,
but
here
we're
kind
of
turning
everything
on
its
head
and
we're
trying
to
check-in
users
before
building
and
shipping
something
and
for
us,
as
a
team.
This
was
a
big
shift.
A
So,
in
this
problem
validation
phase,
we
focused
on
better
understanding
the
workflow
for
air
tracking,
so
we
could
figure
out
how
to
fit
into
it.
One
new
users
look
at
errors.
What
steps
do
they
take
when
do
they
investigate
errors?
What's
the
flow
for
remediating
them
and
the
stickies
that
you're,
seeing
in
the
affinity
map
our
users
responses
to
these
questions?
We
took
these
real
users
responses
and
turn
them
into
issues
and
use
these
insights
to
inform
our
next
steps
and
her
designs.
A
So,
based
on
this
research,
we
made
a
number
of
improvements
to
air
tracking.
You
get
loud,
Jerry
12.6,
so
these
things
are
already
out,
including
increasing
a
search
to
our
air
list,
view,
creating
an
air
detail
page
and
allowing
users
to
create
issues
from
errors,
and
we're
really
excited
about
these
changes
because
they
help
users
more
easily,
investigate
and
resolve
errors
from
within
gitlab.
So
users
can
stay
in
get
lab
as
they
dig
in
errors
and
deploy
the
code
to
fix
them,
which
means
less
context.
A
So
what
does
this
look
like
so
here
you're
seeing
much
of
the
original
list
new
for
errors,
but
we've
added
in
a
search
bar
recent
search
up
here
in
the
top
and
sort
options.
We
also
cleaned
up
the
way
the
list
displays,
as
we
realize
that
some
of
the
information
coming
from
the
century
API
was
being
consolidated
and
displays
displayed
in
ways
we
didn't
originally
expect.
A
Essentially,
we
had
originally
like
designed
a
whole
row
in
this
table
for
error
descriptions,
but
when
we
started
seeing
more
live
instances
of
this
list
in
action,
we
realized
that
the
description
was
being
automatically
appended
to
the
title
by
the
API.
So
our
early
versions
of
this
table
and
had
a
lot
of
empty
States
for
this
description
should
have
been,
but
this
is
now
fixed.
So
that's
that's
great
you'll
also
notice
that
we
added
the
ability
to
act
on
errors
from
the
ListView,
so
you
just
can
easily
ignore
or
resolve
errors.
A
Look
directly
from
the
list
view
and
pagination
for
the
list
is
also
coming
soon,
so
that's
very
exciting
because
we
can
actually
display
more
of
the
errors
than
we
could
originally,
and
this
is
the
second
big
improvement
when
we
introduced,
which
is
the
air
detail
screen
so
clicking
on
any
item
in
that
first
ListView
will
now
show
you
the
details
of
the
error,
and
this
whole
screen
is
totally
new
for
us
here.
Users
can
see
many
of
the
details
that
they
originally
had
to
go
to
century
to
see,
including
foreseen,
lasting
information.
A
So
we're
also
really
excited
about
this,
and
then,
after
we
put
together
these
original
designs,
we
also
went
through
with
solution
and
validation
process
which
helped
us
to
refine
our
designs
and
identify
new
opportunities
and
kind
of
validate
our
approach.
And
one
of
the
things
we
quickly
validly.
As
part
of
this
research
is
the
sorts
of
filtering
that
we
had
been
planning
on
for
air
list.
A
We
were
debating
a
number
of
filters
like
filter
by
release
commit
NMR,
but
based
on
this
research,
we
D
prioritize
several
of
these
options,
as
we
found
that
the
filters
that
we
have
been
planning
on
introducing
weren't,
actually
the
ones
that
are
most
important
to
users.
So
it
was
really
good
that
we
were
able
to
get
that
information
from
users
and
not
proceed
with
something
that
they
didn't
necessarily
want.
A
So
in
terms
of
this
UX
showcase
platform,
we
wanted
to
share
these
improvements
in
particular,
because
this
is
a
big
shift
in
process
for
monitor.
So,
as
mentioned,
we're
really
trying
to
shift
from
a
place
of
act
first
and
get
feedback
later.
So
one
where
we
get
feedback
first
and
allow
those
insights
to
inform
our
plans
and
our
designs-
and
this
feels
like
a
bit
of
a
sea
change
for
us
as
a
team
and
we're
really
embracing
the
problem.
A
So
in
just
a
few
milestones
where
we
completed
the
problem
and
solution,
validation
as
well
as
making
a
great
number
of
improvements
to
air
tracking
and
we're
feeling
really
excited
about
that
as
a
team
and
we're
feeling
excited
also
to
apply
this
process
to
our
next
or
next
team
effort.
So
that's
that's
all
I
had
thank
you.