►
From YouTube: UX Showcase: Engineering Director Personas
Description
Nick shares UX work on creating the Engineering Director Persona in GitLab Manage
A
So
hello,
and
thanks
for
joining
the
York
showcase
I'm
gonna,
be
doing
a
little
bit
of
presentation
on
the
recent
work
that
we've
been
doing
within
manage
analytics
and
how
that's
gone
on
to
inform
the
general
direction
of
our
product
and
some
of
the
insights
that
we
learned
along
the
way
about
our
users,
engineering
directors.
So
my
as
I
mentioned
before
work
in
the
manage
stage
in
the
analytics
group
and
there's
a
bunch
of
very
talented
people
in
there
that
I'm
very
happy
to
be
working
with
my
name
should
be
purple.
A
Er
I,
don't
know
why
it's
not!
But
what
can
you
do
as
you
can
see,
there's
a
lot
of
a
lot
of
our
products
at
the
moment
or
at
minimal
level
of
maturity
and
not
very
lovable,
so
that's
sort
of
because
it's
relatively
new
product
and
we're
sort
of
working
out
as
we
go
but
I'm
going
to
tell
you
a
little
bit
about
how
we've
been
working
on
our
roadmap
so
about
six
to
eight
weeks
ago
we
were
feeling
a
little
bit
lost
in
terms
of
our
product.
A
We
we're
feeling
a
little
bit
unclear
on
the
general
needs
that
we
had
around
our
users
from
past
research.
There
is
a
lot
of
sort
of
variants
and
the
requirements
that
users
were
talking
about.
We
are
receiving
quite
poor
feedback
around
product
productivity
analytics
as
something
that
we
put
out
there
recently
as
an
MVC,
and
our
product
manager
also
left
the
team.
A
So
we
thought
it
would
be
an
important
time
to
basically
press
pause
for
a
little
bit
and
conduct
some
strategic
UX
research
to
do
a
little
little
bit
of
problem
validation,
understanding
a
little
bit
more
about
the
needs
and
wants
of
engineering
directors
in
the
analytics
space
and
use
this
as
like
a
Northstar
to
sort
of
direct
us
in
terms
of
our
vision
and
where
we
want
with
this
analytics
product.
So
our
research
research
goals
are
threefold.
One
was
to
create
some
proto
personas
around
the
engineering
director.
We
don't
have
any
of
those.
A
A
We
did
a
bit
of
guided
discussion,
around
responsibilities
and
jobs
to
be
done
and
that
discussion
followed
on
with
some
sort
of
talk
around
lo-fi
stimuli
and
then,
finally,
we
did
once
we
had
all
this
sort
of
huge
amounts
of
information
we
needed
to
sort
of
organize
it
and
synthesize
it
some
way.
So
we
used
a
lot
of
visual
synthesis
within
mural
around
empathy
maps
and
that
view
other
a
few
other
things
too,
to
try
and
organize
our
thoughts.
So
what
are
some
of
the
insights
that
came
out
of
this?
First
off?
A
We
found
some
similarities
between
customer
and
get
lab
engineering
directors.
First
off
engineering
directors
live
at
the
intersection
of
three
domains:
people,
obviously
the
the
people
who
are
they
are
managing
their
engineering
managers
and
the
indiv
individual
contributors
process,
how
they
go
about,
executing
and
and
creating
code
and
then
product
as
then,
the
code
itself,
the
all
the
stuff
around
creating
something
great
for
and
then.
A
Secondly,
there
was
sort
of
interesting
convergence
where
these
form
around
different
sets
of
working
modes,
and
this
seemed
to
be
apparent,
based
on
like
the
limited
bandwidth
and
volume
and
somehow
finding
a
way
to
manage
their
volume
of
work.
So
firefighting,
lots
of
things
like
an
outage
could
happen.
That
would
mean
that
they
would
sort
of
take
up
a
lot
of
their
time
during
a
day
delegating
towards
people
in
their
team,
coaching
people
in
their
team
and
also
sort
of
driving
strategic
initiatives
and
so
on,
and
then.
A
Finally,
there
is
also
a
lot
of
time
of
uncertainty
of
what
people
should
be
doing
specifically
within
gitlab
as
well,
when
there's
so
much
information
noise
to
deal
with
so
processing
seem
to
be
a
interesting
part
of
this
as
well.
We
also
found
a
well
so
off
the
off
the
back
of
this
research,
finding
some
similarities
sort
of
brainstorming
around
what
are
some
of
the
opportunities
that
could
come
off
the
back
of
these
similarities
between
the
gitlab
engineering
directors
and
the
and
the
customer
engineering
directors.
A
A
Secondly,
in
terms
of
some
insights,
we
found
some
interesting
differences
as
well.
Whether
a
engineering
director
or
a
company
was
project
minded
or
product
minded
had
a
big
impact
on
me.
The
way
engineering
directors
looked
at
responsibilities
and
TI's,
so,
for
example,
get
lab
directors
are
very
much
product
minded.
However,
we
spoke
with
a
number
of
consultancies
and
agencies
and
the
way
they
viewed,
responsibilities
was
very
different
because
they
they
organized
in
terms
of
projects,
furthermore
spoke
with
a
bunch
of
engineering
directors
who
didn't
necessarily
have
engineering
managers.
A
They
had
20-30
reports
directly
reporting
to
them
and,
as
you
could
expect,
they're
very
much
overwhelmed
and
this
impacted
the
sort
of
level
of
preference
around
analytics
categories
that
they're
interested
in
and
also
the
sort
of
data
granularity
of
those
analytics
categories,
and
then,
furthermore,
there
is
also
other
responsibilities
that
engineering
directors
potentially
had
based
on
the
size
of
their
companies.
So
we
spoke
with
some
who
worked
with
customers
on
customer
engagement.
A
We
had
some
who
worked
in
sort
of
a
little
bit
around
business
development
project,
scoping,
financials,
lots
of
different
stuff,
so
there's
the
potential
that
they
may
be
wearing
other
hats.
So,
based
on
the
differences
that
we
heard
between
customer
and
get
lab
engineering
directors,
what
are
some
of
the
opportunities?
Well,
how
might
we
cater
to
different
needs
of
project
minded
versus
product
minded
engineering
directors?
How
might
we
help
to
streamline
the
process
of
collecting
contextual
information
from
the
team
on
different
metrics
and
so
on
and
so
forth?
A
So
the
final
insight
that
I
want
to
show
you
is
the
results
of
this
prioritization
exercise
that
I
talked
about
before,
and
this
is
the
PM
for
a
day
thing
and,
as
you
can
see,
these
are
the
get
lab
results
and
the
customer
results.
We
found
some
interesting
similarities
on
this
as
well
in
terms
of
project
health
and
code
review
being
relatively
high
up,
and
also,
very
surprisingly,
productivity
and
value
stream
were
pretty
much
on
opposite
ends
of
the
spectrum.
A
The
way
we
can
rationalize
productivity
being
a
high
priority
for
gitlab
is
we
tend
to
optimize
or
optimized
for
throughput
as
a
company,
whereas
a
lot
of
become
the
customers
that
we
spoke
to
optimized
towards
predictability.
So
that's
another
thing
that
we'll
be
focusing
on
in
the
future,
so
those
are
some
of
the
insights.
There's
loads,
more
insights
in
like
the
full
read
report
that
I've
done.
But
how
did
these
insights
and
how
did
this
overall
research
impact,
what
we're
doing
on
this
product?
A
So
what
and
we
have
sort
of
laid
out
this
road
map
for
our
new
path
forward,
based
on
the
insights
that
we
have,
we've
decided
in
12.6
to
start
working
on
a
code
review
analytics
MVC.
We
chose
this
one
specifically
because
the
create
teams
also
doing
a
little
bit
of
work
on
code
review
MVC.
So
we
thought
there
would
be
some
interesting
areas
for
collaboration
around
that
I
will
be
grooming,
the
backlog
of
jobs
to
be
done.
A
So
we
get
better
statistical
significance
since
there's
only
about
six
customers
and
seven
seven,
seven
directors
who
provided
input
and
thought,
and
we
also
want
to
look
at
how
well
share
this
survey,
not
with
just
engineering
directors
but
engineering
managers
and
individual
contributors
as
well
to
understand
where
analytics
preferences
lie
across
this
sort
of
spectrum
of
hierarchy
and
if
there
are
any
overlaps,
that's
sort
of
a
big
value
driver
there
other
other
things
coming
down
the
way,
but
there's
a
lot
of
solution.
Validation
coming
up.
A
But
to
summarize,
we
we
used
UX
research
to
reorient
ourselves
around
value,
creating
opportunities
for
our
users
by
understanding
some
of
the
core
needs
and
preferences
of
engineering
directors.
Please
go
ahead,
read
the
research
report
that
I
did
in
full
if
you're
interested
and
provide
any
feedback,
and
thank
you
very
much
for
your
time.