►
From YouTube: Product Design at GitLab - Panel Discussion
Description
Product Designers Austin Regnery, Nick Post, Veethika Mishra, Iain Camacho, and Mike Nichols talk about designing at GitLab.
Moderator: Holly Reynolds
A
Hey
mike
and
vitica,
we're
going
to
give
it
just
maybe
another
minute
looks
like
nick
is
here
as
well,
so
I'm
going
to
go
ahead
and
get
us
started,
because
we
are
right
at
right
on
the
hour
and
I
want
to
be
sure.
We've
got
time
for
everyone
to
ask
questions
so
good
morning,
good
afternoon
and
good
evening
to
everyone
on
the
call.
Thank
you
all
so
much
for
joining
us
today.
A
Our
primary
users
are
teams
that
are
working
within
development,
security
and
ops
departments.
So
I
like
to
say
that
we
build
software
for
people
who
build
software.
That's
not
an
official
slogan
by
the
way,
but
our
ux
team
consists
of
about
44
folks,
including
product
designers,
ux,
researchers
managers.
We
also
have
one
of
our
amazing
ux
writers.
That
looks
like
on
the
call
which
I'm
happy
to
see
him
join
as
well,
and
we
are
located
all
over
the
world.
A
So
we've
got
people
everywhere,
which
is
which
is
a
wonderful
thing,
it's
great
to
get
to
see
people
from
all
over
the
place.
So
we
are
a
fully
remote
organization
as
well,
and
we
strive
to
be
asynchronous
first
in
our
communication,
this
lines
up
with
our
values
of
being
inclusive,
ensuring
that
everyone
gets
to
contribute
to
a
conversation,
and
it's
also
very
helpful
for
understanding
and
tracking
the
history
of
our
decisions.
A
A
Please
let
me
know
if
you
do
have
any
problems
being
able
to
access
that,
but
it
should
be
editable
by
everyone
so
that
you
can
add.
Your
questions
in
it'll
also
show
that
the
outline
for
the
discussion
there's
a
section
down
at
the
very
bottom
in
purple
with
some
sample
question.
One
question
two
slots
so
feel
free
to
type
your
questions
in
there
and
at
the
end
of
the
the
conversation
I
will
open
it
up
for
questions
at
that
time.
A
So
again,
I'm
holly
reynolds
senior
product
designer
here
at
get
lab
on
the
plan
team
and
I'm
going
to
just
take
a
quick
minute
to
ask
my
panelists
co-workers
here
to
just
quickly
give
your
name
and
your
title
and
maybe
where
you're
located
and
I'll
just
call
you
out
one
by
one
so
austin.
If
you
would
go
ahead
and
share.
C
D
F
A
But
I
want
to
be
sure
that
there's
plenty
of
time
for
questions
and
for
the
discussion
so
from
a
product
and
team
perspective,
each
segment
could
represent
a
collection
of
features
within
gitlab
that
help
to
serve
a
specific
set
of
workflows
for
a
user
and,
as
you
can
see,
each
of
us
is
assigned
to
a
separate
portion
of
this
process,
which
means
that
we
aren't
always
working
on
the
same
features
together.
But
we
are
working
on
the
same
product
together.
A
So
now
that
I've,
given
you
just
a
bit
of
background
on
gitlab
and
our
team,
I
would
like
to
shift
focus
to
our
panelists.
With
a
few
questions,
I've
heard
from
students
previously
again
I'll,
set
aside
some
time
for
additional
questions
at
the
end.
So
if
you
would
make
notes
of
those
in
the
document-
or
you
can
just
hang
on
to
those
questions
until
we
get
to
that
point
panelists,
if
you
could
keep
your
responses
to
maybe
one
to
two
minutes
max,
that
would
be
great
just
so.
We've
got
plenty
of
time
for
everyone.
A
B
Yeah,
I
mean
I'm
sure
I
better
say
this.
Your
days
vary,
but,
generally
speaking,
when
I
wake
up,
I
try
and
get
myself
something
a
little
bit
easier
to
get
my
day
started,
so
I'm
digging
through
mentions
through
git
lab.
Sometimes
I'm
triaging
that
through
my
gmail
or
sometimes
it's
actually
in
gitlab
itself,
I'm
responding
to
questions
that
may
have
come
up
asynchronously
from
colleagues
in
other
countries
or
even
ones
that
are
close
by
and
then
I
usually
like
to
look
ahead
of
the
meetings
that
I
have
for
the
day,
which
usually
is
like.
B
Once
I
have
that
out
of
the
way,
I
usually
have
a
few
design
opportunities
that
I'm
focused
on
for
a
given
quarter
or
a
milestone
that
we're
working
in
so
then
I'll
usually
work
on
those
items
by
either
creating
specific
wireframes
or
mockups
or
begin
research
efforts.
It
all
kind
of
depends
on
what's
the
priority
for
that
section
of
time,
and
then
usually
I
try
and
squeeze
in
a
coffee,
chat
or
so,
which
is
meeting
up
with
another
teammate
virtually
just
to
casually
catch
up.
Talk
about
things
could
be
work,
related
could
be
personal.
E
So
it's
gonna
sound,
very
similar
to
austin,
which
is
exciting,
so
we
have
some
consistency,
but
I
like
to
start
my
day
also
looking
at
those
to
do's,
which
is
any
time
someone
would
find
something
to
me
or
mentioned
me
or
anything
like
that.
Most
of
my
team
is
in
the
states,
so
they're
ahead
of
me.
So
I'd
like
to
respond
to
everything
they
did
in
their
afternoon
first
thing
in
the
morning,
then
I
usually
get
a
couple
of
hours,
and
this
is
where
I
devote
my
time
to
my
work.
E
F
Sure
so
again,
I
think
you're
gonna
start
hearing
some
themes
here,
but
I'm
kind
of
lucky
that
all
of
my
meetings
tend
to
be
in
the
morning
just
and
and
it's
amazing
to
hear
how,
like
some
folks,
just
based
on
geographic
regions,
sometimes
that
stacks
at
the
end
of
the
day,
and
sometimes
that
start
stacks
at
the
beginning
of
the
day.
But
for
me
it's
in
the
in
the
morning,
so
yeah
first
thing
in
the
morning
check
asynchronous
communications.
F
F
So
I
like
to
see:
what's
progressed,
what's
coming
up
that'll,
let
me
know:
what's
going
on,
usually
sit
through
my
meetings
and
then
based
on
what
has
popped
up
in
those
in
those
emails
and
slack
messages,
I'll
I'll
start
digging
into
stuff
and,
like
others
mentioned,
sometimes
that's
doing
some
product
design,
sometimes
that's
just
digging
through
the
product
and
researching
and
seeing
how
this
feature
works
and
a
lot
of
testing
and
a
lot
of
things
like
that.
So
yeah,
that's
better!
For
me,.
C
Yeah,
so
as
someone
in
europe,
I
I
I
prefer
having
my
meetings
at
the
end
of
the
day,
which
is
lucky
because
most
of
my
meetings
are
with
the
team
in
the
us.
So
that
means
I
have
the
morning
to
have
some
focused
deep
work
where
I
can
sort
of
concentrate
my
time
on
some
of
my
like
biggest
sort
of
design
tasks.
Things
that
I
just
sort
of
need.
C
Some
uninterrupted
time
on
this
is
one
of
like
the
biggest
benefits
I've
found
from
being
a
designer
in
asynchronous
work
is
you're
able
to
carve
out
a
lot
more
time
for
for
deep
work
and
deep
thinking,
which
I
really
appreciate
as
a
designer.
That's
that
really
helps,
rather
than
being
disrupted
all
the
time
when
you're,
in
the
middle
of
like
some
some
thinking.
C
Apart
from
that,
I
have
meetings
like
everyone
else,
but
I
on
a
day-to-day
basis.
I
try
and
bring
in
a
little
bit
of
time
to
think
about
a
certain
feature
that
I'm
working
on.
I
try
and
dedicate
a
little
bit
of
thinking
time
to
our
broader
design
system
and
some
of
the
components
for
the
way
that
we
we
structure
it
as
a
broader
team,
and
I
also
like
to
dedicate
some
more
of
my
time
to
like
the
culture
of
gitlab
as
well.
C
D
A
Thank
you
so
much
so
I'm
just
gonna
go
through
the
same
process
again,
but
with
a
new
question
here.
The
reason
I
like
to
ask
this
question
is
because
I
do
know
that
we
have
a
lot
of
students
on
the
call
and
we
have
a
lot
of
folks
who
are
going
to
be
hopefully
entering
the
design
workforce
soon,
and
I
know
all
the
senior
designers
and
other
designers
here
on
the
call
know
that
this
is
a
common
question
when
you're
interviewing.
G
B
Our
handbook
and
meet
those
same
strategies
generally
speaking,
though
it's
essentially
trying
to
take
whatever
idea,
has
been
proposed
and
being
able
to
help
bring
vision
to
that,
whether
that's
visually
or
through
some
other
means
and
then
validating
that.
That
idea
is
useful
and
valuable
to
our
customers
or
proposed
user
base,
and
then
once
we
feel
confident
in
that
it
moves
into
our
build
track.
So
that
might
mean
that
I'm
building
low
fidelity
wireframes
to
help
conceptualize
the
layout
of
the
page.
That
could
mean
going
and
digging
into
metrics
to
understand.
B
B
A
G
E
For
sure
very
similar
to
austin,
I'm
gonna
say
the
handbook
kind
of
shows
everything
that
we
do
in
terms
of
how
we,
how
we
work
and
things
like
that.
So
that's
a
great
resource.
If
you
want
to
investigate
that,
if
I
wanted
to
give
it
kind
of
a
high
level
overview,
I
would
say
that
my
design
process
is
broken
up
into
three
pieces.
E
The
first
piece
is
devoted
to
exploration
and
understandings.
This
is
when
I
like
to
do
problem,
validation
or
discovery,
research
and
talk
to
users,
so
I
can
understand
what
it's
like
for
them
to
have
this
problem
I
like
to
partner
with
the
product
manager
or
other
stakeholders
involved
in
whatever
it
is
to
understand
what
value
is
the
business
going
to
get
out
of
it?
What
are
they
hoping
to
achieve
in
the
long
term
versus
right
now
and
really
get
a
broad
understanding
of
what
is
going
on
here?
E
We
think
you
have
a
problem
or
something
that
could
be
better
or
something
you
want
us
to
invest
in.
We
want
to
build
this.
Try
using
it
now
tell
us,
did
it
actually
make
it
better
and
assuming
we
get
a
good?
Yes,
that's
awesome.
We
move
forward.
The
more
realistic
answer
is
yes,
but
which
is
most
of
it's
good.
We
need
to
make
some
adjustments
or
the
third
one
is
totally
possible,
which
is
didn't
quite
hit
the
mark.
We
should
do
it
again.
F
Yeah
so
I
like
to
spend
most
of
my
time
in
the
first
phase
of
ian's
three
phases
there.
I
I
to
me
problem
investigation
is
where
it's
at
so
it's
interesting.
We
talk
about
design
so
much
and
and
and
well,
I
think
a
lot
of
times.
We
focus
on
that,
but
in
in
what
I've
found
in
my
career
and
in
life
in
general,
just
the
better,
you
can
understand
a
problem,
the
better
you
have
a
chance
of
solving
it
and
there's
a
tendency
to
jump
right
to
that
solving
part.
F
But
I
like
to
spend
as
much
time
as
I
can
understanding
the
problem
from
every
angle.
You
know
doing
user
research,
but
is
a
huge
part
of
that,
but
also
just
going
into
the
product.
We
have
a
very
complex
product
so
to
even
get
started
on
something
a
lot
of
times.
You
have
to
go
in
and
understand
it
read
some
documentation.
Do
some
testing
try
some
things
out?
Sometimes
that
requires
setting
up
environments
and
and
test
projects,
and
things
like
that.
F
But
if,
if
you
take
the
time
to
do
that,
I
think
it
really
sets
you
up
to
you
can't
solve
a
problem
that
you
don't
understand
is
basically
what
I'm
trying
to
say
so
so
number
one
dig
into
that
problem,
and
then
there's
that
that
is
the
happy
phase
like
ian
says
right
once
you
get
that
understanding
there
is
that
that
fun
little
moment
where
you
get
to
do
that
design
work
that
I
think
we
that
we
all
hold
very
high.
But
that
is
a
very
fleeting
thing.
F
A
lot
of
times
you
spend
a
little
bit
of
time.
There
do
do
that
and
then
it
comes
the
next
phase
of
like
okay.
This
is
what
we
want,
but
what
can
we
actually
build?
So
then
it's
a
lot
of
times
breaking
it
down
with
your
product
managers
and
the
engineers
and
things
like
that
and
comparing
what
the
ideal
end
goal
state
would
be
versus
what
we
can
do
in
a
realistic
manner
and
then
formulating
a
plan
how
to
get
from
point
a
to
point
b.
C
I'm
just
gonna
copy
and
paste
everyone
else's
answer
into
the
into
the
chat,
but
yeah,
as
everyone
said.
I
completely
agree
with
what
everyone
said
I
I
like
to
as
a
designer
who's,
not
particularly
great
at
ui
and
likes
to
bring
in
as
many
ideas
as
possible.
I
like
to
sort
of
act
a
little
bit
more
like
a
facilitator
within
my
design
process,
so
within
the
problem
space
within
solution
space
using
my
design
skills
to
make
it
clear
play
back.
C
What
is
the
problem
and
try
and
create
some
frameworks
or
ways
of
explaining
more
clearly
what
the
problem
is,
so
people
can
contribute
to
that
and
again
sort
of
iterating
and
playing
back
that
and
and
doing
the
same
in
in
the
solution
space
as
well
of
thinking.
What
are
the
potential
solutions
posing
what
the
problem
is
to
people
collecting
feedback
and
using
that
overall
to
sort
of
shape
and
and
and
move
the
solution
forward.
A
Thank
you
so
much
nick
and
just
a
quick
note
to
everybody
on
the
call.
I
know
that
I
recap
this
a
lot
in
in
class,
but,
as
you
can
see,
collaboration
is
such
an
important
part
of
ux.
I
mean
it's
it's
something
that
your
hiring
managers
are
going
to
be
asking
about.
So
again,
you
can
see
talking
with
others
on
your
teams
with
stakeholders
with
users.
That's
all
a
huge
part
of
ux
same
question.
Please.
D
Sure
so
I
have
put
a
link
in
the
in
the
document,
which
is
for
a
handbook
page
that
I
maintain
along
with
my
product
manager.
We
actually
worked
like
pretty
hard
to
come
up
with
a
process
for
our
particular
group,
keeping
in
mind
all
everything
that
existed
since
before
the
the
rituals
that
we
used
to
follow
since
before
and
the
product
development
workflow.
That
is
defined
in
the
handbook
for
the
whole
of
gitlab
and
that's
where
the
exact
steps
are
documented.
D
But
apart
from
that,
I
would
also
like
to
talk
about
how
the
process
has
evolved.
Since
I
started
working
for
gitlab,
so
my
it
has,
it
evolved
in
a
way
that
it
is
a
very
it.
This
is
a
domain
which
is
very
technically
complex,
so
which
is
the
reason
that,
instead
of
including
stakeholders
at
a
later
stage,
I
now
keep
them
involved
since
the
very
beginning
of
the
entire
process.
D
D
I
ask
a
lot
of
stupid
questions,
I'm
kind
of
popular
for
that,
maybe
and
then,
as
soon
as
I
put
up
the
very
first
after
the
design
on
the
issue,
I
broadcast
it
on
the
messaging
platforms
and
the
issues
like
I
tag
everyone,
so
that
there's
enough
visibility
for
everyone
to
look
at
it
at
a
very
early
stage.
So
the
direction
that
I
take
from
there
on
is
something
that
we
all
agree
upon
or,
if
not
agree
upon,
at
least
that
something
that's
right
for
the
product.
A
Thank
you
so
much
so
we're
going
to
move
on
to
the
last
question
and
then
I'll
open
it
up
for
questions
from
the
group.
So
what
tools
and
technologies
do
you
find
essential
for
product
designers?
I
didn't
specifically
say
here
at
get
lab
only
because
I
know
that
we're
kind
of
all
working
on
the
same
tools,
but
if
there
are
any
additional
tools
that
you
personally
find
valuable
or
have
found
valuable
in
the
past,
I
would
love
to
hear
about
those
as
well,
and
this
would
start
with
austin
again.
B
Yeah,
I
try
to
generalize
it
a
little
bit
having
a
good
software
support
your
design
process
that
can
be
whatever
it
works.
Well
for
you,
if
you
know
sketch
figma
and
vision,
adobe
xd
any
of
them,
you
can
switch
between
them
for
the
most
part
and
then
being
able
to
jump
into
user
research.
Software
has
also
been
helpful
for
synthesizing
results
like
using
whiteboarding
tools
like
mural
or
whatever
your
team
might
be
using
at
the
time
project
management.
B
B
Hopefully
it's
get
loud,
but
then
the
other
ones
that
are
kind
of
random
that
I
thought
are
a
little
bit
more
niche,
but
very
helpful
to
me
is
being
able
to
use
the
developer
console
a
bit
to
dig
through
elements
and
and
manipulate
them
so
like
when
you
right
click
in
the
browser
inspect
element,
you
can
change
things.
That's
helpful
for
just
kind
of
sometimes
quickly
mocking
something
up
or
better
understanding.
B
If
this
is
a
bug
or
something's
going
on
and
markdown
has
been
pretty
huge,
at
least
slightly
for
me,
everything
that
I
write
ends
up
being
in
markdown,
which
isn't
like
a
crazy
syntax
or
anything,
but
it
does
seem
to
become
like
the
universal
way
of
formatting
text
in
the
web
as
whether
that's
you're,
using
slack
or
if
you're,
using
git
lab
or
any
other
tools.
You'll
see
markdown
used
a
lot
and
that
helps
you
better
communicate
your
ideas.
E
So
everything
austin
just
said
is
a
great
place
to
start
two
things
that
I
would
have
kind
of
added
to
it
that
I've
discovered
recently
that
have
really
helped
one
is
a
tool
called
loom.
It
allows
you
to
record
your
screen
and
yourself
talking
it
posts
it
up
into
the
cloud
and
gives
you
a
nice
little
link.
E
It's
even
helped
me
review
the
design
out
loud
and
I've
had
several
moments
of
like.
Oh
now
that
I
say
it
out
loud
that
doesn't
work
so
that
little
tool
has
actually
really
helped.
Me
revise
my
own,
my
own
design,
to
communicate
more
effectively
with
my
team,
which
is
kind
of
the
the
biggest
challenge.
I
think
as
a
designer
is
to
be
a
really
good
communicator.
A
E
No,
I
can
come
up
with
a
second
one.
Let's
see
challenge
accepted,
I
think
the
next
tool
that
I
would
really
pay
attention
to
is
how
you
organize
yourself.
So
what
to
sell
to-do
list
manager
when
you're
a
designer,
you
spend
a
lot
of
time
communicating
with
a
lot
of
different
people
and
they
share
a
lot
of
information.
F
I
got
nervous
because
I
thought
when
he
was
talking
about
organization,
I
thought
he
was
about
to
steal
mine,
but
I
would
just
say
regardless,
whatever
tool
you
use,
whether
it's
sketch
figma
indesign
photoshop,
whatever
organization,
is
a
huge
key
to
that,
whether
you're
going
full
on
design
system
or
if
it's
a
smaller
project
that
doesn't
require
all
that.
How
you
organize
your
assets
within
that
tool
is
almost
just
as
important
as
that
tool
itself.
F
So
I
would
highly
recommend
coming
up
with
some
sort
of
organizational
system
that
worked
for
you
and
once
you're
in
an
organization
that
works
for
that
organization,
so
organization,
very
much
an
important
part
of
that
and
then
another
one
austin
hit
on
a
little
bit
that
I
that
I
love
to
use.
I
use
this
all
the
time
if
you
are
fortunate
enough
to
work
on
a
fairly
mature
application,
like
austin,
said
doing
a
little
bit
of
editing
of
html
and
css
in
the
actual
product.
F
A
C
No
probs,
so
I
always
really
enjoyed
paper
and
pen,
but
that's
sometimes
quite
difficult
on
on
the
web,
so
one
tool
that
I've
been
using
quite
a
lot
recently
is
procreate,
which
is
a
weird
name,
but
it's
a
really
good
ip
ipad,
app
that
you
can
use
with
an
apple
pencil,
and
I
tend
to
screen
record
that
and
talk
through
ideas
or
problems
and
mapping
stuff
out
and
share
that
on
youtube.
So
people
can
provide
feedback
on
that
sort
of
stuff.
C
So
that's
sort
of
a
way
that
I
use
that
app
to
to
sort
of
take
the
role
of
of
of
doing
a
whiteboard
sort
of
session
that
you
may
do
face-to-face
with
people
and
yeah.
When
it
comes
to
tools
and
technologies,
everything
that
everyone
else
said
you
can
be
pretty
interchangeable
with
them
once
you
sort
of
get
the
knack
for
it,
but
just
remembering,
like
they're
just
modalities
of
of
communication,
so
the
core
of
it
is
understanding.
D
But
here
what
we
get
to
do
is
we
get
to
put
our
designs
in
the
issue
itself
and
the
or
the
conversation
is
so
organized,
and
all
of
that
happens
without
leaving
the
context
of
the
issue,
which
is,
I
think,
the
best
and
for
everything
that
we
don't
do
on
gitlab.
I
prefer
figma
because
of
course,
sigma
has
kind
of
replaced
a
bunch
of
tools
from
the
past
I
mean
if
you,
if
I
would
have
had
to
answer
the
same
question
say
five
years
ago.
D
I
would
have
named
three
four
different
tools
for
mind:
mapping
for
a
collaboration
for
making
vector
objects,
but
now
it
all
happens
all
at
one
place,
so
yes,
figma
and
loom.
Of
course
ian
talked
a
lot
about
that
and
it
is
really
very
helpful,
especially
when
we
are
divided
by
time
zones
and
we
are
not
available
for
each
other
all
the
time.
It
really
makes
a
huge
difference
when
we
record,
like
just
five
minute
videos
about
what
we
are
working
on
and
what
our
idea
is
all
about.
D
So
that
has
really
helped
me
in
my
process
and
last,
but
not
the
least
the
bear
app.
So
that's
where
I
take
my
notes
and
a
good
part
about
that
is
when
you
take
notes
there,
it
lets
you
copy
the
same
notes
as
markup
markdown
html.
So
that's
that's
very
helpful,
like
you
can
put
it
at
different
platforms
without
even
thinking
about
reformatting.
It.
A
Thank
you
so
much
all
right,
so
it
looks
like
we
have
a
lot
of
good
questions
and
answers
already
popping
up
in
the
document.
Please
do
put
those
additional
questions
in
for
the
panel
if
you
have
any,
but
let's
just
kind
of
quickly
run
through
and
and
go
over
some
of
these
as
a
group
so
vitica
it
looks
like
the
first
answer
was
from
you
and
the
question
was:
how
has
your
background
helped
you
in
your
role.
Do
you
mind
just
kind
of
touching
on
what
your
response
was?
There.
D
I
started
off
as
a
visual
designer
and
I
work
for
various
agencies,
advertising
agencies
and
graphic
design
agencies,
and
even
though
I
have
not
done
that
in
a
very
long
time,
but
it
has
definitely
given
me
an
eye
for
perfection
when
I,
when
I'm
creating
something
visual
and
also
a
sense
of
composition,
which
is
very
important
in
our
work.
Apart
from
that,
I
have
my
education
background.
My
education
background.
I
have
a
degree
in
game
design
and
I
would
say
that
has
totally
flipped
my
mental
model
and
how
I
look
at
things.
B
B
Yeah
absolutely
yeah,
I
used
to
work
a
really
big
company
and
I
used
gitlab
there
so
having
that
personal
usage
is
definitely
helpful.
So
this
is
a
bit
more
tailored
to
my
experience
of
working
at
git
lab,
but
my
educational
background
was
in
business.
I
have
an
mba
I
focused
in
it.
So
being
able
to
always
talk
about
value
with
my
product
manager
has
been
huge.
B
E
So
speaking
of
education
and
background,
my
education
was
actually
in
architecture
and
design
theory,
which
is
a
little
different
than
product
design
for
sure.
But
one
of
the
things
that
happened
was
it's
a
very
competitive
space
to
try
to
work
in,
and
so
when
they
are
doing
design,
critiques
and
design
reviews,
they
can
be
a
little
harsh.
E
What
I
learned
was
through
the
process
of
kind
of
doing
it
over
and
over
again
was
how
to
take
feedback.
How
to
correctly
ask
her
feedback,
how
to
gather
a
lot
of
responses
from
something
I
created
without
taking
it
personally,
and
it
changed
how
I
thought
about
feedback.
Suddenly
I
could
be
like
the
design
is
fine.
B
Yeah
so,
like
I
said,
I
used
it
like
my
last
job,
so
I
really
loved
it
as
a
tool
and
when
I
was
ready
to
start
looking
for
new
opportunities,
I
could
get
loud.
In
the
back
of
my
mind,
they
were
just
hiring
designers
just
at
the
right
time.
That's
kind
of
how
it
works
out
some
in
some
cases,
but
the
biggest
factor
that
attracted
me
was
the
all
remote
pre-covered.
B
That
was
not
a
common
thing
and
my
wife
works
in
the
emergency
department.
So
her
schedule
is
really
weird
and
I
was
looking
for
more
autonomy
over
my
schedule
day
to
day
so
like
this
week,
she's
off
tuesday,
wednesday
thursday,
and
it's
been
awesome
to
be
able
to
have
lunch
with
her
and
go
on
walks
in
the
middle
of
the
day.
Those
were
things
that
I
was
otherwise
not
having.
D
Oh,
so
ever
since
I've
had
joined
college
for
a
master's
education,
I
used
to
follow
the
creative
commons
and
the
open
source
movement
very
closely,
and
I
was
a
big
fan
and
I
had
since
ever
I've
been
trying
to
get
into
organizations
that
follow
similar
practices,
and
I
think
gitlab
is
the
most
open,
ark
and
transparent
organization
that
I
found
so
far.
So
here
I
am.
A
E
So
in
that
situation,
I
tend
to
look
for
two
different
things:
one.
I
really
want
to
know
how
comfortable
the
candidates
are,
communicating
either
one-on-one
during
our
interview
and
how
do
they
communicate
with
a
broader
audience
they're
going
to
have
to
interact
with
a
lot
of
people
they're
going
to
have
a
lot
of
questions.
If
they're
on
the
more
junior
side,
I
would
want
to
know
which
one's
going
to
be
more
comfortable
there.
The
second
thing
I
look
for
is:
how
excited
is
the
candidate
to
talk
to
the
users?
E
A
F
Yeah
I'll
just
say,
passion
is,
in
my
opinion,
does
if
you
are
passionate
about
design
you're,
a
good
designer,
whether
you
have
the
skills
or
not
yet
is
irrelevant.
Those
can
be
taught.
But
if
you
really
love
this
stuff,
you'll
end
up
being
good
at
it.
So
I
passion
is
the
number
one
thing
I
look
for
when
I'm
talking
to
candidates.
A
D
A
C
Yeah
sure
there's
so
much
from
so
many
people
to
learn
and
when
I'm
interviewing
junior
designers
there's
plenty
that
junior
people
can
teach
me.
So
I
often
look
for
interesting
traits
skills
things
that
they
could
potentially
teach
me
if
we
were
to
work
together.
So
that's
that's
something.
I'd
look
for.
A
B
Yeah,
I
mean
everybody's
kind
of
hidden
already,
but
it's
that
general
notion
of
especially
if
they're
a
junior
designer
I'm
not
looking
to
see
like,
can
they
create
this
flashy
animation
that
can
transition
all
these
screens
together
and
make
it
feel
like
everything's
already
made
for
production,
I'm
more
interested
in
how
are
they
going
to
work
with
my
team?
How
are
they
communicating
the
ideas
that
they
have?
How
do
they
think
through
problems
you
might
run
into
scenarios?
B
Are
you
doing
a
whiteboard
exercise,
an
interview,
or
maybe
you're,
given
a
case
study
to
take
home
and
present
back?
It's
more
all
about
that
presentation
and
better
understanding?
How
are
you
going
to
work
with
people,
because
that
is
where
you
spend
80
of
your
time,
maybe
like
20
of
it,
is
actually
heads
down
like
making
things,
but
you
spend
so
much
of
your
time.
Writing
words
saying
words,
and
so,
if
you
can
do
that,
well,
then
that's
what
really
matters.
A
Thank
you
so
much
so
it
looks
like
the
next
question
is
regarding
growth.
Since
the
beginning
of
your
careers
in
the
field
of
ux,
how
do
you
feel
that
you've
changed
or
grown
not
only
as
a
designer,
but
also
a
professional,
possibly
even
as
a
person
austin,
it
looks
like
you've
also
got
that
next
response.
B
Yeah
sure
so
I've
moved
from
being
like
super
intrigued
by
like
visual
design,
and
that
might
be
partly
because
I
work
on
more
enterprise
based
applications.
Even
in
my
last
role,
productivity
is
a
huge
measure,
so
I'm
not
trying
to
convert
people
to
buy
things,
I'm
not
trying
to
make
the
next
instagram.
That
is
a
different
scope.
I'm
not
trying
to
get
people
to
buy
things
through
shopify,
so
I've
definitely
focused
more
on
productivity,
which
leads
to
asking
questions
more
around
like.
Why
are
you
trying
to
achieve
this?
B
What
are
you
trying
to
do
just
trying
to
truly
understand
what
people
are
doing,
because
they
ultimately
are
hiring
whatever
software
I'm
making
to
do
a
job?
If
my
software
can't
do
the
job
for
them,
then
it's
not
helping
anything
professionally.
I've
just
learned
how
important
it
is
to
treat
work
as
a
team.
Sport
always
champion
your
co-workers.
B
A
I
agree.
Thank
you
so
much
austin,
it
looks
like
we've
had
a
couple
of
folks
join
by
the
way.
So,
in
the
event
that
you
have
recently
joined,
we
are
looking
at
a
document
that
I
posted
in
the
zoom
chat.
A
google
doc
feel
free
to
open
that
up
and
and
toss
in
any
questions.
Thank
you
so
much
marcia
for
putting
that
in
feel
free
to
open
that
up
and
put
in
some
questions.
We
still
got
about
20
minutes
left
to
go
through
so
ian.
E
Yes,
I
think
the
biggest
thing
that
I've
seen
in
my
personal
growth
being
a
designer
for
so
long
is.
I
have
completely
relearned
how
to
ask
the
right
question
before
I
try
to
solve
a
problem.
I
am
a
caregiver
by
nature,
I'm
the
person.
That's
like.
Oh,
I
heard
you
had
a
problem.
I
want
to
fix
it
right
now.
I
had
to
relearn
to
like
take
that
step
back
similar
to
mike's
point
earlier.
E
I
need
to
understand
the
problem.
I
need
to
ask
questions
in
a
way
that
aren't
going
to
bias
the
answers
that
I'm
actually
going
to
get
the
genuine
information.
I
need
to
make
my
choices
and
that
I
ended
up
pulling
into
my
personal
life
and
that's
made
me
a
more
effective
communicator
in
my
relationships.
It's
allowed
me
to
solve
problems
more
efficiently.
A
Thank
you
so
much
ian
I'd
like
to
also
maybe
touch
on
the
fact
that
I
think,
as
designers,
we've
all
had
to
kind
of
give
up
that
desire
to
make
everything
picture
pixel
perfect
before
it
goes
out
and
being
able
to
kind
of
put
out
the
smallest
thing.
First,
even
if
it's
not
exactly
perfect,
you
know
you
don't
want
to
stall
too
much
by
by
adding
in
deep
polish
yeah.
A
It
doesn't
need
to
be
pixel,
perfect
yeah
so
feel
free
to
look
at
ian's
additional
response
there
and
I'm
going
to
move
this
on
just
for
the
sake
of
time.
So
the
next
question
was:
what
would
you
recommend
for
someone
new
in
the
industry
to
look
for
or
look
out
for
when
job
hunting
and
mike
it
looks
like
your
response
was
first.
F
Yeah,
so
just
noting
that
ux
team
size
will
tell
you
a
lot
where
that
organization
is
in
the
process,
if
it's
a
smaller
team
size
or
if
you
are
the
first
designer
that's
being
brought
in
just
know,
you're
getting
into
a
place
where
you're,
probably
gonna,
have
to
build
a
practice
and
and
and
change
that
organization's
path,
which
can
be
a
fantastic
thing.
I'm
not
saying
that
you
should
avoid
that.
Just
know
that
you're
gonna
have
to
dive
in
it's
gonna,
be
a
trial
by
fire,
so
be
ready
for
that.
A
E
Yeah,
I
think
the
first
thing
I
look
for
now
when
I'm
looking
at
a
new
organization
to
join,
is,
am
I
actually
interested
in
the
product
or
the
problem
space
they're
trying
to
solve
when
you're
a
product
designer
you
spend
a
lot
of
time,
learning
about
the
very
nitty
gritty,
tiny
little
details
of
these
flows,
and
if
you
try
to
jump
onto
a
product
that
doesn't
interest
you
in
any
way
it's
going
to
be
really
hard.
I
find
it
anyway
very
difficult
to
convince
myself
to
learn
about
a
product.
I
don't
care
about.
A
Thank
you
so
much
so.
The
next
question
is:
what
percentage
of
your
day
would
you
say,
you're
stressed
on
time,
rushed
to
get
things
done.
Do
you
feel
like
you're,
rushed
on
your
design
process
stages
or
usually
have
the
time
you
need
to
get
the
job
done
well
or
done
and
done
well,
it
looks
like
a
couple
of
the
responses
are
pretty
similar
that
we
don't
necessarily
feel
super
rushed
at
gitlab.
So
I
won't
make
the
shorter
responses.
A
F
It's
phased,
so
there'll
be
times
when
it's
just
crunch
time
and-
and
it
seems
insane
and
then
there'll
be
other
times
when
there's
really
not
much.
To
do
so.
Just
know
that
a
lot
of
times
the
less
agile
company
is
a
lot
of
folks
are
still
in
the
waterfall
world
and
in
the
waterfall
world,
it's
crunch
and
then
not
much
to
do
so.
It's
it's
often
phased
out.
A
C
So
if
you
are
trying
to
accomplish
something
and
there's
a
limited
amount
of
time,
think
about
what
is
it
that
I'm
trying
to
accomplish
and
then
sacrifice
fidelity
in
order
to
sort
of
can
achieve
what
you're
trying
to
do
in
the
best
way.
So
if
someone
says
I
need
to
understand
the
layout
of
a
page,
you
don't
need
to
make
a
pixel
perfect
page.
C
If
you
have
a
smaller
amount
of
time-
and
then
iteration
is
really
useful
here
as
well,
because
you
can
always
iterate
on
top
of
fidelity
and
when
you
put
something
out,
it
means
that
people
can
provide
feedback,
whereas
if
you
don't
put
something
out
regardless
of
how
great
the
fidelity
is,
no
one's
going
to
be
able
to
provide
feedback
on
it.
So
manage
fidelity
and
use
iteration
to
your
advantage.
And
that
should
help
in
when
you
are
pressed
for
time.
D
Sure
I
mean
we
have
no
reason
to
be
in
that
position,
because
if
we
are
doing
a
communication
and
iterations
right
at
gitlab,
we
definitely
should
never
feel
the
stress.
But
to
me
it
happens
mostly
towards
the
end
of
our
milestone.
Milestone
is
a
30
days
period
that
we
consider
as
a
release
cycle,
and
it
could
very
well
be
a
personal
trait
which
I've
written
in
the
document
as
well,
because
as
we
near
the
deadline
for
the
milestone,
I'd
get
really
worried
about
what
could
go
into
implementation.
D
A
G
B
Gitlab's
a
great
example
of
where
we
really
focus
on
this
thing
called
asynchronous
communications
like
how
you
communicate
things
when
no
one
else
is
there
to
listen
to
you
say
them:
your
portfolio
stands
as
an
asynchronous
object.
People
are
looking
at
it
and
learning
things
and
how
you
communicate.
Those
things
is,
what's
most
important
to
me.
I
would
say
the
mistakes
I
see
are
people
only
posting
screenshots,
yes,
and
it
is
great
to
see
you
can
make
visual
aesthetic
things
that
look
great,
show
great
understanding
of
color
theory
or
how
human
psychology
works.
B
But
if
there's
no
words
that
I
can
understand
from
that,
then
it's
hard
to
discern
what
you
did
with
it.
It's
okay!
If
you
post
things
to
dribble
dribble's
great,
I
use
it
all
the
time
to
look
at
stuff,
but
there's
a
difference
between
using
something
to
communicate
ideas
and
to
show
off
your
visual
muscles.
F
C
It's
just
reiterating
what
mike
said
in
a
different
way:
people
who
communicate
the
outputs
of
a
particular
project
rather
than
the
the
process
and
what
they
went
through
and
communicating
the
value
that
came
from
whatever
it
is
that
they
produced
so
showing
the
outputs
is
great,
showing
the
beautiful
things
you
can
create
is
great,
but
also
demonstrating.
The
process
that
you
came
to.
Those
beautiful
outputs
is
is
more
important
when,
judging
whether
a
person
is
suitable
for
a
company
or
not.
A
A
Very
good,
thank
you
so
much
so.
The
next
question
is
when
laying
out
case
studies
for
your
portfolio.
What
is
too
much
and
what
level
of
detail
is
most
important.
I
don't
actually
see
a
response
to
that
one
at
the
moment,
so
I'm
gonna
move
this
on
because
we
look.
We
do
have
a
lot
of
additional
questions
and
only
about
10
minutes
left
but
panelists.
If
you
want
to
post
anything
in
there
feel
free
to
do
that.
Just
so,
everyone
can
see
those
responses
and
I'll
move
on
to
the
next
question.
A
B
B
To
show
anybody
that
worked,
but
if
your
company's
not
designed
for
it,
I
get
that
I've
worked
with
some
really
ugly
front,
end
ui
elements
and
there's
nothing.
I
can
do
to
affect
that.
So
that
does
show
up
in
the
way
that
my
designs
are
because
I'm
constrained
to
like
what
our
development
team
could
make.
B
The
most
important
thing,
I
would
say,
is
try
and
communicate
the
problem
that
you're
solving
and
how
you
solve
that
problem
for
users,
because
at
the
end
of
the
day,
people
in
business
want
to
make
money
and,
if
you're,
making
their
users
more
efficient
or
you're
bringing
in
more
revenue.
Regardless
of
how
the
ui
looks.
F
F
That's
a
great
opportunity
to
say
you
know
this
might
not
be
pretty,
but
here's
where
the
challenge
is,
and
here's
how
I
here
were
the
wins
that
I
got
against
those
and
sometimes
showing
that
you
can
fight
against
a
difficult
situation
is
more
impactful
than
you
know.
Everybody
at
google
is
successful.
F
A
B
Yeah,
the
the
project
question
is
a
difficult
one,
because
we
don't
think
about
work
at
gitlab
in
terms
of
projects.
We
really
think
about
it
in
terms
of
problems
that
we're
trying
to
solve.
So
I'm
shouldn't
say
I
try
and
solve
three
or
four
different
problems,
maybe
at
most
of
the
time
that's
simply
try
and
minimize
the
amount
of
context.
A
E
No,
I
don't
want
to
say
everyone's
time.
I
could
actively
work
on
two
or
three
design
projects
at
a
time
after
that
trying
to
do
those
two
designs,
the
context,
switching
gets
so
expensive
that
I
spend
so
much
time
trying
to
remember
what
I
was
going
to
do
instead
of
just
doing
it.
That
being
said,
I
can
manage.
E
I
think
the
most
I've
ever
done
is
about
15
projects
and
those
are
just
15
things
that
are
going
to
be
worked
on
or
in
progress
or
if
it's
an
agency
like
these
are
pitches,
or
these
are
possible
things,
but
a
lot
of
them.
I
can
keep
track
of
touching
on
a
lot
of
them,
but
I
can
only
actively
have
a
public
project.
B
Yeah
again
go
back
to
like
problem
point
for
gitlab,
I
would
say
we
usually
get
about
a
month
to
work
on
a
problem
space
before
it's
expected
to
really
be
pushed
into
the
build
track.
There
are
times
where
things
arise,
they're
like
okay.
We
need
to
really
get
this
from
idea
to
production
in
a
couple
weeks,
but
those
are
rare
unless
you're
in
maybe
more
mature
area
of
the
product,
but
generally
for
me,
I
see
about
a
month.
You
can
scope.
A
Thank
you
so
much.
Some
of
the
questions
here
have
maybe
more
brief
responses
like
typical
hours
and
a
work
day,
so
I'm
going
to
actually
skip
those
to
some
of
the
ones
that
might
have
a
little
bit
more
complexity
in
the
response.
Just
so,
we
can
get
as
much
value
out
of
the
last
few
minutes
as
possible.
A
B
Yeah
so
I'd
say,
like
the
technical
part,
at
least
the
gitlab
isn't
normal
for
everybody,
but
we
have
to
review
code
changes
that
come
in,
so
this
is
checking
out
code.
So
it
requires
some
level
of
knowledge
of
git
and
understanding
how
to
get
that
code
change
locally
to
build,
and
sometimes
you
get
allowed
to
have
to
configure
things
to
make
it
appear.
So
that
can
be
a
bit
of
a
challenge
more
administratively.
This
is
maybe
more
to
the
design
process.
B
I
would
say
gathering
evidence
is
hard,
it's
easy
to
like
pitch
this
great
idea
and
then,
when
they
say
where's
the
evidence
that
we
should
make
it
it
then
just
like.
Okay,
now
I
gotta
go
find
metrics.
I
gotta
go
conduct
some
user
research.
I
have
to
go
validate
this
thing
somehow
some
way
we
do
have
a
back
door
saying
like
okay,
we
definitely
know
like
we
should
change
this
button
from
blue
to
red.
Okay,
that's
fine!
B
A
Thank
you
so
much
austin
by
the
way,
I'm
gonna
put
him
on
the
spot
just
a
little
bit,
but
we
have
again
one
of
our
ux
writers
on
the
call
mark
martian.
So
if
you
have
any
questions
related
to
that,
if
you
would
just
post
those
in
the
document
and
russian,
if
you
don't
mind
just
kind
of
keeping
an
eye
out
eye
out
and
responding
to
those,
that
would
be
awesome
as
well.
Sorry
to
put
you
on
the
spot.
E
Because
it's
asynchronous
is
knowing
just
how
annoying
I
need
to
be,
because
design
is
not
always
everyone's
first
focus,
especially
engineers.
They
have
code
product
management,
they
have
a
lot
of
talks
and
customers
and
failed
and
all
those
things
so
finding
out
just
the
right
amount
of
okay,
everyone.
I
need
you
to
give
me
feedback.
Okay,
I'm
still
waiting
on
feedback
that
you're
getting
responses,
but
no
one's
frustrated
because
you're
annoying
them.
It's
a.
A
D
A
Thank
you
so
much.
That
is
a
great
point
as
well.
That's
definitely
something
that
I
have
also
dealt
with
in
the
past,
so
we've
got
about
two
minutes
left.
Let
me
just
quickly
skim
and
see
if
there's
anything
else
that
might
be
worth.
These
are
all
great
questions
by
the
way.
Thank
you
all
so
much
for
putting
those
in
coming
from
different
industries.
A
How
have
your
strengths,
weaknesses
and
skills
affected
your
design
process,
and
thank
you
so
much
to
whoever's
going
through
and
marking
those
in
bold.
That
does
make
it
a
little
bit
easier,
let's
actually
wrap
up
with
the
last
question
of
impact
and
austin.
It
looks
like
you
have
a
response
to
that.
But
what
impact
do
you
feel
that
you've
made
on
the
product.
B
B
Sometimes
my
features
have
come
up
like
in
reddit
threads
or
on
public
forums,
which
is
sometimes
encouraging
or
challenging,
depending
on
what
the
feedback
is.
So
in
some
ways,
it's
really
rewarding
to
me
to
see
that
some
of
the
work
that
I'm
doing
is
recognized
by
people
in
the
industry.
So
I
do
feel
like,
even
though
I
work
on
a
very
focused
part
of
the
application.
A
Thank
you
so
much
austin.
We
are
right
at
about
time.
So
if
you
do
have
any
additional
questions
that
you
want
to
address
with
the
panel
feel
free
to
post
those
into
the
document,
and
maybe
our
panels
would
be
kind
enough
to
just
kind
of
review
those
for
a
couple
more
minutes
and
type
those
in,
but
I
want
to
say
thank
you
all
again
to
everyone
that
joined
us
today.
Thank
you
so
much
again
to
the
panelists
who
came
in
and
gave
their
amazing
responses.
This
was
really
helpful
and
really
fascinating
conversation.