►
From YouTube: UX Showcase: Roadmaps & Jira Importer
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
Awesome,
thank
you,
cool
hello,
y'all.
I'm
alexis
ginsberg
senior
product
designer
currently
working
on
the
plan
stage
I'll
be
chatting
with
you
a
little
bit
about
road
maps
and
then
I'll
hand
it
over
to
holly.
To
tell
you
about
her,
exciting
importer
work.
A
So,
first,
let's
start
with
what
a
roadmap
is
in
a
nutshell:
a
roadmap
helps
a
team
understand
where
they
are
where
they
want
to
be
and
how
they
could
possibly
get
there.
It's
basically
a
document
that
helps
lay
out
product
vision,
both
short
and
long
term,
usually
over
the
course
of
a
year,
or
so
it
helps
our
teammates
in
product
communicate
key
priorities
with
both
internal
and
external
stakeholders,
which
lines
up
perfectly
with
our
main
job
to
be
done
in
roadmaps,
so
the
larger
and
more
functional
job
here
is.
A
I
want
to
view
the
status
of
planned
work
items
within
the
roadmap
from
a
high
level
down
to
a
very
granular
view,
so
I
can
craft
the
right
right
roadmap
for
the
right
audience,
so
right,
roadmap
right
audience.
A
A
Our
next
goal
is
to
move
road
maps
from
minimum
to
viable
and
to
get
more
git
labors
using
our
roadmaps
instead
of
google
docs
in
excel,
as
some
of
them
currently
do
through
customer
interviews
and
feedback.
We
have
some
solid
assumptions
on
what
could
help
get
us
here,
as
you
can
see
in
the
epic
I'll
highlight
three
things
we're
currently
working
on
that
will
hopefully
get
us
on
track.
A
So
when
I
came
into
the
plan
stage
and
then
moved
into
the
portfolio
management
team,
as
dri
road
map
looks
something
like
this,
so
as
you
can
see,
we
weren't
really
too
far
off
from
some
of
the
competitors
I
showed
in
the
previous
slide.
This
feature
was
only
in
the
product
due
to
some
really
great
work
of
a
few
designers
here
at
gitlab.
A
So
I
had
a
great
foundation
to
start
iterating
and
building
on
one
of
the
first
items
needed
in
roadmaps
to
make
them
for
more
useful
for
planning
is
showing
progress
of
planned
work.
We
already
allowed
users
to
see
how
their
epics
maps
on
the
timeline
as
you
saw
before,
but
they
had
no
context
as
to
how
these
epics
were
progressing.
A
A
I
then
chatted
through
this
with
austin
jeremy,
who
you'll
hear
from
later,
and
we
ideated
on
how
this
could
look.
The
mvc
we
landed
on
was
adding
a
progress
bar
as
its
own
object
on
the
epic
bars
themselves.
The
progress
metric
here
is
based
on
weight
at
the
moment,
but
in
the
future
we
may
allow
users
to
configure
this
by
maybe
issue
completion,
or
maybe
some
other
metric
in
the
future.
A
This
gives
users
even
more
context
as
to
how
their
work
is
progressing
and
if
everything
looks
on
track
to
hit
a
milestone
or
a
higher
level
goal
in
general,
I
talked
more
in
depth
about
milestones
during
our
last
showcase
about
time,
boxes
and
sprints,
but
short
version
is
that
we
use
milestones
a
bit
differently
than
other
products.
We
allow
users
to
specify
a
start
date
and
an
end
date
or
both
or
neither
many
other
roadmaps
represent
milestones
as
one
point
in
time.
So
it's
like
a
milestone
marker
on
a
road.
A
This
led
to
some
interesting
design
challenges.
I
did
some
competitive
analysis
here
again
and
I
thought
about
how
we
could
display
milestones
if
we
displayed
only
the
due
date
at
the
first
level.
I
got
feedback
here
that
we
need
to
display
both
start
and
end
date
for
mvc.
A
Also,
we
have
many
constraints
in
general
around
how
we
fetch
the
entire
group's
milestones
in
our
roadmap
and
it
scrolls
horizontally
kind
of
seemingly
infinitely
so
there's
some
performance
issues
there.
So
we
decided
we
wanted
to
start
start
very
small
and
we'll
gather
feedback
around
this
we'll
do
more
research
on
more
coming
improvements
on
things
like
pinning
milestones
to
the
top
hiding
milestones
and
even
just
improving
milestones
visually
in
general.
A
The
last
improvement
I'll
touch
on
I'm
trying
to
speed
through
this
is
allowing
users
to
view
the
hierarchy
of
their
work
in
the
roadmap
in
general.
So
nbc
here
is
displaying
the
child
epics
that
live
within
each
parent.
Epic,
as
epics,
are
the
only
item
within
the
roadmap.
Currently,
the
main
objective
here
is
to
allow
users
to
dig
into
a
larger
goal,
so
in
epic
and
view
more
granularly
the
progress
and
status
of
the
items
that
will
help
them
complete
that
goal.
So
again,
this
ties
back
to
that
job.
A
This
was
a
big
request
overall
and
appeared
many
times
in
our
research.
So,
like
I
said
as
again,
it
helps
our
users
communicate
status
of
their
work
to
stakeholders
at
different
views,
so
it
will
become
increasingly
important,
as
we
add
items
like
issues
and
we're
also
working
on
tasks,
so
those
could
be
displayed
in
the
roadmap
at
a
hierarchy
level
as
well.
A
A
I'd
like
to
iterate
on
the
way
we
view
information
about
items
in
the
roadmap,
so
milestones
epics
in
the
future
issues
and
tasks.
So
I
would
like
to
allow
users
to
view
more
information
without
ripping
them
out
of
the
context
of
their
roadmap
themselves
by
like
either
opening
a
new
tab
or
going
to
another
view
overall,
but
actually,
I
would
also
like
to
work
through
how
we
allow
users
to
set
time
frames
on
the
roadmap,
because
I
touched
on
before
we're
having
some
performance
issues.
Given
the
amount
of
stuff
we
fetch
on
load.
A
So
eventually
we
would
like
to
have
users
set
their
own
time
frames
that
they
want
to
focus
on
and
then
maybe
even
more
future
scope
would
be
allowing
them
to
kind
of
brush
and
zoom
within
that.
So
I
will
definitely
be
pinging.
Some
analytics
minded
folks
around
that
and
just
visual
improvements
as
well
reorganizing,
the
left
column,
thinking
about
initiatives
or
how
to
display
teams
or
groups
within
the
roadmap
as
well.
So
that
is
roadmaps
in
a
nutshell.
I
am
going
to
hand
it
over
to
holly
to
talk
about
jira
importer.
B
B
So,
let's
start
with
the
problem
that
we're
addressing.
We
believe
that
we
need
to
provide
users
who
are
considering
adopting
gitlab
as
their
project
management
tool
with
a
way
to
quickly
import
jira
project
data
within
the
product,
so
they
can
explore
its
features
in
a
way
that
will
most
simulate
their
day-to-day
tracking.
B
So
the
goal
of
the
importer
is
to
allow
proper
mapping
of
jira
users
and
their
issue
activity
to
the
corresponding
gitlab
user.
This
will
ensure
that
the
importer
successfully
recreates
historical,
accurate
jira
issues
within
our
product,
so
the
mvc
concepts
that
we're
exploring
here
are
really
just
going
to
be
the
first
step
in
providing
that
additional
support
for
users
when
migrating
data
from
jira
to
get
lab,
including
the
long-term
vision
of
offering
user
mapping,
support
for
mapping
of
custom
fields,
traceability
reports
and
more
jira
commands
34
of
the
market
share.
B
So
while
we
don't
currently
have
sufficient
product
capabilities
to
satisfy
the
full
gamut
of
business
use
cases
riding
this
importer
first
enables
us
to
use
adoption
rates
as
kind
of
a
barometer
and
leading
indicator.
When
we
start
reaching
the
inflection
point
of
making
a
tangible
dent
in
jira's
dominance
within
the
marketplace,.
B
B
So
I
created
a
couple
of
flows
and
showed
how
they
tied
together,
and
this
included
the
user,
creating
an
import
from
a
jira
product
project
into
an
existing
gitlab
project
and
then
separately,
when
creating
a
new
gitlab
project
and
also
doing
an
import
at
the
same
time.
So
this
flow
just
kind
of
outlines
that,
and
I
think
that
I've
got
a
link
in
in
the
slides
here
to
this
flow
and
to
my
other
whimsical
screens.
If
anyone
wants
to
look
at
those
at
a
little
bit
of
a
deeper
level.
B
So
I
got
to
work
with
a
couple
of
other
stage
groups
on
this
one
which
is
really
exciting.
I
always
love
that
daniel
who
is
over
the
import
section
in
manage.
He
and
I
work
together
to
talk
about
how
that
import
process
needs
to
complement
one
another,
because
I
was
working
on
the
import
from
the
issues
list
screen
and
he
was
handling
imports
from
the
actual
new
project
standpoint.
B
So
we
worked
together
on
that
also
worked
with
libor
on
the
verify
team
because
he
was
making
some
changes
to
the
jira
integration
screen
and
collaborated
on
how
our
pieces
might
fit
together.
So
that
was
that
was
a
really
good
activity
to
do
also
collaborated,
frequently
with
my
project
manager
and
the
fe,
and
be
devs
to
iterate
on
those
wire
flows.
B
This
is
again,
this
is
very,
very
early
stages,
so
we
want
to
continue
to
learn
through
the
research
issue
that
we've
created
and
understand
what
the
value
will
be
to
the
user
in
terms
of
next
steps.
So
just
very
humble
beginnings
for
this
particular
feature
and
the
value
that
it
has
to
offer
initially
so
issues
or
imports
will
show
in
the
issues
list
with
a
predefined
scoped
label
in
a
format
that
includes
something
like
this.
B
But
what
we're
trying
to
convey
here
is
that
this
is
a
jira
import
and
then
the
jira
key,
which
is
represented
here
by
the
word
demo
and
then
a
time
stamp
date
and
time
stamp,
and
that
will
help
users
in
particular
to
know
what
project
they're
importing
from
that.
It's
a
jira
import
and
then
the
day
and
time
that
it
was
actually
imported,
which
is
a
in
particular.
If
you
do
multiple
imports
from
the
same
project
to
the
same
gitlab
project,
we
want
them
to
be
able
to
differentiate
between
those
imports.
B
So
that's
kind
of
the
vision
for
that
label.
Right
now
we
are
exploring
some
other
options,
such
as,
instead
of
a
date
and
time
stamp,
maybe
doing
a
number
that
just
adds
on
incrementally
as
they
import
more
and
more.
But
we
don't
expect
that
have
to
happen
very
often
so
we're
thinking
that
might
be
an
edge
case.
But
that's
something
also
that
we
want
to
understand
as
part
of
our
research.
B
So
for
next
steps
we're
planning
to
work
on
the
user
mapping
within
the
application
from
a
technical
standpoint,
there
are
also
lots
of
fields
that
we
want
to
understand
in
terms
of
value.
What
will
be
most
useful
for
the
users
to
get
first?
Would
it
be
something
like
comments
or
having
attachments
that
sort
of
thing?
B
So
we've
got
a
long
list
of
items
that
we're
having
users
rank
for
us
and
give
us
feedback
on
as
part
of
our
research,
to
help
us
to
know
what
is
going
to
be
most
valuable
in
terms
of
next
steps.
We
have
created
a
blog
post
entry.
Well,
it's
not
quite
on
the
blog
yet,
but
the
issue
has
been
created
for
it
to
get
added
to
the
blog
so
that
we
can
kind
of
raise
a
little
bit
more
interest
in
and
get
some
more
activity
in
terms
of
that
survey.
B
And
then
we
have
some
user
interviews
that
we're
hoping
to
go
through
to
understand
what
will
be
the
most
valuable
feature
again
for
us
to
explore
in
terms
of
next
steps
and
then
hopefully
creating
a
prototype
to
ensure
that
the
processes
such
as
merging
existing
issues
and
resolving
conflicts
between
imports
of
issues
can
be
seamless
and
I've
included
links,
of
course
here
to
the
research
issue
and
the
blog
post.
B
B
A
I
just
want
to
say,
like
someone
pinged,
I
think
karis
about
feedback
and
we
linked
our
issues
to
the
agenda.
So
of
course
always
feel
free
to
leave
feedback.