►
From YouTube: A new designer's take on iteration | GitLab Design Talks
Description
Nick and Austin sit down to talk about Austin's recent experience since joining GitLab.
A
B
B
So
it's
a
bit
overwhelming
in
terms
of
trying
to
make
a
product
better
because
you're
kind
of
responsible
for
the
entire
thing,
and
that
can
be
a
big
challenge,
whereas
we
had
like
a
really
solid
team
here
at
get
lab
focus
on
proving
a
singular
product
which
is
really
fun
to
get
down
in
the
weeds
and
everything
I
think.
That's
probably
the
biggest
resource
changes
is
having
like
a
dedicated
group.
That's
focused
on
UX,
as
opposed
to
having
just
centralized
model
where
you
have
a
bunch
of
designers.
B
I
get
dispersed
across
the
company,
and
so
that's
been
interesting,
is
getting
to
work
with
a
bunch
of
people
on
the
same
product.
But
the
thing
that
has
stood
out
to
me
very
obviously
from
the
get-go
stuff
shifts
frequently
like.
If
they're,
the
train
doesn't
stop,
it's
continuing
to
move,
and
so
whether
I'm,
prepared
or
not,
the
team
is
going
to
continue
to
kind
of
ship
things,
and
so
that's
something
that
I've
had
to
get
used
to.
But
along
those
lines,
it's
not
just
like
the
design
aspect
that
I
get
to
contribute
to.
B
It
can
be
plenty
of
things
like
side
of
UX.
In
my
first
couple
weeks,
I
was
submitting
changes
to
our
handbook
and
spending
changes
to
some
of
our
processes
that
got
merged
in
and
those
will
be
a
part
of
what
I
consider
production
in
the
future.
So
that
was
really
cool,
I
mean
and
last
week,
I
was
making
changes
to
our
code
base
to
migrate,
some
of
our
deprecated
buttons
to
a
new
style
that
we'd
created
and
so
getting
to
contribute
outside
of
the
UX
profession.
B
I
guess
you
could
say
likes
that
thing
in
some
of
those
front,
end
responsibilities
or
even
documentation,
has
been
rewarding
in
and
of
itself.
That
kind
of
embodies
that
spirit
of
iteration
that
you
don't
necessarily
see
shared
and
other
companies,
where
you're
kind
of
told
to
just
like
stick
to
your
role.
A
B
Yeah
I,
guess
you
call
it
a
generalist,
focus
I!
Think
it's
more
just
everybody
wants
to
help
contribute
to
make
the
company
better
as
a
whole,
as
opposed
to
just
focusing
on
producing
designs
as
the
pure
responsibility,
so
you're,
not
just
making
our
boards
and
shipping
mock-ups
you're,
also
conducting
research
you're
contributing
to
our
documentation,
perhaps
adding
on
to
the
code
base
and
that's
a
bit
I,
don't
want
to
say
full
stack
because
I
don't
think
that's
an
appropriate
term
for
this,
but
it
does
give
you
more
responsibility
outside
of
your
typical
UX
role.
B
A
B
It's
like
changing
this
one
on
the
page,
I,
don't
feel
like
I
have
to
go
necessarily
conduct
an
entire
usability
test
for
changing.
Maybe
one
component
on
this
relatively
small
feature,
and
so
a
bunch
of
those
little
things
add
up
to
a
lot
and
change
in
terms
of
changing
a
bigger
experience,
but
it
does
make
me
feel
a
little
safer
to
say.
Okay,
we
can
make
smaller
changes,
maybe
without
having
to
go.
A
B
Of
features
that
we
have
identified
that
are
a
lower
grade,
experience
like
maybe
they're
a
C
or
D
grade,
and
the
aspirations
are
to
get
to
an
a.1
day,
but
the
a
is
not
next
release.
It's
like
no
we're
gonna
go
from
like
a
D
to
a
see
over
the
next
couple
of
releases,
perhaps,
and
that
reasonable
expectation
really
helps
provide
healthy
psychological
safety.
B
Yeah
and
really
just
feel
like
you're
reducing
risk
along
the
way,
because,
ideally
we're
getting
some
of
those
feedback
loops
from
users
or
customers
that
either
come
back
through
people,
opening
up
issues
and
writing
up
comments.
This
doesn't
work,
you
need
to
add
this
or
it
could
come
through
a
research
session.
B
So
there's
a
number
of
ways
that
we
can
continue
to
solicit
that
feedback
and
to
me
I
think,
there's
nothing
better
than
the
feedback
loop
of
actually
shipping
something
designs
and
mock-ups
and
prototypes
to
help,
but
definitely
shipping
to
production
really
tells
you
to
users
care
to
users
like
this.
It's
helpful
to
them.
That's
really
gives
you
the
feedback.
You
mean.
A
B
A
Yeah
you
gotta,
you
got
to
be
careful
because
burnouts
a
big
thing,
so
we
want
to
be
avoiding
that
at
all
costs
and
and
I
think
what
you
talked
about
is
actually
something
I
went
through
when
I
first
started
I'm
just
like
okay,
there's,
so
many
changes
that
need
to
happen.
I'm
gonna
come
in
I'm
gonna,
I'm
gonna
connect
all
adults,
I'm
gonna,
put
forward
this
beautifully
big
issue
that
summarizes
everything
and
I'm
gonna,
show
it
to
people
and
then
nothing
happens.
So.
A
B
A
Having
a
constant
backlog
of
work
that
you
have
to
be
working
on
I,
imagine
it's
definitely
challenging.
Is
there
anything
that
sort
of
stuck
out
for
you
with
regards
to
how
gitlab
does
design
or
how
it
get
lab
does
like
sort
of
just
product
in
general,
where
you
think
we
could
actually
improve
culturally
mm-hmm.
B
That's
a
great
question,
something
that
I'd
say
is
also
a
challenge
for
me
just
to
get
used
to
and
I
think.
This
is
a
good
value
that
we
uphold
with
our
asynchronous
communication,
but
it's
like
opening
asking
questions
and
open
areas
so
like
the
public
channels,
on
slack
or
within
issues,
there's
many
times
that
I've
been
like
I
really
just
wanted
EMI
product
manager.
This
question
but
I
feel
somewhat
insecure
about
asking
in
this
open
channel
and
I'm
like
no
copy-paste
drop
it
in
the
channel.
B
B
Man
I
think
it's
hard
to
know
exactly
what
the
best
opportunities
are
when
I'm
so
new,
because
everything
feels
so
different
to
me
and
and
in
some
ways
that's
really
great
and
in
some
ways
I
feel
like
I
still
have
a
lot
of
things.
I
would
like
to
learn
first
before
I
speak
on.
This
is
a
clear
blind
spot.
Everybody
has,
but
the
thing
that
I've
definitely
appreciated
so
far
is
everyone's
been
really
welcoming
and
everyone
has
been
willing
to
contribute
and
help.
B
So
I
think
it's
amazing
when
a
designer
that
I
haven't
even
met
is
commenting
on
some
of
the
designs
that
I
dropped
in
and
providing
feedback
of.
Hey
did
you
think
about
this
style
or
this
unit
user
interaction?
We
could
maybe
use
this
pattern
here
and
that's
very
helpful
for
me
and
so
I
think
continuing
to
encourage
that
cross
collaboration
is
really
really
important
because
it
definitely
helps
people
that
are
getting
on
boarded
that
don't
know
the
product
as
well
as
others.
A
Yeah,
there's
a
there's
a
term
or
a
metaphor
that
we
use
get
lab
which
at
which
really
resonated
with
me,
which
is
having
short
toes
so
I-
think
a
lot
of
companies,
especially
like
like
big
enterprises
that
you've
come
come
from
you.
You
always
have
this
little
fear
that
you
don't
want
to
be
stepping
on
anyone's
toes.
There
seems
to
be
like
a
little
bit
of
a
political
nature
along
with
shipping.
B
A
A
I'm
gonna,
I'm,
gonna,
lay
out
a
new
information
architecture,
I'm
gonna
talk
about
new
functionality
and
all
this
sort
of
stuff
and
I
took
a
couple
of
weeks
to
document
this
entire
thing
ship
in
mr
and
it
just
made
it
so
difficult
to
review,
because
the
diff
the
discs
and
when
you're
shipping
are
just
so
so
so
different
from
what
was
originally
there.
So
it's
hard
to
compare
and
contrast,
actually
what
what
you've
seen
or
what
you
had
versus
what
the
new
changes
are.
A
So
breaking
that
big
change
down
eventually
made
and
reviewing
the
the
stuff
that
I've
changed
so
much
easier
for
the
people
who
were
reviewing
it
so
starting
up
I
may
be
restructuring
the
information
architecture,
then
maybe
focusing
on
a
new
section
within
that
and
changing
that
and
doing
it
step
by
step.
It's
not
only
better
because
it
means
you
can
do
your
work
quicker.
It
also
means
that
people
who
are
reviewing
it
and
maintaining
the
stuff
it
makes
their
lives
easier
as
well.
Yeah.
B
No
definitely
and
I
think
that's
just
bringing
in
good
software
development
practices
into
even
a
designer's
workflow
or
a
PM's
workflow
breaking
down
work
to
its
smallest
chunk
makes
it
easier
to
ship
it
the
bigger
that
it
gets
the
harder
it
is
to
figure
out
a
way
to
integrate
it,
and
so
you
know
again
goes
back
to
trying
to
learn
more
than
just
being
a
UX
person.
There's
a
lot
of
other
great
principles
to
bring
in
I
love
that.
A
B
B
The
first
thing,
I
would
say,
is
like
if
you're
interviewing
for
a
specific
stage
or
group
of
the
company
look
into
that
teams
like
backlog
and
see
what
they're
doing
see
what
type
of
discussions
are,
having
the
problems
they're
trying
to
solve
and
figure
out.
That's
interesting
to
you.
That's
something
that's
awesome
about
ELab
is
our
work
is
mostly
public,
and
so
you
can
find
whatever
the
current
team
is
working
on
and
that
will
really
help
you
understand.
If
it
actually
is
interesting
work
like.
B
Can
you
see
yourself
actually
doing
the
stuff
that
they're
working
on,
and
so,
if
you're,
a
designer
I
would
say,
read
the
handbook
page
on
the
product
development
flow
that'll
help
you
understand:
where
does
the
design
process
fit
into
the
way
that
we
build
software
that'll?
Let
you
know
yeah
I
like
this
I
like
the
structure
or
it
doesn't
drive
well
with
you
and
it
doesn't
drive
well
with
you.
Then
it
will
be
pretty
tough
to
work
here
and
along
those
lines.
You
know
we
have
a
pretty
great
librarian,
big
MOA
to
build
and
construct.
B
You
know
high
fidelity,
mock-ups
lit
so
try
making
something
I'm
see
you
see
if
you
like,
interacting
with
our
systems.
Obviously,
if
anybody
has
feedback
to
improve
those
things,
they're
welcome
to
some
initiative
you
or
contribute
to
it,
but
those
will
kind
of
give
you
a
taste
of
understanding.
How
did
things
go
here
and
if
you
like
it
or
not,
because
when
you're
interviewing
it's
it's
equally,
you
know.
Do
we
want
you
as
a
candidate,
but
also
do
you
really
want
to
work
here
and
I?
B
A
B
Biggest
unlearning
has
been
a
git
lab.
I
need
to
show
two
meetings
prepared
to
participate,
I
would
previously
show
up
and
be
fed.
I
would
wait
for
the
person
that
was
facilitating
the
session
to
teach
me
whatever
I
needed
to
learn
in
that
one
hour
long
meeting,
and
instead
here
everything
is
driven
by
an
agenda,
and
so
that
agenda
is
in
every
single
meeting
beforehand.
B
So
I
have
a
responsibility
to
go
in,
put
the
questions
that
I
need
answered
in
there,
but
action
items
that
I
would
like
to
discuss
in
there
and
the
meeting
is
about
a
tackling
those
things
and
so
unlearning.
The
habit
of
just
like
showing
up
to
a
meeting
has
been
really
hard
and
I
still
do
it
sometimes
most
of
the
days
but
I've
been
trying
to
get
better
about
I
think
inside
a
little
bit
of
time
before
each
meeting
to
try
and
address
any
agenda
items
or
be
familiarized
with
what's
coming
up.
B
A
Mmm-Hmm
and
I
think
just
to
touch
back
on
on
on
the
top
of
topic
of
iteration.
When
you
see
our
Google
Docs
meeting
agendas,
sometimes
there's
only
three
questions
or
something
to
start
out
with,
but
as
we
go
along,
there'll
be
more
and
more
questions
added
to
it.
So
it's
sort
of
live
edited
and
everyone's
contributing
to
it.
So
again
that
principle
or
value
of
iteration
sort
of
applies
not
just
to
the
stuff
we're
shipping,
but
also
the
way
that
we're
collaborating
and
interacting
with
each
other
as
well.
Yeah.
Absolutely.
B
So
I
tried
to
find
the
article
but
I,
and
but
what
I
remember
from
it
was
it
was
stating
that
designers,
just
iterating
mock-ups
in
pigma
or
in
sketch
or
whatever
your
favorite
tool
is,
doesn't
actually
count
as
an
iteration.
It
only
counts
an
iteration
if
you've
solicited
feedback
and
then
made
changes
based
off
of
the
feedback
that
you've
received.
What
are
your
thoughts
is
an
iteration
if
you
don't
have
to
be
back
from
customers
or
users
yeah.
A
Yeah
yeah
in
our
in
our
handbook.
It
says
it's
not
an
iteration
unless
it's
it's
been
shipped
so
iterating
on
designs
within
figma
or
iterating
on
the
stuff
that
you
you
document
within
an
issue
or
something
like
that.
Don't
count
unless
it's
been
shipped
I.
Think,
however,
there's
a
bit
more
design
culture
that
we
can
bring
to
our
thinking
around
iteration
and
designers,
live
and
breathe,
breathe
iteration
when
we
diverge
and
converge
and
all
that
sort
of
stuff.
A
So
if
you
think
like
a
good
example
of
this,
is
the
Google
Ventures
design
sprint
and
like
the
purpose
of
the
design
sprint
is
to
in
a
really
quick
way,
take
a
hypothesis
design.
Some
ideas
around
that
hypothesis
and
then
test
them
with
a
finite
number
of
users
to
get
qualitative
feedback
to
inform
a
direction
and
validate
that
hypothesis.
Now
what
they
do
to
make
it
so
quick
and
make
it
happen
within
the
space
of
a
week?
A
That
can
help
to
inform
to
our
decision-making
whilst
saving
a
lot
of
money,
because
if
developers
are
building
something
that
may
not
work,
it's
good
to
test
some
stuff
out,
but
it's
also
nice
to
be
a
little
bit
more
certain
of
the
direction
that
you're
taking
as
well.
So
that's
like
a
slight
disagreements.
I've
got
with
that
with
the
way
it's
had
it
documented
in
the
handbook.
Today.
What
are
your
thoughts?
Yeah.
B
It's
tough
because
I
do
think
the
most
like
valuable
feedback
cycle
comes
from
what
is
existing
in
production,
people
are
using
and
I
think
something
that
I've
really
really
had
to
adjust
to
is,
since
this
is
a
consumer
facing
up
and
I.
Typically
work
on
or
in
the
past,
I
worked
under
standard
price
applications
I
would
live
within
their
own
fiefdom
is
hearing
users
feedback
on
features
that
are
the
envy
you
see.
B
and
dev
and
everybody
kind
of
participating
in
that
initially,
and
just
keeping
it
small
and
iterative
as
we
go,
but
it
does,
it
does
hurt
some
times
to
hear
from
user.
It's
like
yeah.
This
is
underwhelming
and
what
we
know
you
know
hold
on
like
there's
more
coming
next
release
and
next
release,
yeah
and
actually
yeah,
but
I
guess
I
just
know.
Some
people,
like
our
culture
in
general,
isn't
necessarily
used
to
seeing
small
small
small
small
walls
feature
coming
out.
B
B
A
That's
interesting,
so
maybe
there's
an
area
of
exploration
that
we
can.
We
can
try
out
where
we
need
to
start
thinking
about
how
we
redefine
the
relationship
that
we
have
with
our
users
and
customers
and
help
to
set
expect
expectations
on
that
relationship
of
what
to
expect
when
we're
shipping,
how
regularly
we're
shipping,
but
also
what
sort
of
feedback
would
be
useful
and
how
they
can
provide
that
deep
black
and
like
a
more
effective
way.
Mm-Hmm.