►
From YouTube: UX Showcase - Running a “mini” design sprint
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
hey,
my
name
is
matteo:
I'm
a
senior
product
designer
and
growth,
and
today
I
want
to
talk
about
a
recent
design.
Sprint
that
we
did
on
growth,
for
the
user's
dashboard
page
is
what
we
call
it,
and
that
would
be
the
page
that
loads
once
user
clicks
on
the
top
left
logo
in
the
main
nav
bar
and
with
this
work
didn't
start
out
being
a
design
sprint.
A
We
already
did
some
work
and
then,
in
the
middle
of
that
I
suggested
hey,
should
we
do
like
a
quick
design
sprint
for
this
with
a
small
team
just
to
you
know,
accelerate
it
a
bit
and
quickly
find
a
solution
and
possibly
validate
it,
and
everyone
was
up
for
it,
but
before
we
get
there,
we
this
is
the
work
that
we
did
previously.
So
we
defined
the
user
goals
right,
which
the
main
one
we
defined
was.
What
do
I
need
to
do
to
be
successful
in
my
role
in
this
company?
A
Slash,
team
right
and
then
there
are
sub
goals
which
one
of
the
main
one
was
have
an
overview
of,
what's
relevant
to
me
in
gitlab.
A
If
we
talk
from
the
user's
perspective
and
then
our
goals
as
well
right,
so
our
goals
that
would
be
gitlab
slash
growth
team,
what
these
goals
would
be,
and
the
main
one
for
for
us
in
this
case
is
driving
adoption
of
stages
of
gitlab,
which
then
increases
spo,
which
is
our
metric
for
measuring
our
success,
which
is
stages
per
organization
and
then
increase
conversion
which
helps
increase
arr,
which
is
our
main
goal
right
and
then
we
listed
some
key
steps
for
the
dev
leads
and
the
software
developers.
A
We
listed
out
some
possible
jobs
to
be
done,
that
we
wanted
to
focus
on,
and
we
also
started
listing
out
some
of
the
more
concrete
problems
of
the
dev
lead
users
and
software
development
users
as
well.
So
at
this
point
we
haven't
decided
which
user
we
wanted
to
focus
on.
Yet,
but
after
we
mapped
these
problems,
we
realized
that
pretty
much
all
of
them
were
on
the
side
of
the
dev
lid,
but
not
all
of
them
were
on
the
side
of
the
software
developer
right
there.
A
There
are
quite
a
few
of
them
that
are
only
on
the
left
side
of
this
chart.
So
once
we
did
this,
it
was
clear:
let's,
let's
focus
on
the
dead,
lead
user
and
we
also
needed
to
check
to
decide
which
job
to
be
done.
We
wanted
to
focus
on
so
we
already
said
okay
that
lead
and
we
wanted
to
focus
on
the
daily
check-in
job
to
be
done
not
setting
up
because
setting
up
in
this
case,
setting
up
this
dashboard
setting
up
of
an
account
on
on
gitlab.
A
Wasn't
that
important
to
us.
We
wanted
to
design
something
that
user
possibly
already
comes
to,
and
it
already
has
some
content.
It
already
has
some
value,
or
at
least
that
very
quickly
after
they
start
using
it.
It
gets
to
that
point
right,
so
we
wanted
to
focus
on
the
daily
check-in
job
to
be
done,
which
is
when
I'm
starting
work
for
the
day.
I
want
to
quickly
check
what
happened
in
my
team.
A
While
I
was
gone
so
that
I
can
help
my
team
be
productive,
so
this
was
all
the
stuff
that
we
did
before
we
decided
to
do
a
design
sprint,
and
then
I
suggested,
let's
do
like
a
minified
version
of
the
design
sprint.
So
we
accelerate
things.
We
could
quickly
come
up
with
a
solution
and
validate
it.
Everyone
was
up
for
it
everyone
at
this
point.
It
was
just
me
mike
the
product
manager
and
kevin
the
other
designer
that
worked
on
this
and
it's
the
the
goals
of
this
design.
A
Sprint
were
first,
the
main
one,
the
primary
one
which
was
designed
this
concept
right
solution
whatever
and
possibly
validate
it,
and
then
we
I
had
such
two
secondary
goals.
The
first
one
was.
I
wanted
to
prove
that
these
sprints
can
be
completed
in
a
matter
of
days
and
the
other
one
was.
I
wanted
to
prove
that
they
don't
need
to
be
scheduled
and
planned
well
ahead,
but
it's
something
that
can
be
done
at
hawk
in
a
way
right
and
I'll.
Tell
you
in
the
end
which
of
these
goals
we
achieved
successfully.
A
A
We
actually
had
three
synchronous
sessions
and
I
think,
a
couple
of
homeworks
for
each
of
the
participants.
We
started
on
a
monday
and
then
we
completed
design
sprint
on
wednesday
next
week,
where
we
had
the
feedback
calls.
So
we
showed
what
we
came
up
with
to
some
people
internally
and
that's
what
concluded
it
basically,
and
so
we
started
out
with
a
template
right
right:
let's
go
to
the
actual
template,
so.
B
A
The
template
that
we
prescribe
in
a
way
right
here
at
gitlab
for
design
sprints
and,
as
you
can
see,
there's
a
lot
of
stuff
here
right
workshop
series.
One
workshop
series:
two:
you
need
to
come
up
with
a
map
of
the
user
journey
challenges.
All
these
things
right.
A
The
key
thing
here
was:
we
already
had
some
of
these
things
done
and
kind
of
validated,
because
we
already
know
that
about
all
this
research
and
feedback
that
we
get
from
users
that
you
know
we
should
create
like
a
dashboard
or
something
for
them
which
would
eliminate
the
need
for
checking
email,
notifications
or
to-do's,
relying
on
to-do's
and
stuff
like
that.
A
So
what
I,
what
I
did
was
I
just
started:
removing
the
sections
in
this
design
sprint
template
that
I
thought
weren't
relevant
to
us
right.
I
wanted
to
minify
literally
this
design
sprint
and
I
minified
it
into
this.
Basically,
and
just
you
know
quickly,
glancing
at
it,
it
looks
way
smaller,
less,
don't
think
so.
A
I
was
happy
with
that,
and
then
I
prepared
that
plan,
which
I
already
showed
you
and
we
were
ready
to
start
sprinting,
basically
right
and
as
as
we
said,
we
already
had
identified
problems
we
wanted
to
solve
as
some
pre-design
sprint
homework
for
our
participants.
I
asked
them
hey:
can
you
go
into
the
mural
and
start
putting
some
stickies
into
the
first
section?
The
promise
to
solve?
A
You
know
the
ones
that
you
think
are
important,
the
ones
we
identified
through
the
work
we've
already
done
and
then
on
the
day
of
the
design
sprint
before
the
synchronous
session,
I
went
in
and
started
doing
some
affinity
mapping,
so
I
grouped
them
into
a
couple
of
groups
and
we
started
the
design
sprint
by
simply
discussing
these
right,
going
through
them,
acknowledging
them
discussing
them
and
basically
getting
everyone
else
caught
up,
because
we
had
some
new
participants
that
weren't
involved
with
the
work
from
before.
A
So
then
we
had
to
translate
these
problems
into
challenges
right
and
we
do
this
by
framing.
How
might
we
questions
and
we
came
up
with
quite
a
lot
of
them
and
again
we
did
some
affinity
mapping
here
again.
We
did
this
on
the
synchronous
session
and
everyone
was
just
moving
post-it
notes
around.
It
was
quite
cool
and
in
the
end
we
voted
right.
We
voted
on
the
things
that
we
thought
were
the
most
important
things
to
solve
in
this
design
sprint
and
we
ended
up
with
four
top
voted.
A
How
might
we
right-
and
these
four
were,
how
might
we
allow
users
to
designate
and
track
high
priority
issues
and
merge
requests?
How
might
we
show
the
dev
lead
users
what's
urgent
immediately
without
email
scanning?
How
might
we
make
to-do's
as
useful
as
email
notifications
and
how
might
we
create
the
concept
of
a
team?
A
In
the
end,
we
focused
more
on
these
two.
These
two
were
more
outside
of
the
immediate
area
of
focus,
because
to-do's
is
something
that
is
very
much
related
to
the
work
that
we
are
working
on,
but
we
weren't
sure
if
we
wanted
to
actually
tackle
that
big
problem.
You
know
we
all
know
that
the
to-do's
are
quite
problematic
here
at
gitlab
and
then
creating
the
concept
of
a
team.
A
We
weren't
really
sure
about
that,
because
we
already
had
the
groups
and
projects
and
that
structure
isn't
very
clear
to
our
users
already
and
adding
another
layer.
On
top
of
that
complexity,
we
just
weren't
sure
so
we
kind
of
naturally
gravitated
towards
these
two
and
then
this
actually
completed
the
first
synchronous
session.
A
Then
we
had
some
homework
right
and
this
was
the
lightning
demos
we
asked
each
of
each
participant
to
find
a
couple
of
examples
of
dashboards
that
they
really
liked-
and
you
know,
put
down
some
notes
about
these,
so
each
participant
did
that
this
was
completely
asynchronous
and
then
other
participants
would
go
and
take
a
look
at
what
was
posted
in
there.
We.
A
So
when
each
participant
completed
their
homework,
they
would
post
in
the
slack
channel
and
say
hey,
you
can
go
and
take
a
look
at
my
stuff
and
then
the
other
part
of
the
homework
was
actually
concept
sketching
right.
So
the
instructions
are
here.
So
we
didn't
check
how
each
of
the
participants
actually
approached
this
concept
sketching.
We
just
ask
them
to
you
know
when
you
come
up
with
something
put
it
here
in
the
concept
gallery.
Your
sketch,
your
mock-up
wireframe
whatever
and
we'll
discuss
this
in
the
next
synchronous
session
right.
A
So
I
think
all
of
the
participants
actually
sketched
a
couple
of
things.
A
few
of
them
sketched
sketched
multiple
concepts
and
that
was
really
cool.
So
we
started
the
next
synchronous
session
by
just
reviewing
these,
so
these
were
meant
to
be
done
anonymously,
but
we
all
agreed.
You
know
that
we
were
ready
to
share
and
expose
which
of
the
concepts
were
ours
and
just
present
them
a
bit
more
so
that
we
don't
evaluate
them
without
the
context
or
without
the
ideas
behind
it.
A
So
we
did
that
each
of
the
participants
presented
their
their
mock-ups
their
sketches,
and
after
that
we
decided
to
vote
on
them.
But
we
decided
to
vote
on
the
overall
concept
and
on
the
a
particular
area
that
you
possibly
liked
from
a
different
concept
right.
We
each
each
of
us
had
two
votes
and
of
course
we
also
had
the
decider
role
which
mike,
who
was
the
product
manager.
Had
you
can
see
the
two
smiley
votes?
Those
were
his
votes.
A
These
were
the
deciding
votes
in
a
way,
so
he
voted
on
an
overall
concept
of
having
a
flexible
dashboard
where
you
can
possibly
add
or
remove
widgets
and
restructure
the
layout
stuff
like
that,
and
then
a
triaging
sort
of
feature
where
the
user
can
go
through
the
activity
or
to
the
dimensions,
and
then
they
can
say
this
is
important.
This
is
not
important
to
remove
it.
Something
like
that
right.
A
So
we
had
enough
to
then
for
a
designer
to
take
over
and
just
create
either
a
mock-up
or
a
really
early
stage
prototype.
So
kevin
did
some
extra
work
on
top
of
that
and
put
some
content
into
this
really
basic
map
of
what
the
solution
should
be
and
he
created.
So
these
are
the
feedback
nodes
he
created
this
basically.
A
So
this
is
the
concept
that
we're
now
working
on
for
the
user's
dashboard.
You
can
see
the
activity
digest,
widget,
where
he
they
have
like
a
mentions
tab
and
the
activity
tab.
They
can
switch
between
the
two.
They
can
possibly
filter
them
right.
We
offer
them
some
tips.
We
offer
them
recently
viewed
items
because
you
know
just
from
speaking
to
users
and
a
lot
of
feedback
comes
back
to
us.
A
You
know
they
always
navigate
to
certain
things
and
it's
sometimes
hard
to
find
them
in
gitlab,
so
something
like
that
would
probably
be
really
useful
and
then
we're
also
in
contact
with
marcel
and
his
team,
and
he
just
created
recently
this
cool
mac
app
that
lives
in
your
toolbar.
I
think
it's
called
on
max
and
recently
viewed
items.
A
There
are,
I
think
he
said
the
most
popular
they
get
a
lot
of
traffic,
but
then
what
we
started
exploring
was
this
possibility
of
triaging
stuff
right,
so
you
would
be
able
to
say,
or
a
user
would
be
able
to
say,
pin
this
to
my
priorities.
I
need
to
do
something
about
this
right,
so
they
would
click
on
it
and
it
would
land
here
you
scroll,
and
it
remains
there
right.
A
This
was
the
the
riskiest
thing
that
we
were
exploring
in
a
way
right,
and
we
then
showed
this
in
the
last
synchronous
session
to
a
few
of
the
gitlab
team
members
free
and
the
feedback
was
really
positive
and
something
that
was
really
good,
really
cool
for
us
was
this
level
of
excitement.
That
was
obvious
from
all
the
participants
because
they
were
like.
Oh,
I
could
actually
use
this.
A
This
would
replace
the
need
for
me
going
to
email
and
scanning
to
all
the
content
that
is
most
of
it
is
not
relevant
to
me,
and
I
could
just
you
know
possibly
have
multiple
activity
digest.
Widgets
filter
them
differently,
because
I
manage
multiple
teams
and
then
I
could
add
or
remove
stuff
from
my
priorities
right.
I
could
have
everything
in
one
screen
in
a
way,
so
the
feedback
was
really
positive.
We
decided,
okay,
let's
get
some
feedback
from
external
gitlab
users
as
well,
and
that
was
really
positive
as
well.
A
It
was
there
and
but
not
as
much
as
with
with
the
internal
people
that
we
tested
this
with
right.
So
one
of
the
assumption
is
why
there
isn't
that
level
of
excitement
is
we
we
really
need
to
find
the
right
users
to
test
with,
because
this
is
a
feature
if
we
want
to
call
it
like
that.
That
is
most
useful
when
you're
working
in
a
team
and
possibly
have
multiple
projects,
and
you
need
to
be
a
manager
as
well.
A
So
this
is
basically
where
we're
at
with
this
user
users,
dashboard
concept,
and
now
the
next
steps
is
basically
deciding
what
the
mvc
is.
We
kind
of
already
did
that
we
are
thinking
about
just
defaulting
this
dashboard,
this
home
page
to
the
to-do's
and
see
if
we
can
raise
the
engagement
with
that
page
compared
to
the
current
default
dashboard
page,
which
is
just
a
list
of
projects
right
which
isn't
very
useful,
and
then
we
have
a
couple
of
ideas
for
follow-up
experiments.
A
But
how
do
we
test
this
riskiest?
Assumption
of
you
know
pinning
stuff
to
your
priorities?
Maybe
we
could
run
another
painted
door
experiments
it's
what
they're
called
where
we
would.
Basically,
just
you
know,
add
this
icon
to
the
ui.
We
would
show
the
the
tooltip
as
well,
but
once
the
user
clicks,
we
tell
them
hey.
This
is
actually
not
ready.
We're
just
measuring
you
know
the
interest
in
this
by
measuring
engagement,
and
if
it
has
enough
interest
in
enough
engagement,
we
will
actually
decide
to
work
on
this
right.
A
That
could
be
a
way,
but
we're
not
we're
not
sure
yet.
So
that's
it
for
you
know
where
we're
at
with
dashboard.
A
If
we
go
back
to
the
three
goals
that
I
mentioned
at
the
beginning,
the
first
one,
the
primary
one,
was
come
up
with
a
solution
for
end
of
vision
for
the
dashboard
and
possibly
validate
it,
and
we
were
really
happy
with
the
solution
that
we
came
up
with.
We
validated
it
as
well.
We
were
really
happy
with
the
result.
A
The
secondary
ones
prove
that
the
design
sprints
can
be
done
in
a
couple
of
days.
I
was
happy
with
this
one,
because,
even
though
we
started
on
a
monday
and
completed
that
sprint
on
a
wednesday
next
with
a
week
after
it
actually
was
just
freezing
sessions
which
lasted
for
two
hours
and
a
couple
of
homeworks
for
the
participants
right,
this
could
actually
be
done
if
most
of
the
most
of
the
work
was
synchronous.
A
This
could
be
done
in
two
days,
free
max
and
then
the
last
one
proved
that
this
design
sprints
don't
need
to
be
scheduled
and
planned.
Well
ahead,
so
we
weren't
able
to
prove
this
one,
because
we
expanded
the
team
from
the
three
initial
participants
to
five
and
then
that
was
it
was
much
harder
to
find
time
slots
for
the
sync
servicing
sessions
right.
A
So
we
had
to
move
the
design
sprint
from
the
beginning
of
september
to
the
end
of
september,
but
maybe
in
the
next
sprint
that
we
do
maybe
I'll
be
able
to
to
prove
that
so
yeah.
I
wanted.
I
really
wanted
to
prove
these
things,
because
I
don't
know,
there's
this
general
belief
that
design
sprints
are
things
that
you
only
do
occasionally
and
possibly
because
they're
these
complex
things
that
usually
take
two
weeks.
A
So
I
wanted
to
kind
of
break
through
that
mentality,
and
you
know
just
prove
hey.
Maybe
you
have
some
work
already
done.
You
don't
need
to
do
a
full
sprint.
You
need
to
you,
can
just
minify
it
and
just
say:
let's
do
it
with
a
small
team
and
let's
try
to
do
it
in
three
days
and
you
know
really
accelerate
this
to
get
some
momentum
going
right.
So
yeah,
that's
that's
it!
That's
where
we
are.
A
We
are
and
I'd
love
to
hear
your
thoughts
about
what
we
came
up
with
for
the
for
the
user's
dashboard
as
well.
As
you
know,
what
do
you
think
about
design
springs?
Do
they
really
need
to
be
these
huge,
complex
things
that
take
one
to
two
weeks?
Do
you
really
need
to
schedule
them
well
ahead
and
things
like
that.
C
E
A
Yeah
yeah,
I
mean
if
we,
if
we're,
sometimes
we're
not
as
ready
to
do
synchronous
sessions
right
at
gitlab.
We
we
prefer
to
do
stuff
asynchronously,
if
possible,
but
in
in
the
case
of
design
sprints.
If
you
are
able
to
do
most
of
it
synchronously,
you
can
actually
speed
it
up
quite
a
bit
and
do
it
in
two
or
three
days,
especially
if
you,
if
you
need
to
minify
it
or
you
can
minify
it
in
a
way
like
this.
D
A
A
You
know
everyone
to
know
that
it's
okay
to
remove
stuff
from
templates,
even
if
we
prescribe
some
of
these
templates
for
certain
things
right,
you
don't
need
to
do
the
whole
thing,
especially
if
you're
confident
about
the
work
you
already
did
and
you
feel
like.
Okay,
we
really
don't
need
all
this
stuff,
just
remove
it
and
keep
moving
forward.
I
would
say.
E
I
I'm
hesitant
to
remove
certain
parts,
because
maybe
they
will
the
team
might
be
starting
very
preliminarily.
So
I
like
the
idea
that
you're
able
to
recognize
when
you
can
remove
something.
That's
the
hard
part,
though,
how
do
you
recognize
when
you're
able
to
remove
something
yeah
but
iterate?
You
know
by
all
means.
F
I
wonder
because
the
design
sprint
seems
so
valuable,
maybe
even
putting
what
you
just
said,
justin
in
the
larger
template,
which
is
take
out
what
you
don't
want
to
use,
because
even
mate
who
did
it,
it
sounds
like
he
kind
of
had
to
think
about
it
edge
like.
Is
this
all
right?
Well,
yeah!
It's
all
right!
Let's
just
tell
everybody,
it's
all
right.
What
makes
sense
here.
A
Yeah
we
could
either
put
it
in
the
template
itself
or
somewhere
in
the
remote
design,
sprint
page.
We
have
in
the
handbook,
I
think,
there's
another
page.
I
think
I
found
it
when
I
was
looking
up
stuff,
but
even
this
one
is
quite
long
and
there's
another.
I
think
template
for
an
issue
which
is
quite
long
as
well,
and
here
it
says
we
recommend
keeping
your
remote
design
sprints
to
two
weeks
or
less.
E
D
That's
okay!
I
I'll
just
jump
in.
I
have
one
quick
note
and
then
we
can
go
to
your
yours.
I
just
made
a
quick
note
in
the
agenda
that
tim
noah
is
doing
another
one
of
these
sprints
he's
just
starting
at
now
and
he's
making
like
some
small
changes
to
it,
based
on
what
he
needs
for
the
particular
problem.
He's
working
on,
so
we'll
get
more
feedback
pretty
soon.
B
Just
to
add
just
before
I
don't
know
who
else
was
going
to
talk
it,
I
don't
think
we
can
prove
mate's
assumption
of
the
the
couple
of
days
just
because
of
the
nature
of
the
people
that
we're
going
to
be
including,
but
I
think
we're
going
to
adapt
it
to
our
needs
because
we're
going
to
be
doing
sales,
support,
reps
and
so
forth,
so
yeah
it
will
be
slightly
different,
but
I'm
looking
forward
to
using
this
template.
Thank
you.
Mate.
A
I
wasn't
the
one
who
created
it.
I
I
just
noticed
that
it
was.
It
was
a
link
from
this
page.
I
think-
and
I
said
this
is
perfect.
This
is
perfect
as
a
starting
point
and
then
you
know
when
I
reviewed
it,
it
looked
a
bit
big.
I
said
we
already
did
this.
We
didn't
need
that
and
I
started
knowing
stuff
right.
I
don't
know
who
prepared
it.
E
This
write-up
was
multiple
people,
but
it's
based
on
the
template.
So
if
anyone
has
questions
about
anything
on
how
it's
supposed
to
work
or
anything
like
that,
let
me
know.
C
Yeah
semantics
again
christy,
but
the
term
design
sprint.
I
think,
really
helps
us
sort
of
guide
exactly
what
matteo's
talking
about
which
is
generating
and
eliminating
ideas
as
quick
as
possible.
Whatever
that
suits
your
needs,
I
mean,
if
you
have
a
couple
of
weeks
and
a
lot
of
people
to
do
it
in
and
and
the
project
needs
it.
Why
not?
C
But
if
the
idea
is
just
to
quickly
move
on
to
the
next
phase,
then
I
think
adapting
which
is
exactly
what
happened
here
is
is
exactly
what
the
doctor
called
for.
D
Yep,
that's
well
said,
let
me
stop
recording,
we
need
to
move
on.