►
From YouTube: UX Showcase: UX Roadmaps
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
So
hi
everyone,
I'm
andy,
a
staff
designer
here
at
git
lab
and
today
I
wanted
to
talk
a
little
bit
about
ux
road
maps.
So
I
will
share
my
screen
and
just
do
a
brief
walk
through.
A
All
right,
so
this
is
staging
by
the
way.
Don't
worry
what
we
have
is
just
a
brief
background.
So,
a
couple
years
ago
I
got
assigned
an
issue
to
add
a
filter.
To
this
page.
No
big
deal
right
got
some
space,
not
that
many
filters,
no
problem,
then
I
recalled
a
conversation
I
had
with
another
pm
who's
like
hey,
I
need
to
add
you
know
this
other
filter
and
that
got
me
and
my
pm
wondering
how
many
more
filters
need
to
be
added.
A
We
found
like
six
and
that's
a
lot
that
would
make
this
ten
and
then
we
were
like
well,
that
is
a
whole
different
conversation
of
filtering
and
advanced
search
and
the
filtered
search
component
itself,
but
I
was
wondering
more
around
the
situation
of
not
necessarily
being
blindsided
but
kind
of
being
like
well.
How
did
we
not
know
about
these
needs
right?
These
issues
had
existed.
A
For
you
know
a
few
months
and
in
the
conversation
I
had
with
valerie
she's
like
well,
this
is
where
ux
road
maps
and
working
thematically
comes
in
and
so
over.
That
course
that
span.
I
think
we
all
forgot
what
time
was
two
years
ago,
but
I
had
tried
different
approaches
to
bring
ux
roadmaps
in
and
it
wasn't
until
an
okr
in
q1.
A
In
february
I
started
to
formalize
the
approach,
so
I
went
and
took
an
nng
course
on
what
ux
roadmaps
are
and
how
to
incorporate
that
process
into
a
design
department
and
with
help
with
justin,
we
were
able
to
create
a
process
and
documentation
for
ux
roadmaps
and
at
the
highest
level.
I
won't
go
in
and
read
all
of
this
documentation,
but
at
the
highest
level,
ux
roadmaps
are
a
strategic
living
artifact
that
aligns
prioritize,
prioritizes
and
communicates
a
product
team's
future
work
and
problems
to
solve.
A
A
The
benefits
of
these
roadmaps
are:
they
can
align
teams
and
groups
across
stages.
So,
if
you're
looking
at
the
high
level
problems
being
solved
and
secure
and
protect
and
you're
in
ci,
cd
or
ops,
you
can
see
where
there
are
areas
of
overlap
as
well
as
teams
can
look
down
the
road,
your
internal
counterparts
and
say:
hey
they're,
going
to
be
working
on
advanced
filtering
in
search.
That's
great.
A
A
You'll
have
as
a
designer
like
a
more
significant
problem
area,
to
focus
on,
as
opposed
to
feature
by
feature
by
feature
by
feature
which
would
have
happened.
Looking
at
our
filters
right,
we
would
have
gotten
to
five
and
gone
well,
can't
add
any
more
filters,
but
that
wouldn't
have
happened
until
three
months
after
we
implemented
that
last
filter.
A
Not
only
this
too
we'll
be
focusing
on
like
a
larger
problem,
set
right,
the
the
needs
of
the
user
right
and
all
of
the
experience
touch
points
in
one
time,
not
only
that
the
benefits
of
using
road
maps
are,
they
helped,
align
you
as
a
strategic
counterpart
with
your
product
manager.
A
We
see
some
definition
of
like
the
difference
in
product
road
maps
and
the
different
types
of
ux
road
maps,
but
I
can
just
show
you
all.
Instead,
so
we
have
gone
through
a
pilot
justin
and
I
and
secure
protect,
monitor
configures
coming
up
and
a
few
stages
from
release
and
pipeline
insights
to
create
ux
roadmaps.
A
The
okr
and
q1
was
successful
and
we've
made
some
modifications
to
the
process,
and
now
we
are
moving
into
that
second
stage
of
groups
coming
in
and
we'll
be
doing
workshops
with
them.
We'll
get
that
part
later,
and
so
what
you
see
here
is
a
manifestation
of
a
ux
road
maps
using
a
board
and
themes
using
the
issues
themselves
and
slid
lanes
for
stage
groups.
A
So
the
das
ux
roadmap,
which
is
comprised
of
that
goal
and
vision
statement
that
is
going
to
act
as
their
guard
rails
for
the
year,
this
kind
of
defines,
what's
in
and
what's
out
in
terms
of
scope,
as
well
as
the
themes
that
are
built
within
if
we
wanted
to
dive
in
more
into
the
themes.
So
the
themes
themselves
going
back
to
the
documentation
are
really
the
important
part
of
the
ux
roadmap.
It's
all
about
working
thematically.
A
A
Diving
into
the
structure
of
a
theme
itself:
it's
really
just
the
job
to
be
done
like
this
is
where
I
think
we
have
some
difficulty
using
jobs
to
be
done.
Is
that
they're
granular
right
in
granular
issues,
they're
not
meant
to
be
used
at
that
low
level
or
that
micro
job.
That's
really
where
the
user
story
comes
in,
but
using
jobs
to
be
done
to
define
the
theme
in
the
roadmap
is
the
practical
application
of
jobs
to
be
done.
A
So
you
see
these
themes
here,
they're
all
predicated
on
a
single
job
to
be
done
with
sub
themes
as
well.
If
they
need
be,
I
know
I'm
covering
a
lot
and
I'm
going
quickly.
So
hopefully
the
documentation
helps
fill
in
any
gaps
too,
but
we
look
at.
We
have
themes
that
are
comprised
of
the
beneficiary
right
who
these
people
are,
that
we're
solving
the
problem
for
and
who
the
recipients
of
the
value
of
the
product
or
service
is
their
need,
which
is
built
from
the
job
to
be
done.
A
That
middle
part,
the
business
objective
that
we
hope
to
achieve
sub
themes,
which
today
we
are
retrofitting
all
of
the
existing
feature,
issues
as
sub
themes,
right
they're,
just
either
highly
assumptive
solutions
or
even
validated
solutions
or
just
ideas,
as
issues
then
we'll
assign
confidence
which
we
have
done
in
the
workshop,
as
well
as
time
frame
and
owner
any
questions.
So
far,
we
can
collaborate.
It's
okay,
okay,
I'm
gonna,
keep
going,
let's
see
here.
A
So
how
do
we
build
these?
This
here
you
see,
is
the
manifestation
of
the
ux
theme
into
an
issue
right.
All
of
those
components
I
just
walk
through
goes
into
an
issue
and
you
can
either
link
the
sub
themes
which
were
existing
feature
issues
or
you
know
hard
link
them.
A
A
You
want
to
include
the
product
dri
and
the
design
dri.
This
is
a
collaborative
process.
It
can't
be
done
in
a
silo
or
in
the
chamber
just
from
the
ux
side.
It
has
to
have
buy-in
and
it
has
to
ladder
into
the
strategic
goals
and
direction
of
your
stage
in
stage
group
from
there.
We
just
have
a
few
tasks
for
teams
to
do
like
just
educate
themselves
on
what
ux
roadmaps
are
read
the
documentation
and
provide
us
with
inputs.
A
It
is
a
two-hour
workshop,
but
it's
only
once
a
year.
Maybe
so
it
hasn't
been
a
pain
point
yet,
and
then
we
ask
for
those
goal
and
vision
inputs
so
that
we
can
ladder
what
we're
creating
as
a
roadmap
into
what
our
product
is
driving
and
then
we
don't
want
to
forget
jobs
to
be
done
and
there
are
actual
insights.
So
how
this
looks
in
practice
is
it's
a
mess
and
it's
awesome.
A
We
start
off
with
our
section
and
stage
goals
and
our
category
goals
and
from
there
we
build
out
our
vision,
our
vision
statement
like
what
do
we
expect
and
we
ask
these-
prompts
right,
like
by
2023
users,
will
be
able
to
blank
with
our
capabilities,
and
that
is
going
to
act
as
our
guard
rails
for
all
of
the
themes
we're
going
to
be
building
and
working
on
for
the
duration
of
the
roadmap.
A
We
also
have
those
internal
goals
like
what
does
success,
look
like
for
the
ux
and
research
team.
That's
good
as
well,
and
this
also
acts
as
a
nice
warm-up
exercise,
and
then
we
move
into
taking
all
of
the
inputs.
So
all
of
the
yellow
posties
are
issues
that
had
already
been
created
and
they
were
organized
in
different
epics.
A
We
include
the
jobs
to
be
done
and
any
actionable
insights
that
revolve
around
the
center
of
work
that
the
team
had
been
focusing
on
for
this
year
and
then
we
just
restructured
it
right.
So
all
of
these
buckets
here
are
based
on
the
same
beneficiary,
who
has
the
same
needs
with
the
same
expected
outcomes
from
there.
We
get
a
better
organization
allowing
the
designer
to
focus
on
this
problem
area
as
opposed
to
each
one
of
these
individual
features,
and
the
problem
area
is
anchored
by
our
jobs
to
be
done.
A
And
just
an
infographic
to
help.
So
again
we
have
our
scope.
This
defines
the
boundaries
of
our
roadmap.
We
throw
all
our
inputs
together,
which
are
feature
issues
job
to
be
done,
actionable
insights.
We
begin
bundling
them
based
on
the
beneficiary,
the
job
to
be
done.
We
refine
them
into
those
what
we've
seen
as
issues.
So
we
got
the
business
objectives.
The
sub
themes,
their
confidence.
A
So
I'll
stop
there.
I
know
I
covered
a
lot.
B
I
had
a
quick
question:
why
is
working
in
themes
different
or
better,
and
why
can't
we
just
work
issued
issue
like
we
do
now.
A
So
working
thematically
allows
you
to
kind
of
get
your
elbows
out
into
the
problem.
Space
right
allows
you
to
not
work
in
the
boundaries
that
were
defined
by
the
granular
feature
issue
right,
there's
a
prescribed
solution
that
was
given
to
us.
It's
users
must
be
able
to
do
x,
y
and
z
in
this
part
of
the
ui.
A
Sometimes
it
may
be
more
vague,
but
with
the
theme
we
also
get
to
think
more
about
the
end-to-end
ux
process
right,
so
we
could
be
delivering
flow
diagrams.
We
could
be
doing
problem
validation.
A
A
And
the
end
result,
though
this
does
seem
like
you're
building
this
big
thing:
how
do
we
iterate
and
break
it
down?
Well,
that's
that's
the
iteration
and
mvc
value
that
our
counterparts
are
going
to
be
working
with
us
collaboratively
to
do.
We
deliver
the
designs
and
implement
them
iteratively,
I
think
designing,
piecemeal
and
iteratively
gets
us
into.
A
So
right
now
we
are
facilitating
workshops,
we're
trying
to
find
a
process
to
expand
facilitators
in
general.
So
it's
not
just
myself
and
justin
doing
the
facilitation,
but
if
teams
are
interested
in
it,
they
feel
free
to
like
jump
on
board
and
sign
up,
and
hopefully
we
can
kind
of
navigate
just
having
two
people
who
facilitated
these
in
the
past.
B
Now,
yeah
right
now
we're
doing
it
through,
like
okay,
ours,
design
managers
reach
out
to
me
and
we
can
work
together
to
figure
out
how
to
get
your
team
set
up.
That's
how
I've
we've
been
doing
it
hannah
volunteered
for
this
quarter,
so
anyone
else
or
hopefully
we
can
do
the
next
quarter
and
the
quarter
after
I'll
work
with
valerie
on
that.
But
if
that
doesn't
happen,
you
could
still
reach
out
to
me
and
we'll
figure
something
out.
It
doesn't
have
to
be
no
care.