►
From YouTube: Job filters - Solution validation research insights
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
I'm
ritika
the
senior
product
designer
for
Batman
execution
team
today
I'll
be
sharing
the
results
from
a
recent
solution,
validation,
research
that
we
did
for
job
filters,
providing
a
little
context
for
this
exercise.
So
through
this
issue
in
around
1410,
we
delivered
a
filter
for
the
job
list
view
or
the
job
index
page,
and
this
is
what
it
looks
like.
A
We
started
off
with
a
feed
with
the
filter
option
that
we
were
the
most
confident
with
so
this
was
the
MVC
that
was
rolled
out
and
also
there
was
a
lot
of
constraint
that
the
development
team
had
to
work
with.
So
we
try
to
keep
it
smaller
in
scope
and
not
go
with
the
filter
that
we
were
not
super.
Confident
with
now.
A
For
the
next
step,
we
received
a
lot
of
feedback
on
this
issue
itself,
like
there's
a
lot
of
comments
from
different
users
through
the
Cs
team
through
the
TA
team,
and
we
were
still
like
just
to
be
able
to
make
very
confident
decisions
as
to
what
the
next
iteration
should
be.
A
Without
it,
it
would
be
a
good
idea
to
go
with
the
research
first
speak
to
our
users
firsthand
to
understand
like
what
is
it
that
they
intend
to
accomplish
using
the
filter
and
what
the
relevant
use
cases
that
we
should
be
designing
for
so
starting
with
the
in
I'll,
be
sharing
a
summary
for
each
of
the
insights
that
I
had
received
through.
By
going
to
the
information
that
we
received.
A
So
let's
get
started
the
first
one
says
filters
are
useful
when
looking
for
jobs
triggered
by
other
team
members.
So
when
we
try
to
understand
like
when,
is
it
that
users
feel
the
need
to
look
for
a
job
for
a
particular
project?
A
So
something
that
really
came
to
the
surface
was
when
developers
are
working
in
very
small
teams
like
when
they
work
for
a
small
organization
or
a
very
small
team,
they're,
very
aware
of
like
the
pipelines
that
they
run
they
trigger
the
jobs
that
they
trigger
the
health
of
those
jobs,
the
performance
of
those
jobs.
A
So,
in
those
circumstances
they
know
what
they're
looking
for
it's
easier
for
them
to
look
for,
even
though
there's
no
like
easy
way
to
look
for
a
pipeline
or
find
a
pipeline
today,
but
they're
able
to
do
it
because
they
know
the
time
the
execution
time
and
that's
what
they
kind
of
try
to
dig
into
by
scrolling
through
the
list
and
another
use
cases
when
they
work
with
the
team
when
they
work
in
pairs
they're,
not
always
aware
of
what
their
peers
are
working
on
and
the
situations
when
they
have
to
go
and
investigate
into
the
jobs
that
was
from
triggered
by
a
colleague.
A
So
that's
when
they
have
a
certain
set
of
information,
but
currently
what
they
do.
Is
they
scroll
to
the
through
the
list
or
go
through
the
execution
times
and
then
use
control
F
to
find
jobs?
By,
like
the
triggered
author,
they
just
type
in
and
try
to
search
like
that.
A
So
those
were
the
use
cases.
Next
is
filtering
pipeline
by
status
with
the
first
step,
users
follow
while
searching
for
a
job.
So
it's
like
good
for
us,
because
this
kind
of
got
validated
that
status
is
indeed
the
most
primary
information
that
users
put
in
first,
because
they
cannot
come
with
an
intention
to
specifically
look
for
a
job
that
has
been
completed
that
has
been
or
that
that
has
failed.
So
the
tab
that
we
provide
today
here
finished
and
it's
actually
quite
useful
for
them.
A
But
what
would
also
be
useful
like
because
fail
is
also
very
sought
after
a
status
if
we
can
provide
something
for
field
we'll
see
about
that
all
right.
Moving
to
the
next
one,
so
job
name
is
relevant
only
if
users
already
know
the
branch.
A
This
was
interesting
because,
even
though,
like
job
name
is
something
that
would
easily
be
perceived
as
the
most
important
search
filter,
it
kind
of
still
needs
a
support
of
status
and
Branch,
so
users
need
to
know
like
they
come
with
this
information,
that
okay,
this
job
is
failed,
or
this
has
completed
the
one
that
they
are
searching
for
and
it
ran
for
this
particular
change
of
particular
Mr
commit
so
that
piece
of
information
is
carried
in
the
branch
name.
A
So
once
you
provide
the
status
and
the
branch
name,
it
kind
of
forms
the
overarching
context
for
the
job
they're
looking
for,
and
then
it
makes
it
easy
for
them
to
just
select
a
name
or
yeah
search.
My
name
now
this
next
one
is
kind
of
a
rewording
of
the
same
Insight,
because
here
I
put
the
emphasis
on
the
job
name
that
it's
only
relevant
when
users
know
the
branch
name.
A
This
here
puts
the
emphasis
on
the
pairing
of
branch
and
status,
but
it's
pretty
much
the
same
all
right.
Next
one
is
preferred
filters
or
status,
Branch,
name,
job
name
and
Trigger
author.
So
from
what
the
information
that
we
gather
the
most
preferred
filter,
the
top
two
were,
of
course,
status
and
Branch
name.
The
next
were
like
once
you
have
those
you
go
by
the
job
name
when
you
know
the
job
that
you're
looking
for
or
the
trigger
author.
A
So
next
one
says
execution
time:
filter
can
help
surface
the
bottlenecks
bottleneck
jobs
in
the
pipeline.
So
this
was
an
improvement
suggestion
by
one
of
the
participants
that
currently
when
they
are
looking
to
like
compare
performances
for
jobs
they
have
to
just
scroll
through
and
find
that
which
is
the
one
that's
been
taking
a
lot
of
time.
A
So
the
suggestion
came
that
if
you
can
allow
us
to
filter
by
execution
time,
it
would
be
super
easy
for
the
team
to
know
like
which
is
the
job
that
has
been
consuming
the
most
time
and
is
kind
of
consuming
a
lot
of
resources
which
is
going
to
also
help
with
the
optimization
part.
A
The
next
one
is
artifacts
are
helpful
by
investigating
the
performance
of
a
recent
job,
so
I
also
had
included
included
some
questions
around
like
how
Runners
artifacts
environments
like
what's
the
role
that
these
factors
play
when
a
job
is
concerned.
So
users
mentioned
that
artifacts
can
be
useful,
but
only
if
the
job
that
they're
investing
investigating
for
is
a
recent
one,
because
then
they
can
use
the
generated
artifact
to
know
like
what
the
problem
is.
A
The
lack
of
appropriate
filters
make
users
scroll
through
long
lists
and
use
control
F
to
find
specific
jobs.
This
was
we
try
to
understand
like
what
is
it?
A
What
are
the
workarounds
that
users
are
using
today
to
be
able
to
achieve
the
same
goals,
so
they
have
been
just
like
scrolling
searching
by
execution
time
and
using
Ctrl,
f
and
then
presenting
jobs
in
the
context
of
the
environments
they
ran
for
a
helping
understanding
with
the
problem
lies
I,
think
related
information
is
also
sitting
somewhere
in
one
of
the
release,
researches
that
users
really
want
to
like
search
jobs
and
pipelines
by
environments,
because
then
that
helps
them
understand
point
the
problem
sooner.
A
If
the
problem
is
with
the
job
or
the
change
or
with
the
within
with
a
specific
environment,
so
it
would
help
with
that,
and
that
is
all
so.
As
for
my
next
steps,
I'll
be
creating
issues
and
also
outlining
the
next
steps
that
we'd
be
following
in
around
like
what
should
be
the
next
filter
that
we
should
be
adding
here
and
what
kind
of
experience
we
should
provide.