►
From YouTube: UX Showcase: Don't sleep on documentation
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
A
So
as
a
ux
designer,
maybe
you
run
into
scenario,
but
have
you
ever
been
asked
to
design
this
portion
of
something
but
forget
about
the
rest
of
the
iceberg,
because
that's
kind
of
what
happened
to
me
with
the
particular
instance
recently
when
I
first
joined
gitlab,
and
then
it
just
recently
reached
production,
so
we're
going
to
talk
through
that
today,
so
how
this
all
started.
I
first
joined
gitlab
about
a
month
into
my
contributions,
and
my
pm
came
to
me
with
what
felt
like
a
really
simple
request.
A
A
So
today,
projects
can
define
individual
pipelines
for
their
projects,
but
there
are
instances
where
organizations
have
thousands
of
projects
they
just
want
to
set
some
sensible
defaults
that
can't
be
overridden
by
projects.
So
I
was
like
yeah,
this
sounds
great,
but
let's
just
put
input
field
in
this
area,
the
settings
you
know
boom
done
and
then
what
what
followed
was
a
lot
of
technical
discussion
that
I
did
not
follow
at
the
time.
A
There's
a
lot
of
things
passed
around
about
yaml
and
pointing
to
things
through
mermaid
diagrams
and
then
explicitly
talking
about
how
to
build
these
things
through
variables
and
triggers
and
includes-
and
I
was
like-
I
have
no
idea
what's
going
on,
but
I
hope
my
design
is
okay,
because
no
one
else
has
really
said
anything
about
it.
Yet
I
was
just
sitting
there.
Thinking
hey
does,
like
form
validation,
sound
good,
like
we
should
probably
make
sure
that
this
file
exists
before
we.
A
Let
users,
you
know,
did
save
changes
on
that
setting
page
and
the
problem
was.
I
wasn't
focused
on
the
like
more
holistic
journey
like
what
happens
as
you're
going
into
author
that
file
or
what
happens
once
you've
saved
it
and
it's
making
changes
downstream.
I
was
just
very
focused
on
just
being
able
to
like
reference
it
somewhere
in
gitlab
to
take
a
quick
aside
here.
So
what
are
we
trying
to
do
for
cameron?
The
main
persona
of
my
group?
A
Well,
we're
simply
trying
to
make
their
workflow
a
little
bit
easier
and
a
little
bit
less
monotonous.
So
this
can
look
like
removing
steps
like
taking
away
the
need
to
track
non-compliance
so
being
able
to
enforce
pipelines
is
one
way
that
that
can
help
reduce
compliance
effort
or
making
things
a
little
bit
easier
by
defining
these
rules
and
settings
in
gitlab
all
right
so
back
to
the
example,
so
that
design
kind
of
like
was
sitting
there
and
it
went
through.
A
You
know,
solution,
validation
and
we
felt
pretty
confident
about
what
we
were
going
forward
with.
We
think
some
different
groups
for
some
feedback
and
it
sat
there
for
a
while
at
some
point
earlier
this
year
ended
up
like
in
the
planning
breakdown
stage
scheduled
into
a
milestone,
and
then
we
shipped
it-
and
I
was
just
sitting
there
thinking.
I
hope
this
goes
well.
A
The
initial
feedback
we
got
was
actually
really
great.
Our
customers
were
very
excited
about
it.
It
gave
them
a
lot
of
the
control
that
they
were
looking
for.
It
was
driving
a
lot
of
ultimate
conversations,
which
is
really
great
from
a
revenue
perspective,
but
what
I
saw
shook
really
quickly
was
a
lot
of
questions
from
our
tams,
like
our
sales
team,
that
interact
with
customers
trying
to
provide
examples
and
help
them
troubleshoot
problems.
A
What
this
was
telling
me
was
our
docs
were
too
thin.
I
couldn't
find
a
older
version
of
the
docs
to
show
here.
This
is
a
more
recent
example,
but
we
didn't
provide
enough
contextual
examples
in
documentation
to
really
help
guide,
both
git
lab
team
members
and
our
customers
through
the
steps
necessary
to
help.
Do
the
task
at
hand.
We
just
were
like
hey
yeah,
you
can
define
this
file
somewhere
and
good
luck
to
you.
We
think
you
know
what
to
do
best
and
that's
not
really
the
case.
A
A
We
really
want
to
bring
in
more
examples
that
are
like
specific
to
cameron
to
help
show
best
practices
or
even
use
cases
that
maybe
others
don't
think
about
oftentimes.
We
hear
from
customers
asking
hey.
What
do
other
companies
like
us
do
in
this
scenario?
We
kind
of
know
the
goal
we
want
to
go
towards,
but
we
don't
know
how
to
do
it
ourselves,
necessarily
so
keeping
that
user
flow
in
mind.
Keeping
those
assumptions
at
the
forefront
can
really
help
extend
our
documentation
and
make
it
useful.
A
I
came
across
this
awesome
quote
somewhere
on
the
internet.
Regarding
our
docs
there
I
saw
a
user
was
trying
to
troubleshoot
how
to
set
something
up
and
they
found
an
example.
They
copy
paste
it
into
their
environment
and
they're
like
hey.
I
don't
know
how
this
works,
it
seems
magical,
but
it
just
worked.
I
could
just
copy
and
paste
it,
so
I
think
more
things
like
that
will
get
users
excited
and
keep
them
involved
in
gitlab
and
making
our
product
more
useful
in
the
end.
A
A
So
with
that
I'll
open
up
to
questions,
if
you
want
to
just
ask
them
directly
or
if
you
like,
to
throw
them
into
the
google
doc,
that's
cool
too.
B
A
I
think
it
definitely
starts
with
better
cross-stage
collaboration,
so
an
example
of
this
would
be.
I
should
have
been
engaging
with
pipeline
authoring
and
pipeline
execution
way
way
way.
Earlier,
like
sometime
last
fall,
we
should
have
been
collaborating
on
this
idea,
rather
than
addressing
that
supplemental
experience.
A
Now
it
is
a
cool
way
to
show
like
we
release
something
very
small
and
it's
already
having
an
impact
and
we
have
an
opportunity
to
continue
improving
on
it,
but
there
are
definitely
some
quick
wins
that
we're
going
after
now
that
we
could
have
addressed
in
the
past
so
that
and
then
additionally,
I
wasn't
spending
much
time
reviewing
documentation
changes.
I
was
leaning
pretty
heavily
and
just
assuming
tech
writing
handled
that,
but
not
thinking
about
helping
provide
use
cases.
A
So
I
think
often
times
we
just
ask
tech
writing
to
just
hey
just
help
us
write
documentation,
but
we
might
have
better
context
to
help
supplement
that,
and
so
I
definitely
want
to
spend
more
time
in
those,
mrs,
where
the
documentation
is
being
updated
to
see.
If
I
can
help
supplement
an
example
or
rephrase
something
to
make
it
more
obvious.
B
That
makes
sense.
Nick
you
had
a
question.
C
I
think
your
last
point
sort
of
segues
to
this
nicely,
but
how
do
you
think
from
the
past
experience
that
you
had
and
the
fact
that
documents
documentation
is,
is
such
a
huge
part
of
the
gitlab
ux
user
experience?
How
do
you
think
designers
and
tech
writers,
as
well
as
the
broader
team,
can
sort
of
collaborate
more
effectively
on
the
dock
experience
and
how
that
overlaps
with
the
ui
experience.
A
A
D
Sure
I
was
making
sure
I
was
not
muted,
so
the
way
that
we
work
at
get
lab
is
engineers
write
the
first
draft
of
the
doc
engineers
or
pms,
and
then
writers
take
it
and
turn
it
into
documentation.
D
A
Yeah
glad
to
hear
it
reinforces
some
of
our
important
principles
here,
but
yeah.
It
was
a
big
thing
for
me
as
well
just
trying
to
understand
how
I
set
it
up
myself
like
once
we
had
it
running
in
production.
I
was
like
all
right.
I
have
examples
from
comments
that
I'm
relying
off
of
from
past
history.
Those
things
definitely
don't
exist
in
documentation,
yet
it's
at
least
helping
surface.
Some
of
those
things
that
we
use
to
set
up
the
feature
itself
is
a
great
way
to
get
started.
E
I
am,
I
actually
edited
my
comment
in
the
agenda
because
I
had
a
butt
in
there
that
made
me
sound
like
I
was
disagreeing
with
susan.
I
was
actually
agreeing
with
susan,
which
is
oh,
my
goodness
yeah
I
mean
tech,
writers,
they're,
not
gonna.
They
haven't
been
involved
in
the
process.
The
way
that
designers
have
and
pms
have
so
they're,
not
gonna,
know
what
this
context
is,
but
as
they
are
doing
editorial
work,
they
can
absolutely
help
to
get
it
added
in
a
sensible
way.
It's
for
a
designer
to
say,
like
hey.
E
Let
me
tell
you
more
about
this
and
why
it's
important
and
how
it
gets
used-
and
this
isn't.
This
is
a
critical
part
of
the
process
that
austin
you're
right.
We
we
don't.
We
don't
generally
do
this,
the
more
that
we
can
do
this,
the
better
user
experience
we're
going
to
create.
So
this
is
like
this.
This
is
the
type
of
evolution
in
our
thinking
about
the
user
journey
that
I'm
really
really
excited
to
see.
A
Yeah
me
too
I'd
love
to
see
less
questions
that
could
be
definitely
answered
in
docs
in
slack.
That
would
be
great
a
great
outcome.