►
Description
Lorie and Nick sit down to discuss how iteration works for UX research in GitLab
C
B
C
If
you
change
those
questions,
you
change
that
approach
during
that
process.
It
adds
on
time,
and
often
there's
no
more
time
to
add
on
to
things
so
that's
kind
of
where
my
gut
comes
from
telling
me
that
they're
kind
of
opposed,
but
it
doesn't
mean
that
research
can't
work
in
iterative
fashion.
So
what
tends
to
happen
sometimes,
is
we
in
in
corporate
world?
We
don't
do
like
longitudinal
research.
C
C
So
instead
of
longitudinal
like
let's
go,
find
out
how
people
go
and
shop
for
groceries
online?
Now
that
might
take
six
weeks,
this
turns
into
being
how
do
people
search
for
and
purchase
meat
online?
That's
a
very
specific
question
very
focused
thing
to
go
and
find
out
data
on,
and
you
can
do
that
in
a
relatively
short
amount
of
time.
C
You
still
need
to
find
people
to
talk
to
and
then
that
data
can
go
into
that
iteration
cycle
and
say:
okay,
that
can
inform
okay
people
look
for
meat
this
way
now.
What's
our
next
question
and
and
does
that
data
change
that
next
question
and
that's
really
where
research
can
feed
into
that
narrative
cycle
is
to
provide
feedback,
provide
confidence
right
answers
to
product
and
design,
and
so
then
they
can
change
or
have
confidence
in
going
in
the
direction
that
they
had
chose
to
to
do.
In
the
first
place,.
C
C
C
That's
where
you
back
up
and
you
go
higher
and
you
look
broader
over
what's
going
on
now
that
research
does
take
longer,
but
what
you
get
out
of
it
isn't
just
one
answer:
you're
going
to
get
10
answers,
a
dozen
answers
or
more
and
all
of
those
things
will
inform
directions
which
will
then
result
in
the
tactical
research
of.
Do
I
put
the
button
there?
Do
I
have
this
function?
C
You
know
do
go
through
this
process,
this
way
with
this
feature
or
function,
but
it's
the
strategic
piece
that
is
at
a
higher
level
higher
view
and
often
it
comes
into
play
at
get
lab
when
people
are
starting
to
say
we
have
a
problem
over
here.
We
just
you
know
the
numbers
aren't
right:
the
cus
there's
not
enough
customers.
C
We
think
it's
this,
but
we're
not
sure
research
go
and
find
out,
and
usually
when
it's
this
thing
that
they
think
it
is.
Even
that
thing
is
a
strategic
thing.
Maybe
it's
how
we
position
ourselves
in
the
market.
Maybe
it's
how
we're
sitting
down
and
and
telling
potential
customers
why
they
should
use
us.
That's
not
just
one
answer.
It's
not
like
make
a
better
deck.
That's
going
to
be
a
more
strategic
answer,
even
from
the
research
team
to
provide
people.
C
C
So
the
question
has
come
up:
what
is
ci
adoption
and
are
you
asking
everybody
everybody's
got
a
different
answer,
which
is
great,
but
that
means
you're
going
to
need
to
do
some
strategic
research
to
really
understand
what
adoption
means
to
us.
What
adoption
means
to
customers
and-
and
the
true
question
we've
been
asked
to
find
the
answer
to
is
what
is
stopping
people
from
adopting
ci
and
then
going
further
in
the
product.
But
the
first
step
is
to
answer
what
is
adoption
and
then
the
second
pieces
are
like
what
are
the
barriers
who
are?
C
C
Oh
yeah,
I've
seen
it
already
it's
it's
definitely
more
still
at
the
tactical
point,
because
again
they
don't
have
the
luxury
of
sitting
around
doing
thinking,
thoughts
all
day
they
have
other
jobs,
but
I
I
see
it
in
the
areas
that
I
support
all
the
time
and
that's
just
because
that's
where
my
focus
is.
I
know
the
other
researchers
are
helping
their
areas
but
say,
for
instance,
release
management
when
they
have
a
question
around
like
what
are
the
release
managers,
what
do
they
need
to
do
their
job?
Better?
C
That's
a
little
bit
more
of
a
strategic
question
than
the
tactical
one,
but
it
comes
out
as
tactical
decisions
that
were
made
to
add
features
to
the
product,
support
the
release
managers
in
these
ways,
hayana
changed
her
designs,
the
more
she
talked
to
people,
jackie,
the
pm
changed
her
direction,
the
more
she
talked
to
people.
So
it's
it's.
Embedding
the
research
in
that
product
process
and
that
design
process
to
get
more
confidence
over
time.
For
your
decisions
to
say
you
know,
I've
talked
to
five
people.
This
is
pretty
consistent.
C
We
really
should
go
in
this
direction.
I've
got
feedback
from
a
usability
test
in
my
design
from
five
to
six
people.
They
have
problems
with
this
button.
I've
got
to
redesign
this
button,
I've
got
to
fix
it
and
then
I'm
going
to
go,
show
it
to
another
five
people.
So
it's
infusing
that
research
into
that
product
development
flow
as
frequently
as
you
can.
B
C
Yeah,
I
you
know
what
I've
seen
is
the
key
with
that
is
that
the
product
partners,
which
I
call
engineering,
design,
research
and
product
part
product
partners
they
all
have
to
partner
in
on
those
efforts.
So
it's
not
something
that
has
to
be
shared,
shared
or
should
be
shared
later.
This
is
something
that
everybody's
aware
of
everybody's
knows
that
somebody's
going
and
doing
research
for
this
thing,
and
they
know
that
they're.
What
they're
part
of
that
thing
is
whether
it's
design
phase
where
engineering
wants
to
put
their
thoughts
into
like.
Can
we
do
this?
C
Or
can
we
not
do
this,
or
maybe
we
need
to
go
research
something
so
we
can
support
this?
Everybody
knows
what's
going
on
so
if
hayan
goes
off
and
runs
some
sessions
for
waste
management
design,
they
know
why
she's
doing
it,
they
know
what
she's
hoping
to
get
out
of
it
and
when
she
comes
back
and
tells
them
what
she's
learned
they
they
understand
how
they
can
consume
that
information
for
their
for
their
departments.
C
I've
also
seen
people
use
issues,
leverage
issues
to
pull
customer
feedback
that
way
as
well,
so
it
doesn't
always
have
to
be
like
a
talky
session
with
somebody.
You
can
like
actually
pose
a
question
in
an
issue
to
say
what
do
you
guys
think
how?
How
is
this
feature
working
for
you,
especially
if
it's
something
that's
been
out
for
a
little
while
and
been
something
somebody's
either
asked
for
or
complained
about.
Those
are
the
ones
that
you're
always
going
to
get
some
good
feedback
on.
B
B
C
Yeah,
no
I'd
love
to
have
development
there
because
they
always
have
such
a
different
perspective
than
I
have
and
different
from
my
pm
or
my
designer
as
well,
and
it's
a
skill
I
don't
have
I
don't
code.
So
why
am
I
leaving
you
out
of
it
if
you're
actually
going
to
have
to
build
the
thing
that
we're
testing?
You
should
definitely
be
there
to
help
help
guide
that
future.
B
C
One
of
the
big
challenges
is
the
idea
of
small
iterations.
Just
put
it
out
there,
we'll
fix
it
later.
That
kind
of
goes
against
researches
to
I
know
I
was
like
clutching.
My
pearls,
you
know,
goes
against
research's
tenant
of
like
no.
We
have
to
at
least
ask
somebody
something
first
before
we
put
it
out
there,
and
so
I
feel
like
that
can
be
misinterpreted
sometimes
and
used
as
a
shield
to
say
we
just
have
to
move
faster.
C
I
don't
know
necessarily
if
we
always
have
to
move
as
fast
as
some
people
believe
in
their
heart
that
we
should
move
at,
because
we
often
sacrifice
the
customer
experience
to
move
that
fast.
If
it's
a
not
if
it's
a
feature,
that's
not
executed.
Well,
no
one's
going
to
use
it
might
as
well
just
take
a
little
extra
week
or
two
to
get
some
feedback
on
it,
fine
tune
it
and
then
push
it
out.
C
I
don't
believe
that
research
has
to
take
another
two
or
three
months
into
you
know
slap
that
on
to
a
product
cycle.
It
can
be
quicker
than
that,
especially
if
you've
got
customers.
You
already
know
like
get
them
in
front
of
it,
get
them
to
give
some
unbiased
feedback
about
the
thing
that
they're
looking
at
and
you
have
more
confidence
in
in
the
future.
C
So
you
have
a
complete
thought,
a
complete
thing
that
you're
putting
out
there-
and
I
mean
I've-
seen
it
our
customers
know
when
it's
bs.
They
know
when
it's
been
pushed
out
too
fast
and
while
they
too
code,
they
understand,
they
don't
want
their
tool
to
work
like
that.
They
want
their
tool
to
support
them
in
what
they're
trying
to
do
and
they
want
to
have
confidence
in
their
tools.
So
we
really
have
to
think
some
of
that.
Those
quick
decisions
like
quick,
let's
get
out
their
decisions
through.
A
B
C
Yeah,
so
I
you
know
what
I
usually
tell
people
is:
if
you
can
answer
the
q,
if
you
tell
me,
I
have
to
build
this
thing,
and
I
ask
you:
how
do
you
know
that?
And
your
answer
consists
of
more
than
just
I
just
know
that
we
have
to
do
it.
Your
answer
says
customers
have
told
me.
I
can
point
to
you
to
this
issue.
I
can
point
to
you
you
to
this
information
chorus
or
these
other
places
where
I've
talked
to
customers.
They've
told
me
to
build
this
thing.
C
C
They
know
that
this
is
a
problem.
Unless
you
have
some
corroborating
evidence
from
the
outside
world,
you
can't
just
say
we
have
to
fix
this,
like
you
have
to
give
you
have
to
bring
something
else
to
me
competitive
analysis,
even
that'll
work,
something
from
the
outside
world.
That
tells
me
that
you
are
having
confidence
around
your
decision.
That's
not
just
coming
from
the
internal
world
of
you.
B
Agreed
and,
and
to
add
to
that,
you
are
not
your
user
point,
there's
also
the
the
cursive
knowledge
where,
if
you
know
something
you,
you
can't
unknow
that
and
therefore
put
yourself
into
a
position
of
empathy
of
someone
else
who
may
not
know
it.
So
so
as
people
who
develop
for
gitlab
and
and
and
use
git
lab
a
lot
ourselves.
C
I've
I've
seen
it
too.
I've
seen
that
yeah.
We
assume
a
lot
and
even
from
my
my
newbie
self
of
trying
to
do
like
a
merge
request
like
what
am
I
doing.
Where
am
I
at?
Why
am
I
even
looking
at
this
screen?
Did
I
do
something
wrong,
like
all
of
these
questions
went
into
in
my
thought,
process
of
trying
just
to
do
like
a
change
to
the
handbook
page
like
it's?
C
Yeah
yeah,
so
I
I
would
say
that
the
value
of
iteration
here
is
something
that
is
more
practiced
than
I
have
seen
it
anywhere
else
like
I've
been
at
other
companies
where
they're
like
yeah,
you
know
we'll
be
agile
and
we'll
just
make
small
changes
and
push
push
them
out
and
we'll
be
fine,
we'll
just
keep
going
well.
Small
changes
turned
into
maybe
one
thing
a
quarter,
so
definitely
here
we
definitely
practice
it
a
lot,
and
I-
and
I
think
you
know
so
forward
forward.
C
You
know
forearm
so
know
that
we
do
practice
it,
but
the
other
piece
of
that
advice.
I
would
want
to
tell
them
if
they're,
if
they're
a
senior
level
person,
they
would
get
this
a
lot
quicker
than
maybe
a
junior
or
a
mid-level
researcher
would
but
to
to
defend
the
sacredness
of
research
in
in
that
value
of
iteration.
C
Not
to
say
you
cannot
do
this
because
you
have
to
have
you
know
all
this
process
with
with
research,
but
to
understand
that
you
have
to
strike
a
balance
between
the
need
to
iterate
and
the
need
for
confidence
in
that
iteration,
and
a
lot
of
my
conversations
that
I
have
with
designers
and
product
managers
is,
if
they're,
not
fights
or
their
conversations
around.
What
do
you
need
to
know?
When
do
you
need
to
know
it
here?
C
Like
I
mentioned
at
the
beginning
of
the
interview,
it
is
something
that
can
work
together,
but
if
you've
never
experienced
that
working
togetherness
of
iteration
and
research,
you
come
in
thinking
that
it
can't
be
done,
and
those
people
won't
last
here,
both
both
product
design
and
research.
They
just
won't
last.
If
that's
how
you
approach
it.
B
C
C
B
C
You
know
I
will
say
like
this,
and
I
tell
people
this
anybody
who
asked
me.
I
have
never
worked
with
so
many
good
people
at
a
job
before
in
in
so
many
different
roles
throughout,
like
all
of
my
business
partners,
my
design
partners,
my
engineering
partners,
they're
all
on
point,
like
they
all
get.
Why
they're
here
they
understand
their
job
and
they're
good
at
it
and
they're
ready
to
partner
with
other
people
to
get
whatever
it
is
done,
and
I
just
think
it's
very
unique.
It's
it's.
C
You
know
I
worked
at
more
than
one
place
and
it's
not
something
you
find
everywhere
and
I'm
just
so
pleased
to
be
able
to
work
with
people
like
that,
which
is
why,
while
I
didn't
like
working
on
the
weekend,
I
didn't
mind
it
as
much
as
I
may
have
somewhere
else,
because
I
didn't
feel
like
it
was
just
me
carrying
the
burden.
We
all
shared
the
burden
here
and
it's
just
amazing.