►
From YouTube: VizD and the Product Designer 2022 02 10
Description
We discuss possible ways to help the UX department address our UX Visual Design needs.
A
A
A
Okay,
maybe
we
go
through
the
these
two
lists
for
the
video
and
then
we'll
talk
about
a
question
that
andy
posed
so
some
possible
solutions
to
how
we
might
do
this
update
issue
templates
to
include
a
more
robust
definition
of
done.
I
had
mentioned
before
concept
that
andy-
and
I
were
talking
about
that.
I
was
calling
definition
of
ready
for
design
or
something
similar
to
that.
The
bottom
line
is
team.
A
Members
should
have
a
clear
idea
of
what
they're
designing
for
before
they
begin
designing,
so
maybe
there's
some
sort
of
something
that
lets
them
know
that,
while
you're
doing
your
workflows
and
general
layouts
and
making
sure
all
the
requirements
and
user
needs
are
met,
you
should
also
then
take
that
hat
off
and
put
on
the
visual
designer
hat
to
make
sure
you're
doing
a
scrub
for
for
layout
for
accessibility.
You
know
those
types
of
things.
A
B
A
Yeah,
that
could
be
a
cool
one,
and
in
fact
all
of
these
are
multiples
of
them.
Combination
could
probably
be
nice
nice
to
have
the
next
one
provide
communicates,
provides
such
communicate
suggested
process
for
team
members
as
they
move
through
their
phases
of
design,
so
interaction,
design,
phase,
visual
design,
phase,
accessibility,
phase,
so
that's
kind
of
what
I
was
getting
at
when
taking
put
taking
on
and
putting
on
removing
and
putting
on
a
hat
kind
of
thing.
A
So
accessibility,
each
phase
has
overlaps
with
one
another,
as
designers
should
and
likely
are
considering
all
of
them
as
they
go.
So
this
is
maybe
blue
lines.
You
know,
based
on
your
presentation,
we
gave
a
couple
weeks
ago
and
showcase
that
type
of
stuff
provide
tools
to
reference
when
wearing
the
visual
designer
and
accessibility.
Hats,
interaction,
design
tools
abound
in
our
handbook,
though,
shouldn't
assume
that
we
have
all
that
is
needed,
though
this
is
a
secondary
concern
due
to
what
we
have
now.
A
So
I
think
what
I'm
getting
at
here
is.
We
have
tons
of
stuff
on
heuristics
and
things
to
consider
when
doing
a
design,
but
we
don't
necessarily
have
anything
like
that
from
a
visual
design
perspective
and
I
think
actually
andy's
question
at
the
top
alludes
to
this
too
is:
is
there
some
sort
of
set
of
principles
or
heuristics
or
something
where
designers
can
reference
when
they're?
Putting
on
that
designer
hat,
to
make
sure
that
it's
covering
all
the
things
that
we'd
like
people
to
consider.
A
A
Okay,
so
this
is
where
we
just
were
right:
yeah,
it's
never!
This
one
provide
a
supplemental,
visual
design
and
slash
accessibility,
review,
that's
done
by
a
subset
of
team
members
once
the
interaction
design
has
been
done.
So
this
idea
is
similar
to
the
review
process
where
we
post
to
the
ux
channel
and
people
jump
in
and
provide
feedback,
but
maybe
there's
a
a
marker
that
we
can
put
on
something
that
says
this.
A
B
But
if
we're
not
targeting
that
part
of
the
spectrum,
then
I
think
we're
missing
out
on
some
opportunities
there
and
then
the
converse
to
that
is
that
not
everyone
has
a
desired
propensity
to
do
that
today
and
so
to
to
make
that
expectation.
After
the
fact
there
could
be
a
challenge,
so
I
feel
like
we
should
have
some
sort
of
a
process
in
place.
B
A
B
Yeah,
the
second
is,
is
to
consider
a
more
like
official
effort
to
use
formal
requirements
and
acceptance
criteria.
I
mean
I
feel
like
that
in
my
own
work-
and
here
this
is
one
of
the
most
critical
aspects
in
making
something
better
at
every
level.
But
the
moment
we're
we're
not
really
asking
all
the
questions
or
solving
all
the
right
problems.
B
It
it
can
be
kind
of
both.
I
think
acceptance
require
acceptance.
Criteria
would
be
kind
of
once.
That's
satisfied
is
like
a
definition
of
done,
so
it
would
be.
We'd
have
to
kind
of
tease
that
out
what
that
might
look
like
more
formally,
but
I
think
it's
a
little
larger
than
just
a
definition,
because
the
acceptance
criteria
would
be
something
that
we
could
validate
and
qa
qe
qa
testing
would
be
able
to
actually
go
back
and
validate
those
individual
criteria,
not
just
against
a
definition
but
for
actual
testable
items.
B
B
Requirements
gathering
so
where
you
have
multiple
disciplines
actually
weighing
in
and
and
because
of
that,
you're
increasing
that
designer's
awareness
and
knowledge
of
things
that
they
might
not
know
just
out
of
the
box.
So
if,
if
you
know
an
engineer
is
in
there
and
they're
like
okay,
you
want
to
use
this.
This
is
a
new
component,
that's
great,
but
we're
using
it's
going
to
live
in
hamel
and
ruby.
We
know
that.
Okay,
just
a
view
component
ui
is
not
going
to
do
that.
So
you
know
that.
B
Okay,
now
you
have
an
awareness
that
where
the
scope
is
increased
or
how
you
might
address
different
accessibility
parameters
or
different
conditional
items,
those
are
things
that
would
bring
awareness
to
a
designer
to
know.
Oh,
I've
got
a
design
for
these
situations
and
these
scenarios
that
are
going
to
come
up
empty
states,
air
states.
B
So
I
think
we
can
greatly
leverage
gitlab
to
do
that
it.
You
know
in
an
async
way,
so
yeah
yeah.
So
to
your
point,
yeah
the
the
milestone,
planning
and
whatnot,
I
you
know
that's
definitely
happening,
but
it's
that
actual
granular,
like
requirements,
gathering
and
understanding
those
types
of
aspects
that
really
it's.
In
my
experience
and.
A
B
Yup,
so
so
what
what
I've
done
before
is
where
you
would
actually
have
you
know
I
would
with
jira
and
whatnot,
where
you'd
have
a
story
that
would
address
each
one
of
those
and
it
could
be,
it
could
be
any
of
those
it
could
be.
What
are
the
user
requirements?
What
what
are
the
technical
requirements?
What
are
the
accessibility
requirements?
A
Yeah,
so
I
I
know
that
our
workflows,
our
documented
workflows,
do
stress,
collaborating
and
essentially
doing
this,
but
I
think,
maybe
what's
not
there
is
it's
not
looking
at
it
from
a
accessibility
perspective
right
we're
only
looking
at
constraints.
You
know
what
does
the
back
end
provide?
What
what's
difficulty
from
an
mdc
level.
B
You
know,
I
think,
there's
that,
but
we're
also
not
I
don't
see
it
like,
documented,
necessarily
and
checked
off,
like
we're
not
really
dog,
putting
our
own
requirements
feature
in
the
product
and
and
then
looping
back
to
ensure
that
those
are
solved
and
and
again
like.
It's
like
these
are
like
broad
brushstroke
statements
just
based
on
my
experience
and
what
I've
seen.
I'm
sure
that
there
are
our
teams
that
are
that
are
doing
that,
but.
B
Yeah-
and
I
think
it
gets
this
kind
of
a
stream
of
thought
here,
but
the
you
know,
the
approach
today
is
more
from
from
a
ux
standpoint,
it's
more
about
solving
ux
problems,
but
not
necessarily
in
parallel.
The
ui
accessibility
responsive.
Those
other
types
of
problems
are
aren't
always
solved
at
the
same
time.
Right
so.
B
And
just
as
part
of
the
work
process,
I
think
there
could
be
visual
and
accessibility
reviews
kind
of
a
like
if
you're
familiar
with,
if
this
and
that,
but
just
that
kind
of
approach
that
would
trigger
those
reviews
if
certain
conditions
are
met
where
up
front
during
milestone
planning.
You
know
you
know
that.
Okay,
we
got
a
checkpoint.
We
got
this
review
label
whatever
it
is.
A
So
that
almost
makes
me
think
that
there's
a
sub-
I
guess,
workflow
labeled
for
in
the
product
development
flow
that
we
that
you're
almost
suggesting
right,
because
there
is
there-
is
this
design
workflow
design
label,
which
is
that
process.
But
then
there
are
sub
steps.
I
think
that
you're
getting
it
is
that
accurate.
B
And
it
doesn't
turn
it
into
a
waterfall
right,
because
some
of
this
stuff
actually
happens
to
the
process
like
you
should
be
thinking
about
accessibility
at
the
start
and
the
middle
and
the
end
all
of
it.
You
should
be
designing
to
that,
but
the
discipline
is
just
having
that
those.
Those
kind
of
reviews
happen,
which
I
think
also
helps
offset
when
you
have
different
skill,
sets
working
doing
the
work.
It
helps
offset
that
as
well,
because
you're
allowing
those
other
people
that
do
have
those
skill
sets
to
weigh
in
and.
B
A
A
It's
implied
through
our
other
workflows
that,
while
you're
doing
this
that
you
should
be
collaborating
with
your
team,
you
know
to
ensure
that
you're
understanding,
user
requirements,
technical
requirements
and
at
that
point
you
should
also
be
you
know
you
should
also
be
considering
accessibility
like.
I
don't
think
that
I
think
what's
missing.
A
Is
these
explicit
statements
that
say
consider
ixt
consider
visual
design,
consider
accessibility,
just
because
I
I
know
if
it's
true,
but
I
have
a
feeling
that
it's
just
because
it's
relatively
new
a
lot
of
us
have
worked
in
companies
in
the
past
that
you
know
we
think
they're
important,
but
it
wasn't
the
driving
factor.
So
we
didn't
have
the
opportunity
to
do
a
lot
of
this
stuff
now
at
gitlab.
We
are
given
this
opportunity
and
we
do
care
about.
B
A
Yeah
yeah,
I
think
that's
ultimately
what
we're
getting
at
so
we
need
to.
We
need
to
figure
out
a
way
to
make
it
more
explicitly
part
of
our
workflows
whatever.
That
means
whatever
the
solution
is,
and
then
we
need
to
figure
out
a
way
to
give
designers
the
tools
to
do
that,
while
also
being
aware
of
what
you
said
earlier,
that
not
every
interaction
designer
wants
to
be
a
visual
designer
or
wear
that
hat.
A
So
there
has
to
be
a
way
for
us
to
like
that's
another
problem
that
we
need
to
solve.
There
has
to
be
a
way
for
us
to
work
around
that
scenario,
which
is
maybe
other
people
can
come
in
and
help
with,
providing
that
visual
design
assessment
and
I'm
using
visual
design
as
a
blanket
for
accessibility
and
all
of
the
other.
A
Details
there's
an
expert
bullet
and
a
few
of
the
designers
have
been
added
as
visual
design
experts,
so
maybe
there's
something
where,
if
you're
not
one
of
those
interaction
designers
that
has
the
wherewithal
to
do
visual
design
reviews,
you
might
call
in
one
of
those
people
to
or
to
run
an
assessment
or
again
maybe
we
drop
them
into
the
channel
and
they
put
a
emoji
or
something
that
says
this
is
a
visual
design
review
request,
as
opposed
to
specifically
interaction
or
generically
anything.
You
know.
A
So,
okay,
so
going
to
andy's
question,
which
we
briefly
sort
of
alluded
to,
is
there
any
way
to
put
together
or
define
ui
principles
for
designers
to
follow
simple,
do's
and
don'ts?
That
could
address
the
majority
of
the
problems?
I.E,
don't
use
boxes
to
define
context
or
content
hierarchy
when
it
is
okay
to
use
boxes,
containers
yeah,
so
so
that
was
kind
of
my
impetus
for
when
I
pinned
you
initially
on
slack,
was
there
any
classes
anything
on
linkedin
learning?
A
You
know
other
like
we
have
heuristics
in
ux
or
interaction
design,
which
are
very
solid
and
known
design,
principles
for
for
interaction,
design,
type
stuff?
Some
of
them
fall
into
visual
design
to
some
degree.
But
I'm
look
I'm
wondering
if
there's
something
even
more
specific
to
a
from
a
visual
design
perspective,
and
I
think
that
your
answer
was
not
really,
I
mean
just
gestalt
stuff,
like
we
briefly
talked
about
that.
B
I
mean
because
principles
in
general
will
get
you
so
far
and
that
you
know
that
and
of
itself
takes
time
to
practice
and
discern
and
know
when
to
what
to
pick
up
on.
But
then,
when
you
talk
about
a
specific
brand
aesthetic
on
top
of
that,
all
of
a
sudden
you're
trying
to
apply
those
principles
through
the
lens
of
the
brand
or
you
know
the
ui.
Whatever
the
goals
of
that
ui
are.
B
B
B
Our
what
we
need
to
start
shaping
with
that
you
know
kind
of
in
the
same
way,
you
you
have
your
copywriting
style
guides
and
your
your
voice
and
tone
like
what
is
our
visual
voice
and
tone
and,
and
at
least
at
least
I
start
there.
That's
still
jumping
in,
like
I
said
to
that
middle
layer,
where
you
see
it,
but
at
least
there's
something
replicatable
there
to
a
degree,
and
you
start
to
understand
what
that
visual
language
is
but
explore
that
further
and
then
back
fill
with
with
some
of
the
principles.