►
From YouTube: UX Showcase - Consistent content
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
A
A
So
if
consistency
is
the
aim,
how
do
we
achieve
it?
As
I
mentioned
earlier,
we
set
standards
and
conventions
of
the
gitlab
UI.
We
use
the
gitlab
design
system,
also
known
as
pajamas
for
the
documentation.
We
use
the
documentation
style
guide,
but
it's
not
enough
to
set
standards
and
conventions
that
are
only
effective
if
we
comply
with
them
at
GitHub.
We
do
that
when
a
merge
request
is
being
reviewed.
A
At
GitHub,
we
review
content
during
two
phases
during
the
design
phase,
the
product
of
designer
and
technical
writer
collaborate
on
the
UI
text.
Other
people
are
involved,
but
it's
primarily
their
role
during
the
development
and
test
phase.
The
engineers
and
Technical
writers,
collaborate
on
the
documentation.
A
A
Here
I've
got
an
example
of
where
the
combination
of
UI
content
and
stocks
content
is
not
what
was
expected
at
the
top.
Here,
we've
got
a
modal
named
validate
site.
The
user
needs
to
complete
three
steps
here,
one
of
which
requires
them
to
do
a
task
against
like
to
get
that
UI
each
step
has
a
numeric
prefix
step,
one
step
two
step
three:
to
make
it
clear:
they
must
be
completed
in
order.
A
The
problem
comes
when
the
task
is
documented
below
the
model,
so
the
next
character
with
a
matching
docks,
and
it
wasn't
until
I
wrote
this
dog's
content
that
I
realized
the
steps.
Numbering
is
a
problem
in
the
task.
We
referenced
steps
two
and
three
of
the
modal
by
their
prefix,
but
that's
potentially
confusing,
because
the
task
steps
and
numbered
it
may
not
be
clear
that
when
we
mention
step
two
we're
not
referring
to
step
two
of
the
task,
but
step
two
as
labeled
in
the
UI.
A
A
B
You
for
listening
what
inspired
you
to
do
your
presentation
on
this
topic.
A
I'd
had
a
few
instances
recently,
particularly
with
API
content,
API
responses,
where
the
terminology
that
we
used
within
the
docs
didn't
match
what
we
had
in
the
API
responses,
so
I
thought,
for
example,
if
we've
got
someone
completing
a
task
in
the
user
interface
and
someone
completing
the
same
task
using
the
API,
they
they
different
terminology
used
within
those
those
two
different
tasks:
I
thought
that
that's
not
what
we
ought
to
have.
We
ought
to
be
using
the
same
terminology
or
both,
otherwise
they
can't
you
know.
A
Someone,
for
example,
may
become
familiar
with
the
task
using
the
by
using
the
UI
and
then
say:
okay
great
I,
also
now
want
to.
You
know,
send
me
automate
that
task
using
the
API
if
they
already
familiar
with
the
the
user
interface
and
then
they
switch
to
using
the
API.
If
the
API
uses
a
different
terminology,
then
they're
going
to
get
quite
a
sort
of
jarring
effect
and
trying
to
go
from
one
to
the
other.
A
The
other
one
was
the
the
example
that
I
gave
within
the
presentation,
which
was
one
that
yeah
yep
that
one
thank
you
where
effectively
I
collaborated
with
the
product
designer
on
the
the
content
in
the
modal
and
it
all
looked
perfect,
all
the
all
made
sense,
but
when
it
came
to
producing
the
documentation,
that's
when
things
yeah,
it
was
some
problems.
I
wrote
and
again
I
covered
that
in
the
presentation.
A
So
that
was
another
instance
where
I
thought
you
know,
we've
got
content
in
UI,
API
responses
and
the
the
docs
themselves,
and
all
three
really
need
to
be
consistent,
and
yet
our
review
processes
don't
necessarily
capture
all
three
of
those.
A
B
So
great
so
the
example
here
on
the
UI,
we
have
step
one
two
three
and
then
once
we
write
the
documentation,
we
mention
it
as
step
two
and
three,
but
the
confusion
that
Russell's
kind
of
trying
to
highlight
is
there's
this
step.
Two
mean
this
step
two,
or
does
that
mean
step
two
of
the
docs?
B
So
this
is
something
that
we
need
to
be
mindful
as
product
designers
that
when
we're
designing
something
that
is
very
sequential
like
this,
it
might
be
a
good
time
to
think
about
how
the
documentation
could
be
written
out
and
then
maybe
working
with
your
technical
writer
to
kind
of
brainstorm,
some
different
ideas
to
potentially
either
change
the
UI
change
the
layout
or
work
with
the
technical
writer
to
see
how
we
might
be
able
to
document
this
in
a
clear
and
consistent
way.
So
thank
you
for
highlighting
this
problem.
Russell
and.