►
From YouTube: UX Showcase - Environments 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
Awesome
hi
everyone,
I'm
Emily,
I'm,
the
senior
product
designer
on
the
environments
team
and
today,
at
the
York
showcase
I
wanted
to
go
over
a
design
Sprint.
We
did
in
environments
about
a
month
ago
that
went
really
well
and
I
want
to
share
kind
of
like
our
process
and
what
came
out
of
that.
A
So
the
first
thing
is
kind
of
went
the
start
of
June
2023.
We
did
the
first
design
Sprint
in
the
environments
team,
and
this
is
how
it
went,
but
before
I
get
into
that,
what
is
a
design
Sprint
for
those
of
you
who
haven't
done
one
before
so
a
design
Sprint
is
typically
a
five-day
process
for
solving
problems
through
design,
prototyping
and
testing
ideas
with
customers.
A
This
process
came
out
of
Google
from
Jake
Knapp
in
2010
building
products
like
Gmail
and
hangouts,
and
then
he
kind
of
refined
that
process
in
2010
to
2012,
with
things
like
Chrome
search
and
such
and
this
all
came
out
of
the
Sprint
book
from
Jake
Knapp.
So
if
you
haven't
read
this
book
before
I
highly
recommend
it,
but
basically
design
Sprints
go
from
developing
like
this,
where
you
have
an
idea.
A
Take
a
long
time
to
develop
your
launch,
take
a
long
time
to
get
data
to
go
from
getting
an
idea
to
getting
data
and
doing
that
cycle
quickly,
but
the
too
long
didn't
read
version
of
this
is
design.
A
Sprints
help
us
figure
out
what
we
should
build
and
answer
the
question:
are
we
on
the
right
track
to
making
a
product
users
will
want
to
use
so
to
give
some
background
on
why
the
environments
team
decided
to
do
a
Sprint
I
just
want
to
do
a
quick
overview
of
what
environments
are
for
those
of
you
who
haven't
worked
in
this
area
before
environments
are
described
as
a
place
where
code
is
deployed
and
each
time
each
time,
gitlab
CI
CD
deploys
a
version
of
code
to
an
environment.
A
A
deployment
is
created
so
right
now
our
environments
feature
is
very
focused
in
on,
like
the
deployments
going
into
the
environments,
we
have
a
very
kind
of
simple
UI.
We
have
had
a
lot
of
problems
with
the
Cy,
both
from
an
accessibility
perspective
and
a
feature
perspective.
What
we
offer
our
users,
which
I'll
be
getting
into
in
a
bit,
but
basically
we
wanted
to
Sprint,
because
we
want
to
position
environments
as
a
central
place
to
gather
all
delivery
related
information
for
git
lab.
A
So
we
want
to
rethink
the
role
of
environments
and
build
on
the
knowledge
we've
kind
of
gathered
over
the
past
years
and
how
users
use
projects
and
groups
with
this
workflow
and
kind
of
like
as
source
code
Mrs
are
Central
to
a
Dev
organization.
Environment
should
be
Central
to
devsecops
organization,
and
today
our
environments
feature
kind
of
falls
short
of
this
expectation.
It
was
built
more
as
like
a
gitlab
CI
extension.
A
So
how
did
this
design
Sprint
go
so
I
kind
of
I've
done
design
Sprints
in
the
past,
never
done
one
in
an
async
company,
but
I've
kind
of
adjusted
it
to
work
in
just
four
days
instead
of
the
five
day
typical
one.
So
we
did
day
one
two
and
three
together
and
then
day.
Four
is
happening
at
a
later
date.
A
The
Sprint
team
consisted
of
eight
volunteers
here,
you'll
notice.
One
of
these
volunteers
is
actually
not
a
git
lab
team
member.
If
we
got
a
customer
to
participate
in
all
three
days
of
the
Sprint,
which
was
really
really
cool
to
have
customer
Insight
kind
of
24
7
throughout
the
Sprint,
so
that
was
something
that
was
really
different
with
this.
A
The
other
thing
that
had
was
a
whole
lot
of
time
zones.
There
was
17
hours
between
most
East
and
most
West,
so
making
this
work,
for
everyone
was
a
little
bit
complicated,
but
thankfully
people
kind
of
stepped
out
of
their
time
zones-
I
woke
up
earlier
Australia
had
to
stay
later,
but
we
were
able
to
meet
both
sink
and
async,
which
was
really
cool
but
yeah.
It
went
great,
so
we
first
started
with
sharing
knowledge,
so
we
got
everyone
to
kind
of
record
some
videos
to
share
what
they
knew
about.
A
The
environments
feature
the
problems
it
has.
This
was
very,
very
useful,
coming
from
our
customer
to
participating
in
this,
and
then
we
kind
of
used
those
recordings
to
really
focus
down
on
what
problem.
A
We
wanted
to
solve
and
what
the
goal
for
the
Sprint
would
be,
and
then
we
work
together
as
a
team
to
kind
of
ideate
on
different
solutions
to
go
forward
with
the
environments
so
doing
activities
like
this
crazy,
eight
sketching
exercise,
and
then
we
prototyped
that
out
had
a
bunch
of
great
conversations
about
what
we
landed
on
and
kind
of
moved
into
testing,
and
we
created
that
testing
plan
together
too
in
mural,
so
that
everyone
had
on
the
team
had
a
chance
to
kind
of
like
put
the
questions
they
wanted
to
ask.
A
And
then
this
is
the
funniest
part
of
it
a
lot
of
times
when
you
ask
people
to
draw
people
do
not
want
to
draw
so
I
found.
This
activity
works
really
well,
where
you
just
get
people
to
scribble,
and
then
you
turn
a
scribble
into
a
bird
and
I
think
that
is
actually
what
helped
us
get.
This
sketching
exercise
to
work
so
well,
so
we
drew
some
chaotic
Birds,
but
that
really
landed
us
into
a
great
sketching
exercise
where
everyone
participated
and
then
yeah.
A
We
landed
on
this
New
Concept
for
environments,
which
is
very
service,
focused,
so
you're,
focusing
on
your
service
as
it
moves
through
environments
instead
of
the
environments
and
deployments
themselves.
So
you
can
see
an
overview
of
all
your
services,
how
they're
doing
and
then
dig
into
those
services
and
see
how
they're
kind
of
their
health
status
the
deployments
going
into
them
throughout
each
environment
and
yeah.
A
This
New
Concept
kind
of
thinks
of
environments,
more
three-dimensional
with
the
introduction
of
services
so
before
we
really
just
had
a
deployment
going
through
Dev
prod
QA
staging
your
environments
with
the
introduction
of
a
service
concept.
Now
you
can
kind
of
follow
a
service
as
it
moves
through.
You
have
a
much
better
overview
of
kind
of
what
is
going
on
with
your
application,
as
it
goes
through
environments
and
there's
a
lot
more
data
to
kind
of
track,
and
this
really
aligns
with
the
workflow.
A
Our
users
were
wanting
and
yeah
I
wanted
to
go
into
a
little
bit
of
the
biggest
takeaways
for
running
a
Sprint
as
well.
The
top
one
we
realized
is
partnership
between
product
and
ux
was
really
imperative,
so
I
have
to
give
a
big
thank
you
to
Victor
on
this.
It
was
his
idea
to
run
the
Sprint,
but
having
the
good
partnership
really
helped
us
run
it
smoothly.
He
got
buy-in
from
engineering
to
join
other
team
members.
A
I
put
together
the
activities
and
running
it
together
was
a
lot
easier
than
just
running
it
solo
as
a
designer
proper
time
zone
planning
is
important.
This
is
something
I
learned
really
early
on.
A
good
example
of
this
is
my
day
starts
after
Australia's
day
ends,
so
just
giving
people
a
full
24
hours
to
do.
Async
activities
meant
buffering
an
extra
day
in
with
the
Sprint,
and
because
we
did
that
I
would
then
try
and
post
a
Sprint
overview
at
the
start
of
the
first
person's
time
zone.
A
So
everyone
had
the
appropriate
amount
of
time
and
no
one
was
kind
of
cut
short
get
a
customer
to
join
the
Sprint.
This
was
probably
one
of
the
biggest
successes
we
had
a
gitlab
customer
join
us
for
all
the
activities
he
was
really
instrumental
in
having
us
land
in
the
concept
where
we
were
and
kind
of
giving
an
overview
of
what
was
not
working
for
him
with
environments
which
really
factored
into
what
wasn't
working
that
we
had
learned
in
the
past
and
we
got
this
customer
to
join.
A
This
is
someone
Victor
reached
out
to
and
asked,
and
he
was
happy
to
join
in
this-
is
an
area
of
git
lab.
He
really
wanted
us
to
improve,
so
he
was
just
happy
to
join
in
with
that
and
then
take
advantage
of
internal
users.
So,
on
day,
three
of
the
Sprint
we
actually
broke
off
into
partners
and
each
partner
group
went
and
interviewed
someone
in
gitlab.
A
So
we
had
three
interviews
happen
the
day
of
day
three
and
they
were
internal,
get
lab
users,
but
we
got
a
lot
of
great
information
from
them
very
quickly
without
having
to
go
through
any
recruitment
and
then
what
we
learned
is
this
kind
of
goes
against
gitlab.
So
maybe
this
is
a
bit
controversial,
but
we
found
out
for
a
design
Sprint.
Sometimes
you
need
to
meet
sync.
We
found
some
of
the
conversations
we
had
in
these
shorter
sync
meetings.
A
We
tried
to
keep
them
to
an
hour
to
two
hours
a
day,
not
more.
It
was
going
to
be
hard
to
mimic
in
an
asynchronous
way
so
well,
we
did
most
of
the
Sprint
async.
There
were
a
few
things
that
we
really
wanted
to
sync,
including
conversations
about
the
Prototype
conversations
about
the
ideation.
Those
are
a
bit
harder
to
do
and
I've
linked
the
Sprint
YouTube
playlist
down
there,
so
yeah.
The
next
steps
for
this
is
we're.
Gonna
make
a
plan
for
user
testing.
A
This
concept
more
intensively,
just
making
sure
this
aligns
with
all
the
personas
for
the
environments
group
and
not
just
the
one
customer
that
kind
of
came
to
our
design
Sprint
and
get
a
better
idea
of
how
to
break
it
down.
Because
right
now
we
have
a
North
star,
but
we
really
need
to
figure
out.
What
is
the
smallest
thing?
We
can
do
first
to
get
this
out
and
then
the
next
thing
is
because
the
Sprint
was
very,
it
was
run
pretty
good.
A
We
had
a
lot
of
good
feedback
in
the
Retro
I'm,
going
to
add
some
of
my
learnings
to
our
handbook,
page
around
Sprints
and
maybe
put
up
through,
like
slides
templates.
I
noticed
we
didn't
have
those
before
to
share
with
the
broader
ux
team,
and
then
maybe
I
was
talking
with
my
own
team,
about
this
put
together
a
small
design,
Sprint
training
document
and
see,
if
anyone's
interested
in
that,
and
then
I
just
dropped
some
additional
Links
at
the
end
of
this.
A
And
I'll
give
a
few
bit
of
time
to
add
questions,
but
I
asked
vetica
Well
Chrissy
about
yours
is
read
only
so
I'll
give
it
to
vitica
First.
B
I
really
agree
with
what
Christie
mentioned,
and
while
we
were
sharing
this
with
me,
as
you
were
doing,
this
print
I
was
so
impressed
and
also
inspired,
because
we
don't
often
think
about
how
to
kind
of
re-look
at
the
concepts
that
we
have
been
working
on
day
in
and
day
out,
but
it's
so
important,
like
zoom
out
sometimes
and
focus
on
the
job
that
we
are
allowing
users
to
do
so.
B
This
is
great,
and
one
thing
that
I
really
started
to
think
about
was
that
if
we
are
really
looking
at
how
we
are
presenting
information
about
the
environments,
that
would
also
touch
upon
many
different
things,
which
are
very
closely
associated
with
environments
such
as
variables,
the
pipelines
that
are
running
for
each
of
the
environments
which
are
specific
to
them.
B
Then
the
runners
which
are
configured
for
those
environments
and
I'm
just
like
thinking
if
there
was
any
consideration
or
any
plan
in
mind
to
kind
of
Loop
in
other
teams
to
have
those
discussions.
I
know
that
Ben
is
going
next,
but
I
was
looking
at
his
the
mapping
of
jobs
to
be
done.
I
think
that's
going
to
make
it
really
easy
to
kind
of
identify
it
which
of
the
teams
are
which
of
the
groups
are
going
to
be
impacted
by
any
change
that
happens
for
this
so
yeah.
Is
there
anything.
A
That's
a
good
question
so,
to
give
some
background,
currently
we
were
running
through,
like
some
tech
discovery
meetings
with
the
team
just
to
see
how
feasible
some
of
these
changes
will
be
and
part
of
those
Tech
discovery.
Meetings
are
really
understanding
like
what
back
end
kind
of
like
the
back
end
team
really
has
to
be
cognizant
about
who
they
have
to
reach
out
to,
because
some
of
these
changes
will
affect
other
stage
groups.
A
So,
while
we're
building
out
this
prototype,
the
engineering
team
is
also
taking
a
look
at
we're,
adding
in
A
New
Concept.
How
do
we
add
in
that
New
Concept,
and
what
all
is
it
going
to
affect?
So
we'll
probably
have
more
details
on
that
in
a
bit
later,
we
have
been
meeting
about
it
once
a
week
to
kind
of
discuss,
so
I'll
be
happy
to
share
when
I'm
sure
it'll
affect
the
kind
of
like
verify
team,
so
I'll
reach
out
when
we
can
figure
out
more
about
that.
B
Yeah
I'm
curious
to
know
what
you
do
differently.
If
you
were
to
do
another
design,
Sprint
I
feel
like
I've,
never
been
in
one
that
has
followed
like
the
official
processes,
but
here's
to
know
what
you
change
in
the
future.
A
Yeah
I
think
the
one
thing
we
would
change
and
we
realized
is
we
didn't
give
people
enough
warning
for,
like
the
pre-sprint
stuff,
so
I
think
in
doing
planning
for
this
I
would
just
give
myself
a
bit
more
time
before
the
start
of
the
Sprint
just
to
make
sure
I'm
giving
everyone
the
appropriate
info.
A
We
had
some
people
on
PTO
and
they
didn't
get
the
info
before,
like
the
day
before
the
Sprint,
so
just
making
sure
I'm
getting
information
to
people
quick
enough
and
making
sure
I'm
kind
of
taking
a
look
at
Sprint
members
PTO
and
getting
the
information
to
them
in
a
time
that
makes
sense
so
I
think
that
and
the
other
one
is
having
a
better
plan
for
the
day
four.
So
we
wanted
to
do
the
day,
four
right
after
the
Sprint
only
to
realize
there's.
A
Yeah
so
Justin
I
think
you're
the
next
one.
That's
not
freedom.
Yep
I
was
just
wondering
how
to
do
the
participants
feel
about
the
Sprint
and
do
you
think
did
they
say
they
would
do
it
again
yeah.
This
is
the
thing
that
made
me
really
excited
about
the
Retro.
Is
the
Retro
had
far
more
positive
feedback
than
negative
feedback
in
it?
People
were
really
excited
about
the
activities
they
really
like
the
buffer
days
in
between
too,
because
then
they
could
do
their
regular
work
with
the
Sprint.