►
From YouTube: CI/CD UX Meeting - 2021-03-10
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
there
this
is
this:
the
icd
wax
meeting
for
march
10th
2021.,
I'm
gonna
jump
right
into
the
agenda.
We
have
a
couple
of
fyi
and
read
only
items,
but
just
a
heads
up,
I'm
not
sure
if
you
saw
we
have
more
friends
and
family
days
scheduled.
So
please
have
a
look
and
schedule
your
your
time
off.
Added
to
your
agenda.
A
I
actually
had
the
first
point.
This
was
a
discussion
item
from
the
ux
leadership
call
and
on
collaboration
between
tech
writers,
with
ux
designers,
and
this
came
up
from
craig
discussing
pretty
much
like
how
managers
are
aware
or
how
are
people.
How
are
things
going?
Oh,
my
god,
it's
too
early,
sorry
daniel!
Do
you
feel
this
way
like
it's
too
early
to
speak?
Not
portuguese
anyways!
You
just
want
to
know
how
is
collaboration
going
in
case.
We
need
some
support
there.
A
So
from
a
tech
writer's
perspective,
they
want
us
to
over,
communicate
and
ask
for
their
input
sooner
rather
than
you
know,
just
in
the
merger
class
phase.
So
I
just
asked
here:
how
are
you
doing
today
to
kind
of
try
to
understand
that
and
see
if
there's
anything
that
I
can
do
to
help
bridge
the
gap
there
or
connect
with
that
writers,
and
I
saw
that
nadia
has
the
the
first
point.
So
now
they
free
to
voice
your
what
you
wrote
to
the
agenda.
B
Yeah,
I
I
collaborate
a
lot
with
marcel
our
tech
writer
on
any
ui
changes
or
ui
text
changes
or
additions,
and
typically
I
just
ping
him
once
the
planning
breakdown
starts.
So
when
I'm
working
on
the
designs
once
things
are
more
or
less
refined.
If
I
have
high
confidence
about
the
text
more
or
less,
I
get
him
involved
during
that
phase.
B
So
I
start
working
with
engineers
on
planning
breakdown
and
awaiting
the
issues
and
the
same
time
I'm
refining
the
copy,
because
at
that
point
we
can
already
weight
the
issues,
usually
so
that
kind
of
speeds
up
the
process.
So
I
can
do
two
things
at
once,
but
if
a
ui
copy
is
more
problematic
and
it's
more,
it's
a
more
significant
part
of
the
design
and
then
I
might
get
technical
writing
involved
earlier
as
well,
and
we
also
collaborate
on
some
bigger
efforts.
You
see
there
in
the
agenda.
B
A
Easier
you
just
work
on
yeah,
multiple
right
pieces
of
the
copy
in
the
same
flow.
Have
you
seen
other
designers
doing
something
like
that?
Nadia?
Because
I
think
it
is
a
good.
You
know
best
practice
for
us
to
share
broadly
with
the
with
evac's
department.
A
B
B
So
that's
why
we
started
the
spreadsheet
because
we
had
to
collaborate
like
across
the
whole
organization,
basically
to
get
information
about
the
templates
because
turns
out
that
all
of
the
different
cic
templates
are
owned
by
different
groups,
and
it
took
me
weeks
to
just
find
people
who
know
something
about
those
templates
and
still
for
some
templates.
I
couldn't
find
the
dri.
B
So
that's
why.
But
so
I
don't
know
if
it
could
be
useful
for
just
like
a
feature
design.
Probably
I
would
still
prefer
to
keep
everything
in
the
issue
just
to
keep
one
single
source
of
truth,
but
if
you
need
to
collaborate
widely
across
the
company
and
if
it's
like
you
know,
10
plus
people
collaborating
on
something
like
this,
then
I
think
a
spreadsheet
can
be
helpful.
A
Looking
at
it
from
for
my
case
like
how
I
would
use
it,
I
would
try
to
work
on
the
copy,
even
if
it's
for
a
small,
not
a
small
feature,
not
cross
cross
stage,
but,
for
example,
runners
right.
Where
are
we
designing
runners
at
the
the
admin
level?
And
then
we
have
settings
level
you
have
so
much
ui
and
for
my
case
sometimes
I
have
to
prototype
things
so
that
tech
writers
can
validate
and
give
them
context
of.
A
Why
certain
you
know
copy
it's
written
or
is
proposed
the
way
it
is,
I
think,
in
my
case
this
would
be
helpful
like
that,
having
sheet
or
having
a
source
of
be
helpful
to
just
tell
them
like
hey.
This
is
everything
that
we're
thinking
for
a
certain
feature,
but
anyways,
it's
up
to
you
feel
free
to
share
this.
I
think
it's,
even
if
it's
not
across
a
larger
project
like
for
the
cic
templates,
I
think
folks
can
still
learn
from
from
this
method.
B
A
Awesome-
and
I
added
here
to
the
agenda-
I
think
daniel
is
going
to
be
the
most
useful
to
you.
There's
a
link
for
you
to
see
who
is
the
tech,
writer,
tech
writer
designated
to
a
certain
stage
group,
and
then
you
have
the
backup.
So
let's
see
who's
mine,
so
you
have
a
for
example,
mccaskill
and
then
his
backup
is
axel,
so
you
can
figure
out
who
to
ping.
C
I
was
gone
for
a
little
while,
so
maybe
I
missed
something,
but
I
just
wanted
to
mention
that
so
marcel
and
I
we
collaborate
very
often
and
it's
almost
like
every
alternate
day.
We
get
over
a
call
to
discuss
an
issue
because
he
has
a
very
good
method
to
explain
the
technicalities
behind
some
very
complex
features
and
I
always
make
use
of
it
and
especially
on
issues
we
think
I
mean.
I
think
we
almost
like
collaborate
every
single
day.
So
it's
going
very
well
for
us.
A
A
Should
it
be
in
the
y
phase,
while
you
know
in
the
comment
section
doesn't
really
matter
it's
up
to
you,
whatever
works
for
you
and
your
your
strategic
counterpart,
but
make
sure
that
you
are
over
communicating
with
tech
writers
so
that
they
can
help
us
clarify
ui
copy
sooner
than
the
development,
the
merger
quest
phase.
A
So
next
up
is
danielle.
D
Hey
so
I
wanted
to
share
a
little
bit
the
work
I've
been
doing
for
a
ux
scorecard
for
autodevops.
It's
pretty
much
the
first
design
task
that
I
was
assigned
to
by
hayanna,
essentially
to
better
understand
the
current
state
of
the
product
and
I'll
share
my
screen
and
and
share
a
little
bit
of
the
figma
prototype.
But
there
is
a
link
to
the
issue
that
has
everything
on
the
agenda,
so
you
can
take
a
look.
Look
at
that
as
well.
Let
me
share
my
screen.
D
All
right,
I
assume
you
can
all
see
it
already,
if
you
don't
just
wave
all
right
so
this
to
be
more
specific.
This
was
a
scorecard
for
autodevops
with
aws.
D
The
idea
here
was
to
do
as
close
as
possible
to
the
formal
standard
of
a
ux
scorecard,
but
I
didn't
have
a
specific
persona
or
jobs
to
be
done
for
this,
so
I
created
my
own
jobs
to
be
done
with
a
lot
of
input
from
ion
and
valerie,
which
was
when
contributing
to
an
application.
I
want
my
new
code
to
pass
tests
and
go
live
automatically,
so
I
don't
need
to
worry
about
deployments
or
infrastructure
right.
So
essentially,
the
idea
here,
the
the
persona
here-
would
be
a
friendly
developer.
D
D
D
So
I
went
with
a
very
simple
static
site
generator,
and
then
I
just
went
to
the
documentation
and
search
auto
devops
aws
and
that's
where
it
started
to
get
tricky,
because
there
were
multiple
entry
points,
multiple
docs
that
could
serve
as
an
entry
point
to
this
process.
So
here
on
the
sidebar,
you
can
see
autodevops
get
started
requirements
or
other
devops,
auto
devops
development
guide.
So
right
from
the
start,
it
was
really
hard
for
me
to
understand.
D
Where
is
the
default
way?
The
default
step?
One
for
this?
As
I
went
along,
I
saw
a
bunch
of
talks
and
saw
there
was
an
option
for
kubernetes
and
an
option
for
amazon
ecs.
From
my
experience,
kubernetes
is
kind
of
like
a
overkill.
It's
for
larger
projects,
so
I
just
decided
to
go
with
ecs,
but
it
was
an
arbitrary
decision
and
didn't
know
for
sure
if
it
was
the
best
option
for
my
use
case.
D
But
that's
that's
the
best
decision
I
could
make
at
that
moment
and
then
from
then
on
a
lot
of
aws
stitching
together
different
docs
different
rides,
and
since
I
had
very
little
knowledge
about
this
pretty
much.
If
you
taught
me
to
create
a
new
role,
I
create
the
role
with
the
default
options
as
much
as
possible
and
see
if
that
works.
D
So
that's
what
I
did
sign
in
create
user,
create
role,
create
group,
create
resources,
a
bunch
of
aws
screens
and
then
once
I
had
these
resources
created
then
had
you
know,
keys
and
and
and
whatever
information
was
needed-
I
would
come
back
to
the
project
and
put
it
there
at
some
point.
I
found
this
setting
screen
that
made
me
believe
that
actually
kubernetes
is
the
default
way
to
use
auto
devops
and
that
may
be
a
bit
frustrated
like
oh.
D
I
came
all
this
way
with
an
option
that
is
not
the
default
option,
so
maybe
I'm
doing
things
the
hard
way
and
turns
out.
I
was
but
at
this
point
I
was
committed,
so
I
kept
going
and
eventually
I
finished
all
the
all
the
steps
that
the
guide
suggested.
I
had
all
the
resources
created
on
the
aws.
I
had
all
all
the
configurations
of
my
demo
file
and
you
could
see
here.
This
is
the
actual
pipeline
of
my
of
my
repo.
It
has
amazon
ecs
on
the
pipeline,
but
nothing
actually
happened.
D
So
at
some
point
some
step
of
my
configuration
failed,
but
there
were
so
many
steps
that
I
weren't.
I
wasn't
able
to
recreate
or
retrace
what
went
wrong.
D
So
that's
where
I
stopped
for
this
for
this
workflow,
but
it
manages
to
to
teach
me
a
lot
about
the
product
and
then
some
takeaways
that
I
had
were
that
the
starting
points
for
autodevops
are
very
unclear
regardless,
if
you're
going
with
kubernetes
or
not,
there
are
too
many
options,
there's
no
one
default
place.
That
tells
you.
This
is
where
to
start
right.
D
Documentation
is
very
driven
by
feature
and
technologies
and
like
the
actual
technical
platforms,
you
will
be
using
either
amazon
ecs,
aws
or
google,
rather
than
the
the
actual
workflow
that
me,
as
a
user,
I'm
going
through
right,
the
the
documentation
that
actually
resembled
the
workflow.
The
best
was
a
blog
post
on
the
on
the
gitlab
blog,
and
that
was
the
most
useful
piece
of
documentation.
I
had
that
had
screenshots
of
aws
and
took
me
step
by
step
rather
than
the
official
technical
documentation.
D
That
pointed
me
in
many
different
directions
at
once,
and
the
last
point
is
regarding
regarding
kubernetes
and
and
that
surprise
I
had
midway
through
where
default
options
really
could
be
more
prominent
along
the
process
and
the
documentation.
D
So,
no
matter
where
I'm
looking
at
in
terms
of
of
auto
devops
having
a
link
at
something
that
points
to
hey
you're
new
to
autodevops.
This
is
the
place
to
start
right
start
reading
here
and
then
you
can
take
the
rest.
Maybe
that
existed.
But
given
the
amount
of
information
available,
I
wasn't
able
to
to
to
find
it
in
the
middle
of
everything.
D
So
after
I
did
this,
I
wrapped
up
this
workflow
and
since
I
realized
kubernetes
was
a
default
way
to
use
autodevops.
I
started
doing
the
same
with
kubernetes
and
after
some
hiccups
I
was
actually
able
to
connect
it,
but
there's
some
issues
with
my
project
so
that
that
that
evaluation
is
still
ongoing
but
yeah.
This
is
what
I
have
for
now.
D
So
I'm
not
sure
if
there's
any
specific
feedback,
I'm
looking
for
from
this.
So
in
general,
what
are
your
thoughts
and
what
are
some
ways?
You
could
see
me
upgrading
this
back
into
the
working
release
and
and
turn
this
into
actual
suggestions
for
for
the
different
teams
working
on
this.
A
You
know
first
off
thanks
for
sharing
it's
very
interesting,
to
see
the
walkthrough
and
see
the
challenges.
I
think
I
I'm
speaking
for
myself,
but
I'm
assuming
that
we
all
have
been
through
the
these
challenges,
once
configuring
auto
laptops
so
making
this
navigating
through
the
docs
figuring
out
how
things
work
at
gitlab
so
nadia,
can
you
link
here
the
the
auto
devops,
I
think
big
issue.
A
I
think
that
you
created
with
the
flows
so
that
we
can
also
share
this
with
daniel
to
give
him
some
previous
context
of
our
conversations
I'll
find
it.
Thank
you
I'm
curious
to
hear
danielle
from
your
point
of
view
in
terms
of
process.
What
were
the
challenging
aspects
of
the
ux
scorecards
in
terms
of
you
know,
setting
up
the
documentation?
That's
in
the
handbook.
How
was
the
experience
of
creating
and
working
on
this
exercise
other
than
the
the
technical
aspects
of
it
and
the
learnings
in
the
product.
D
I
found
I
found
the
the
general
description
of
the
goals
and
and
what
the
ux
scorecard
should
be
very
clear
but
more,
given
that
it's
such
a
such
an
intense
exercise
where
you
have
to
to
do
you
know
a
lot
of
workflows
and
then
document
everything
and
then
have
suggestions
on
top
of
it.
The
emotional
grading.
All
that
I
found
there's
there's
little
concrete
templates
or
examples
for
it.
D
I
actually
had
to
to
sift
through
previous
ux
scorecards
and
find
some
that
were
very
complete
and
very
thorough
and
then
use
those
kind
of
as
a
template.
I
literally
went
into
the
the
the
issue
copied
all
the
texts
and
pasted
on
mine
and
started
changing
that.
That
was
the
easiest
way
for
me
to
structure
everything,
but
in
terms
of
what
is
the
goal
of
the
exercise,
the
the
handbook
was
pretty
clear
on
that.
A
Think-
and
I
saw
that
there
was
a
discussion-
a
thread
with
with
valerie
about
the
jobs
to
be
done.
So
I
know
that
this
is
a
separate
thing
right.
The
job
should
be
done
to
kind
of
wrap
the
ux
scorecard
exercise,
but
in
terms
of
job
to
be
done,
do
you
have
any
feedback
or
what
feedback
do
you
have
on
writing
a
job
to
be
done?
You
know
finding
the
language
finding
yeah
the
the
test.
The
scenarios
in
combination
with
the
x4
card.
Is
there
a
gap
there?
No.
D
Yeah,
so
just
to
give
more
more
context
to
nadia
and
vitica
this,
this
jobs
to
be
done
that
I
showed
was
actually
fruit
of
many
iterations
and
conversations
on
a
tread
with
hyuna
and
and
valerie,
and
I
think
for
me,
because
I
I
had
to
write
the
job
to
be
done
for
the
ux
scorecard
and
I
kind
of
did
both
at
once.
D
I
was
too
too
stuck
to
the
technical
level
to
technical
details,
so
it
started
much
more
when
creating
a
new
project
for
aws.
I
want
to
connect
with
so
I
had
to
break
it
in
parts
and
start
going
higher
level
with
it.
I
think
starting
the
jobs
to
be
on
from
previous
research
is
the
ideal
way
and
it
helps
you
keep
a
a
higher
level
to
it.
D
So
yeah,
I
think
for
me,
starting
from
from
technical
workflow,
that
I
was
working
on
kind
of
stood
in
the
way
and
made
me
stay
too
low
level
with
the
jobs
to
be
done
so
next
time.
I
would
do
this,
I
would.
I
would
try
to
start
from
research.
The
goal
here
was
kind
of
start
fresh
and
not
look
at
too
much
context
before
I
did
this
exactly
to
to
go
at
it
with
fresh
eyes,
but
ideally
you
should
have
as
much
context
as
possible
in
a
regular
scenario.
C
Okay
yeah,
so
I
mean
when
I
had
my
coffee
chat
with
maria,
maybe
sometime
like
last
month.
I
remember
her
mentioning
about
the
direction
they're
planning
with
auto
devops
because
she's
from
configure.
I
definitely
think
that
if
you
haven't
planned
one
already,
you
should
check
in
with
her
to
understand,
like
what
are
the
directions
they
have
in
their
team
for
working
on
auto
develops,
because
kubernetes
is
the,
I
think,
the
way
that
they
have
decided
to
venture
into.
So
there
would
be
some
very
useful
insights
for
you.
D
Yeah,
I
actually
did
have
a
coffee
chat
with
her,
as
I
was
wrapping
this
up
a
week
and
a
half
ago,
and-
and
she
gave
me
really
good
context
on
that-
explain
a
little
bit.
Why
are
things
this
way
and
the
team
is
moving
in
a
different
direction,
so
this
specific
workflow
I
I
did
hasn't
really
been
that
maintained
for
a
while.
So
that
explains
explains
why
it's
so
so
documentation
intensive,
but
it
was
interesting
to
to
do
this
scorecard
expecting
to
you
know:
oh
yeah.
D
This
is
the
work
of
the
releasing
where
I'm
working
at
and
actually
all
the
things
that
I
evaluated
apart
from
configure,
so
so
that
that
was
funny,
but
but
it
was
good
to
learn
about
the
project
anyway,.
C
Right
and
in
fact
it
was
really
good
that
you
got
to
know
that,
like
you
ran
into
this
very
early
the
process,
because
maybe
much
later,
when
you
would
have
already
started
to
work
on
release
issues,
you
would
have
found
this
lack
of
context
right.
I
think
this
happened
for
good.
D
Yeah-
and
it
was,
it
was
a
really
good
lesson
on
on
really
understanding
the
structure
of
teams
and
the
product
here
at
it
lab
right
where,
yes,
it's
such
a
large
and
technical
product,
that
the
configuration
aspect
of
it
is
a
whole
different
scenario
as
a
different
team
that
that
looks
at
a
different
context,
but
also
there
are
opportunities
to
better
tie
these
two
parts
together.
So
I
was,
I
was
glad
I
did
this.
A
B
I
don't
know
if
you
I,
I
don't
know
if
you
seen
these
conversations
around
other
devops,
that
happened
during
the
thing
big
session
and
like
the
general
kind
of
changing
product
direction,
but
there
were
also
conversations
about
giving
other
devops
to
pipeline
authoring
because
it's
kind
of
ci
cd
configuration.
B
So
it
is
like
a
complicated
problem
who
should
own
this,
and
how
do
we
connect
all
of
these
different
workflows
together,
because
autodevops
can
also
enable
so
many
different
things
so
yeah?
I'm
I'm
curious
about
how
it
will
turn
out,
because
there
needs
to
be
a
lot
of
cross-stage
collaboration
to
really
leverage
the
auto
devops
features.
B
But
so
far
I
haven't
really
seen
much
happening
in
that
regard.
We've
had
lots
of
conversations
around
it.
How
maybe
to
create,
like
a
working
group
to
have
multiple
ux
designers,
collaborating
on
it
to
create
a
vision
that
can
really
leverage
other
devops
to
make
it
easier
to
enable
gitlab
features.
But
in
the
end
the
decision
was
made
to
keep
it
in
configure.
B
D
Yeah
for
sure
that
that
that
is
in
line
with
with
what
I
talked
with
mania
a
while
back
and
thanks
for
the
link
for
the
thing
being
sasha,
we'll
take
a
look
at
it
and
and
try
to
integrate
this
context
as
well.
A
Yeah
and
just
for
context,
the
configure
team
is
working
on
the
plan
for
auto
devops,
so
the
technical
folks
are
working
on
a
technical
blueprint
for
what
the
npc
or
the
first
steps
will
look
like,
and
maria
and
justine
will
be
leading
the
ux
vision.
So
indeed
we're
it's
good
that
we
all
gather
as
much
context
as
we
can
to
support
them,
but
they
are
the
dris
for
auto
devops
like
what
nadia
said.
A
I
think
other
devops.
We
all
owned
it
at
some
point
in
time,
we're
all
responsible
for
it
a
little
bit
so.
B
A
Interesting
product
area-
and
I
suggest
daniel
that
you're
looking
to
if
you
haven't
done
that
yet
look
into
the
the
release
category.
So
I
linked
here
the
handbook
page
that
has
all
the
the
categories
for
release
so
continuous
delivery,
advanced
deployments,
review,
apps
feature
flags
release
orchestration
in
pages.
I
know
that
with
your
exercise,
you
didn't
get
to
the
point
where
you
finalized
the
deployment
and
you
didn't
work
on
the
cd
part
per
se
of
the
ux
scorecard.
A
But
I
suggest
you
go
over
these
pages
and
read
the
direction
redivision
the
what's
next,
to
get
some
understanding
to
get
understanding
of
how
this
relates,
for
example,
to
setting
up
auto
devops,
it's
very
useful.
It's
not!
I
don't
think
it's
always
that
we
use
autodevops,
but
knowing
how
things
work
and
how
the
cicd
flows
connect
is
a
key
to
success
for
our
little
design
group.
A
Yeah,
if
no
one
has
any
other
comments,
then
vitika
you
can
take
over.
C
All
right,
so
I'm
going
to
share
my
screen
just
a
moment.
C
Okay,
all
right,
so
I
know
that
I've
been
talking
about
this
since
last
week
about
this
mapping
that
I'm
doing
for
jobs
to
be
done
for
ci
yesterday.
What
we
did
in
the
cia
team
was
tom
and
I
we
observed
in
our
just
to
look
at
and
refine
everything
that
was
there
already
on
this
board.
So
we
started
off
with
like
deciding
on
what
our
core,
who
our
core
executors,
are.
So
something
that
I
did
not
include
before
was
dakota
so
dakota.
C
We
figured
that
dakota
is
kind
of
a
very
crucial
piece
in
this
whole
ci
business,
because
they
are
kind
of
the
decision
makers,
so
we
also
have
to
keep
them
at
the
center
and,
as
jackie
also
mentioned
in
a
comment
when
I
shared
the
cms
scorecard
results
that
we
can't
call
ourselves
lovable
yet
because
we
are
hardly
providing
any
value
to
dakota
yet
so
that's
just
to
make
sure
that
this
is
our
focus
for
future.
C
We
have
added
this
as
well
to
the
core
executors
for
ci
and
after
that
we
just
went
on
improving
what
I
already
had
on
the
board
here,
and
we
are
only
for
we
only
focused
on
the
areas
which
concern
ci,
which
is
the
prepare,
execute,
monitor
and
conclude
stage,
which
kind
of
directly
relate
to
the
run
and
analyze
part
of
gitlab
ci,
leaving
the
define
and
optimize
for
pipeline
authoring.
So
nadia.
C
If
you
want
to
you,
can
use
the
same
board
and
you
can
just
follow
the
same
process
that
we
did
and
maybe
just
recycle
and
reuse
the
content
all
right.
So
after
having
spent
a
lot
of
time.
What
we
did
was
we
polished
all
the
jobs
to
be
done
that
we
had
identified,
and
we
didn't
just
do
that.
C
We
also
kind
of
prioritized
them,
and
we
made
sure
that
this
time,
where
we
followed
all
the
right
practices
for
framing
the
jobs
to
be
done,
for
example,
keeping
it
gitlab
ci
as
a
tool
agnostic,
then
persona
agnostic
and
just
following
the
right
rules.
C
And
then
we
also
kind
of
figured.
So
the
one
that
you
are
seeing
in
green
is
something
that
we
are
still
working
on
reframing.
It
is
not.
The
work
is
not
done
yet
here
and
the
ones
that
you
are
seeing
in
purple
are
the
areas
that
we
identified,
that
we
haven't
done
anything
for
us.
C
So
these
are
the
three
jtbs
in
ci
that
have
not
been
attended
to
yet
that
means
we
would
very
consciously
take
this
effort
to
work
on
these
jobs
to
be
done
and
at
least
make
sure
that
we
are
providing
some
value
to
the
code
executors
who
are
associated
with
this,
which
is
mostly
dakota
in
this
case.
That's
our
goal
for
at
least
this
financial
year,
and
I
would
what
I
would
be
doing
next.
C
So
one
thing
that
I've
already
done
is
I've
created
a
merge
request
to
include
all
of
these
changes,
and
tile
still
is
yet
to
have
a
look
at
these,
and
she
has
to
maybe
polish
a
few
things
on
here.
But
another
thing
that
I'm
planning
to
do
using
the
same
board
is
define
the
ux
goal
for
financial
year
for
this
financial
year
and
kind
of
document
that
in
the
handbook,
maybe
not
for
the
financial
year
just
for
the
quarter.
C
But
it
would
very
strictly
be
tied
to
this
jtbd's
that
we
have
identified
and
that's
how
we
are
planning
to
prioritize
them
as
well.
So
that's
pretty
much
it
yeah
and
I
I
remember
the
comment
that
daniel
made
that
the
problem
study
phased
file
framing
the
database
like
it.
It
was
very
difficult
to
level
level
it
up
and
we
were
only
focusing
on
the
technical,
functional
jobs.
C
So
I
would
recommend
you
use
you
at
least
try
using
this
template,
because
what
this
demands
you
to
do
is
this
demands
you
to
not
only
just
document
the
functional
and
core
jobs,
but
also
keep
in
mind
the
social
and
emotional
aspects
for
those
jobs
and
when
you.
Finally,
when
you
come
down
to
framing
the
jtbd
you'll,
have
so
much
of
information
at
hand
that
it
just
gets
easier
to
keep
all
those
things
in
consideration.
A
This
is
awesome.
I
was
going
to
ask
you
about
how
I
was
using
the
the
template,
because
we
discussed
this-
I
think
a
week
ago
or
so
and
you're,
I
think,
you're
the
one,
the
first
using
right
this
this
resource.
So
it's
a
good
reminder
to
connect
the
jobs
to
be
done
and
I
think
in
general
visualizing
how
things
fit
in
in
the
in
the
priority
in
the
map
and
look
at
the
emotional
aspects.
It's
a
it's
a
very
positive
thing
from
using
this
resource,
the
mural.
B
Yeah
beautiful,
I
haven't
gotten
to
it
yet
there's
like
fires
burning
with
the
pipeline
graph
designs
and
release
so,
but
at
some
point
I'll,
definitely
reuse
this
thanks.
So
much
for
doing
all
this
great
work,
I
will
definitely
be
able
to
build
upon
it
and
I
think
there
will
be
some
oral
app
as
well,
especially
with
the
enterprise
jobs
to
be
done.
We
haven't
really
done
much
digging,
we
kind
of
have
them.
B
You
know
like
in
our
mind,
and
we
have
some
ethics
that
are
created,
but
we
need
to
start
looking
more
into
it,
and
I
think
we
will
start
thinking
more
about
it
in
the
second
half
of
the
fiscal
year,
but
maybe
like
in
a
couple
months,
probably
I'll
be
focusing
more
on
it.
So
we
can
collaborate
on
it.
D
Vitica,
it's
it's
very
interesting
that
to
see
me
mentioning
that
that
issue
with
jobs
to
be
done,
and
then
this
framework
that
pretty
much
solved
those
problems
that
I
had
one
one
question
that
I
have.
If
I
understood
correctly
once
you
broke
down
these
jobs
into
functional
social
and
emotional
aspects,
I
understood
you
took
different
pieces
of
each
one
of
these
aspects
to
merge
into
one
job
for
that
column.
Right
in
that
case,
what
kinds
of
decisions
you
had
to
make
into?
C
So
I
mean
the
emotional
aspect,
especially
it
doesn't
get
reflected
very
straight
in
a
very
straightforward
manner,
but
in
case
that,
if
you
feel
that
that's
kind
of
a
very
overwhelming
factor
in
this
whole
jobs
to
be
done,
so
you
mentioned
that.
How
did
you
break
it
into
functional
social
and
emotional?
I
in
fact
did
not
do
that.
I
started
off
with
so
I'll
show
this
to
you
again.
C
So
what
this
for
this
template,
how
this
is
organized
is
it
asks
you
to
put
down
the
functional,
the
very
functional
task
that
you
are
looking
to
accomplish
in
this
particular
stage
with
the
tool?
So
I
did
I
when
I
was
noting
this
down.
I
was
not
exactly
thinking
of
the
job
to
be
done
and
I
was
only
focusing
on
the
task
and
it
was
only
towards
the
very
end
of
it.
C
I
started
to
kind
of
consolidate
all
of
this
information
into
one
statement,
but
it
was
very
easy
because
we
already
have
this
format
in
picture
right
like
when
I
want
to
then
so
I
can
so
that
kind
of
makes
it
very
easy
so
that
that
framework
in
itself
just
to
draft
the
statement,
it
takes
care
of
how
you
include
the
social
and
emotional
aspect.
A
No,
we
are
a
little
bit
over
time,
but
I
just
want
to
go
over
some
of
the
items
that
are
left
in
the
agenda.
So
my
next
item
is
about
the
unfiltered.
The
itlab
design
talks
series
on
design
leadership,
so
I
mentioned
this
yesterday
during
the
ux
leadership-
call
not
sure,
if
you're
all
there,
but
I'm
interviewing
designers
that
made
a
transition
or
the
designers
that
are
now
in
you
know,
management
or
staff
roles
to
talk
a
little
bit
more
about
what
they
do.
What
is
it
to
be
a
staff
researcher?
A
What
is
it
to
be
a
staff
designer?
What
is
it
to
be
a
design
manager
and
discuss
a
bit
of
about
skills,
background
career
outside
of
gitlab,
et
cetera,
et
cetera?
So
I
invite
you
to
watch
these
videos
because
it's
been
very
nice.
It's
been
great
talking
to
the
designers
in
our
team
to
understand
what
they
think,
what
they
understand
as
a
leadership
and
discuss
and
showcase
ways
that
we
can
exercise
leadership
without
talking
about
a
role
or
a
change
in
your
seniority.
A
So
it
gives
you
really
gave
me
a
glimpse
on
how
different
the
career
paths
can
look
like
for
designers
in
the
organization.
So
I
have
two
videos
now
with
lori
and
marcel
today.
I'm
uploading
the
one
from
my
interview
with
pedro
and
next
week,
I'm
speaking
with
tori
about
her
transition
and
what
is
it
to
be
the
lead,
the
manager
for
ux
foundations
team?
A
So
if
you
have
any
questions,
feel
free
to
drop
them
in
the
slack
channel
in
the
the
link
link
there,
the
issue
that's
linked
to
the
slack
channel,
but
also
the
pilot
issue.
I
think
it's
okay,
never
mind
doing
the
pilot
issues.
If
you
have
any
comments
or
feedback.
C
A
But
the
main
idea
of
this
session
is
to
talk
about
leadership,
of
course,
taking
the
example
of
leaders
right
in
organization,
but
also
discuss
that
leadership
is
not
about
your
role
and
the
many
ways
that
we
as
individual
contributors
of
how
we
showcase
and
how
we
can
exercise
leadership
in
our
roles
as
designers.
A
So
have
a
look
and
if
you
have
any
feedback
I'll
I'll
try
to
incorporate
that
in
the
blog
post.
I'm
hopefully
writing
this
this
weekend.
So
and
nadia.
Do
you
want
to
go
over
your
item.
B
Yeah
I
just
wanted
to
share
this
slide
deck,
that
the
product
team
kind
of
shared
in
a
very
low
key
way
in
the
product
channel,
and
I
think
it's
a
gold
mine.
So
it's
a
deck
with
the
post
purchase
survey
results
where
customers
were
interviewed
about
why
they
upgraded
to
a
page
here
or
upgraded
to
a
higher
tier
of
gitlab,
and
there's
lots
of
really
interesting
information
there
about
what
features
were
the
deciding
factors
for
them
to
switch?
B
And
you
can
see
what
are
the
top
features
that
made
our
customers
switch
to
a
paid
tier.
So
you
can
use
that
those
insights
to
maybe
brainstorm
some
ideas
around
how
to
better
surface
those
features
in
the
ui,
maybe
recommend
them
to
users.
Of
course
we
have
to
be
very
careful
with
this,
but
I
think
it's
important
that
we
keep
those
in
mind
and,
like
make
sure
your
product
manager.
B
I
have
seen
this
as
well,
because
I
brought
it
up
to
dope
and
he
actually
hasn't
noticed
because
it
was
just
like
buried
in
in
the
product
channel
somewhere
so
and
also
you
can
reach
out
to
the
growth
team
as
well.
B
If
you
have
some
ideas
that
you
want
to
implement,
reach
out
to
them
and
see
what
they
think,
because
they're
really
experts
on
all
things,
you
know
all
of
the
upgrades
and
all
of
all
the
things
like
that
they've
done
lots
of
research,
so
chances
are
they've,
actually
run
some
tests
around
the
ideas
you
might
have.
A
Thank
you
for
sharing
that
yeah.
It's
really
this
information's
like
exactly
what
you
say
that
stays
in
the
channel
and
then
we
have
to
dig
so
thank
you
for
bringing
that
up
and
sharing
with
us
yeah
sure
we
are
a
time
anything
else.
Oh
yes,
by
the
way
I
have
a
conference
today
and
tomorrow,
so
I'm
gonna
be
away
from
keyboard.
If
you
need
me
for
anything,
feel
free
to
ping
me
in
slack
and
I'll
try
to
to
take
care
of
that
other
than
that.
I
think
we're
good!
A
No,
yes
and
I'll
see
you
later
enjoy
the
rest
of
your
day.
If
I
don't
see
you
anymore
today,
thank
you.
Bye.