►
From YouTube: Using Visual Difference Figma plugin.
A
Hello,
everybody
dan
Mitzi
Harris
here
with
Jeremy
L
there
looking
at
one
of
my
favorite
figma
plugins
called
visual
difference,
so
visual
difference
allows
you
to
see
when
pixel
pixels
have
changed
on
a
on
a
figma
file,
similar
similar
to
how
we
have
story
shot.
I
think
it
is
in
gitlab
UI
that
when,
when
we
make
a
change
things
that
aren't
easier
to
see
with
the
eye,
computers
are
really
really
good
at
seeing
because
they're
seeing
pixels
so
just
give
a
quick
demo
of
how
it
works
so
start
up.
A
A
So
let's
change
the
fill
color,
for
example,
to
red
rerun
the
rerun,
the
plugin
no
changes
here,
but
it's
picked
up
that
I've
got
a
red
circle.
Difference
detected
nice
Pink
by
here
nice
Red
by
there,
but
that's
quite
an
easy
change
to
see.
So
what
about?
Oh,
let's
not
undo
like
that!
What
if
the
change
was
a
little
bit
harder
and
more
suitable
for
a
machine
I
think
it
was
e5s,
no
d9s
and
let's
shift
it,
the
pixels
or
four
pixels
to
the
right
by
eye
I.
A
Think
even
my
eagle
eyes
wouldn't
be
able
to
swap
this
one.
But
let's
see
if
the
machines
no
yeah,
we
can
see,
it's
detected,
there's
a
difference
between
the
original
and
this.
But
that's
not
super
useful
so
to
work
out
exactly
what's
changed,
you
click
in
like
this,
and
you
can
change
the
overlay
and
can
you
see
the
pink
border
there?
Sometimes
even
this
is
quite
hard
to
see
so
I
switched
to
party
mode
and
I'm
in
this
really
small
changes.
A
So
let's
approve
those
changes,
I
like
them,
but
this
is
super
useful
for
when
you
change
components
which
you
can
see
what's
going
on
and
the
changes
happen
in
a
different
frame.
So
let's
say
I
change
the
letter
space
in
one
percent
and
know
it's
changed
here
because
I've
been
in
it
but
I
might
not
have
seen
the
effect.
Let's
change
the
line
height
as
well
to
have
it
a
real
world
impact,
so
it
changed
my
line
height
to
18,
but
I'm
busy
up
in
here
and
I
didn't
notice.
A
B
I
think
that's
well.
Well,
maybe
one
one
quick
thought
is
that
if
you
are
like
in
some
instances
that
you've
done
before,
where
you'll
run
the
test
for
me
and
then
say:
oh
here's
the
results,
you
would
not
approve
the
change.
You
would
want
that
left
so
that
I
could
actually
see
that
regression.
So
there
is
a
difference
of
when
you
would
approve
it,
maybe
in
your
own
workflow,
but
if
you're
kicking
it
over
for
review
on
a
final
change,
you
would
not
necessarily
want
to
approve
that
change
before
having
somebody
else
detect
that.
A
Width
or
the
letter
spacing
and
then
wanted
to
check
the
impact
of
the
line
height
if
I
approved
in
between
it
would
allow
me
to
see
what
each
of
those
separate
changes,
what
effect
that
was
having
in
a
two-step
but
I,
think
I
think
that's
a
much
rarer
use
case.
But
yeah,
like
you,
said,
I
found
it
useful
for
myself
when
I'm
doing
work
to
make
sure
I'm
not
affecting
things
negatively
elsewhere
and
when
it
is
happening
and
we're.
Okay
with
it
makes
it
hopefully
easier
for
other
reviewers
to
see
where
the
changes
are.
B
Okay
and
then
my
other
comment,
because
we
had
discussed
this
prior
to
recording-
is
that,
unlike
a
a
get
workflow
where
you
would
compare
changes
to
the
main
branch,
these
are
comparing
changes
within
a
branch,
so
something
you
did
at
the
start
was
you
ran
the
plug-in
at
the
start,
which
is
critical,
because
you're
you're
checking
the
changes
in
the
branch
to
what
it
you
know
to
its
starting
point.
So
it's
kind
of
like
you're.
B
You
know
your
diff
within
that,
but
it's
not
going
to
compare
what
is
in
the
main,
so
the
I
just
wanted
up
to
state
that,
because
I
that
wasn't
clear
to
me
initially
I
was
thinking.
Well,
is
this
gonna?
You
know
detect
changes
against
the
main
or
against
what
I've
changed
in
the
branch
and
it's
specific
to
that
Branch
or
that
file,
so
yeah
I've.
A
I've
Got
a
Theory
though,
and
we're
going
to
find
out
in
real
time
if
it
works
and
I
I
promise
you
I
haven't
tested
this
before,
but
I've
got
a
feeling.
It
just
looks
at
the
frame
names
and
the
plugins
just
looking
for
an
old
snapshots,
Auto
layout,
so
I've
made
some
changes
to
this
label
in
a
branch
and
I've
decided
I,
don't
know
and
do
my
work
I
want
to
see
what
visual
impacters
have.
So.
My
theory
is
if
I
go
to
make
a
brand
new
branch.
A
A
A
A
B
That's
great
and
and
to
be
clear
too,
this
is
purely
visual
regression
right.
This
is
not
going
to
tell
me
that
layer
order
has
changed
that
I've
changed
my
my
auto
layout
settings.
All
of
those
things
would
still
be
done
in
a
branch
review
with
the
figma
UI.
This
is
purely
for
visual
regression,
testing.
B
B
A
B
Yep
I
think
that's
fantastic
and
I.
Think
I've
got
that
right.
Nathan
Curtis
on
that,
yes,
and
so
with
this
I,
think
that
you
know
something
that
highlighted
just
as
you
becoming
a
figma
maintainer
was
your
testing
skills
and
capabilities.
So
I.
Thank
you
for
demonstrating
this
I
think
I'm
going
to
use
it
when
I
update
the
type
styles,
but
also
being
able
to
distribute
or
set
up
plugins
that
are
globally
available
to
the
organization.
B
B
The
reason
I
asked
that
too
is
because
we
might
also
want
to
it
might
not
just
be
these.
These
tests
that
we
run
we
might
want
to
manually
highlight
some
other
changes.
We've
done
and
place
them
in
this
testing
section,
or
you
know,
if
you're
doing
some
stress
testing
on
a
component
there's
actually
a
new
plug-in
out
that
that
actually
builds
out,
like
all
of
your
combinations,
for
you
and
stress
test
is
different
things
we
might
want
to.
You
know,
run
some
results
of
that
and
place
them
in
a
section.
B
A
B
A
A
A
A
B
A
A
B
Okay,
so
not
ready
for
adding
to
a
section
like
a
testing
section.
Yet
so
it's
just
critical
in
the
meantime
or
maybe
helpful
that
we
identify
those
sections
with
something
outside
of
it
initially,
if,
if
we
need
to
or
to
group
those
so
that
we
can
kind
of
group,
all
our
testing
but
yeah,
we'll
watch
for
that
and
see.
If
there's
an
update
on
that.