►
From YouTube: UX Showcase - Connecting the dots
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
So
what
do
these
things
have?
In
common
code
owners,
Alyssa
names,
an
icon
for
lock
an
edit
button
and
a
set
of
pajamas?
These
to
me
almost
have
no
relation
to
one
another
they're
all
issues
that
have
come
up
in
my
world
in
source
code
and
source
code.
It
covers
a
lot
of
breath,
so
we
handle
different
areas
from
permissions
to
how
you
might
edit
a
file
to
how
you
may
protect
the
file,
and
a
lot
of
our
pages
are
actually
quite
old
and
don't
always
align
to
the
latest
guidelines
from
pajamas.
A
So
when
we're
trying
to
make
some
changes
around
this,
it
can
be
kind
of
difficult
to
find
what
that
next
step,
we
should
take
towards
making
the
changes
with
code
owners
there's
an
issue
where
the
layout
kind
of
messes
things
up
the
icons
we
want
to
indicate
to
users
like
which
files
are
locked-
and
this
is
some.
A
A
So
if
you're
we
have
code
owners
and
when
it
loads
on
the
page,
we
actually
make
a
call
to
the
back
end
to
load
the
information,
that's
good,
because
our
Pages
load
up
quickly.
The
downside
is
that
it
can
result
in
this
scenario
where,
if
you're,
trying
to
click
a
directory
or
is
going
to
somewhere,
but
it's
still
loading
here
and
what
ends
up
happening
is
people
start
clicking
on
these
double
dots?
A
The
next
thing
was
the
lock
icon.
We
have
this
ability
that
we
can
lock
a
file
within
gitlab
to
only
the
person
who
unlocked
it
can
make
changes
directly
to
it.
But
the
problem
is:
we
have
the
icon
here
in
the
directory
view
or
the
tree
view,
but
once
we
get
into
the
file
view
or
the
blob
View,
we
don't
display
that
icon
anywhere
and
the
quick
bias
for
Action
is
to
like
yeah
just
put
it
here
or
put
it
here.
A
A
A
If
we
just
keep
on
just
adding
one
little
thing,
one
little
thing:
it
just
builds
up
and
builds
up
and
before
we
know
it,
we
have
a
lot
of
functionality,
but
no
Clarity
on
what
we
want
a
person
to
do
on
the
page,
and
even
looking
at
this
page
here,
we
can
see
that
we
have
a
primary
action
that
we
want
people
to
take
in
the
middle
of
all
buttons.
This
is
just
an
example
where
these
are
older
pages
that
haven't
been
adhered
to.
A
Pajamas
and
there's
opportunities
around
this
and
other
designers,
like
Julia
in
the
editor
group,
has
highlighted
this
as
a
problem
and
has
presented
different
ideas
of
how
we
could
simplify
this.
But
when
you
look
at
everything
holistically
is
like:
where
do
you
make
the
moves?
What's
the
most
important
move
to
make?
First,
so
that
everything
can
happen,
but
everything
looks
like
scattered
dots.
You
know,
there's
all
these
problems
with
this
page,
but
they're
all
very
connected
right,
they're,
all
they're
all
relate
to
the
page.
They
all
need
a
place
on
the
page.
A
But
how
do
you
do
that?
And
this
is
where
I
felt
like
we
haven't
taken
action
on
this,
because
we
didn't
know
where
we're
going
with
it.
So,
let's
say
I
threw
on
an
extra
button
or
threw
on
an
extra
icon.
We
resolved
that
one
issue,
but
we
created
another
issue
elsewhere.
So
adding
an
icon
to
that
existing
layout
is
great.
Now
we
know
which
files
are
locked,
but
now
we
may
have
made
the
screen
a
lot
more
complex.
A
We
might
cause
layout
issues
because
there's
no
space
for
any
icons
or
we
might
add
extra
confusion,
because
we
have
a
lot
of
buttons
and
icons
already
on
the
page
and
throwing
another
one
on
there
could
cause
more
confusion,
so
without
purpose
of
where
we're
going
to
it's
hard
to
iterate
and
hard
for
us
to
iterate
with
the
purpose
to
say
clearly
what
we
want
our
customers
to
do.
B
A
Once
I
joined
the
source
code
group,
but
it's
only
recently
that
I
actually
put
everything
into
an
epic,
and
this
is
what
this
whole
talk
is
about
is
actually
we
have
ux
roadmaps,
which
is
a
bigger
thinking
about
where
things
should
be.
A
So
the
takeaway
here
is
actually
trying
to
use
epics
as
thematic
things
that
you
can
group
things,
and
you
can
always
change
and
break
things
up
in
the
future.
But
it's
a
really
good
way
to
get
it
out
of
your
head
and
somewhere
more
transparent,
so
that
other
people
can
see
how
you're
thinking
about
grouping
these
things
together
and
or
how
these
things
may
relate
and
there
might
be
patterns
there
that
can
help
you
find
a
solution
and
sometimes
solving
one
problem
can
result
into
another.
A
So
example,
here
is
I
was
saying
like
if
I
added
a
lock
icon
onto
the
page,
it
could
cause
confusion
of
why
a
lock,
icon
there
or
layout
issues-
and
this
might
be
a
good
time
to
ask
yourself
why
and
it
comes
down
to
like
oh
there's,
not
enough
space,
and
why
is
there
not
enough
space
Oh?
We
have
too
many
buttons.
Why
do
we
have
too
many
buttons,
because
we
have
buttons
for
every
key
act?
A
Okay,
maybe
there's
other
patterns
that
we
have
right
now
at
our
disposal
through
pajamas
to
potentially
group
or
hide
buttons
that
are
less
actively
used
or
not
part
of
the
main
flow
that
we
want
people
to
take
so
I'm
just
going
to
walk
through
an
example
now
of
how
I
am
using
these
principles
to
transform
this
directory
page
that
we
have
right
now
in
gitlab
and
how
it
could
look
in
the
future.
So
none
of
these
designs
are
final
they're
up
for
review
and
inspection.
A
But
if
we
take
a
look
at
this
page,
like
I
said,
one
of
the
key
issues
was
the
number
of
buttons
on
the
page.
So
let's
say
we
solve
that
by
putting
some
buttons
at
the
top
that
are
not
core
to
the
experience
into
an
overflow
menu
and
we
had
the
add
button
over
on
this
side
attached
to
views.
But
potentially
it
could
be
grouped
over
here,
and
so
now
we
have
a
whole
area,
that's
consistent
to
just
actions
on
the
page.
A
A
If
we
take
the
directory
and
make
it
the
title,
we
we
have
a
page
layout,
that's
consistent
with
some
other
pages
in
gitlab
as
well,
but
also
given
us
an
opportunity
to
break
this
up
and
actually
give
us
more
space.
So
that's
pretty
good
and
with
code
owners,
potentially
one
thing
that
we've
seen
in
other
platforms.
The
problem
that
the
layout
happens
is
that
when
this
thing
comes
out,
it
pushes
the
content
down.
So
what
not
one
potential
idea
I'm
not
sold
on
this
yet
is
to
just
display
this.
A
It
can
load
asynchronously,
but
whether
it
shows
up
here
won't
affect
the
layout
of
the
page,
because
it
would
only
appear
in
this
line.
So
we
eliminate
that
issue
of
if
I'm,
trying
to
click
on
this
and
it
pushes
the
content
down
and
I
end
up
clicking
this
back
up
to
directory
that
that's
potentially
a
move.
A
So
if
we
look
at
them
side
by
side
by
applying
some
of
the
rules
that
we
have
in
pajamas
around
when
to
use
the
overflow
menu
page,
title
headers
and
thinking
about
other
ways
to
present
information
on
the
page,
we
could
get
to
a
page.
That's
a
lot
less
cluttered
and
a
little
bit
more
focused
around
what
we
want
people
to
do,
taking
the
same
kind
of
logic
and
thinking
around
this
to
our
file
Pages.
It
could
look
something
like
this
so.
C
A
A
A
Based
on
this,
we
can
start
making
iterative
plans
to
say:
okay,
you
know
if
this
is
happening
Maybe,
we
can
pause
on
certain
issues
that
we
can
move
ahead
with
certain
issues,
or
we
can
make
smaller
changes
that
are
head
heading
directionally
to
where
we
want
to
be,
rather
than
just
making
the
quick
action
and
not
having
a
real
sense
of
where
we
want
to
get
to
so
the
main
takeaway
that
I
want
everyone
to
get
from
this
today
is
thinking
about
using
epics,
to
create
smaller
thematic
groups
of
issues
so
that
you
can
see
everything
holistically
and
potentially
find
one
solution
that
could
solve
multiple
issues.
C
I
just
had
a
comment,
not
a
question.
First
of
all,
I
love.
This
I
love
seeing
this
kind
of
work,
this
proactivity
and
like
yeah.
It
takes
a
little
bit
more
time
initially,
but
I
think
the
usability
like
improvements
are
awesome
and
I
also
think
you
could
definitely
release
these
changes
quite
iteratively.
So
this
is
super
awesome
to
see
it's
just
interesting
that
you
mentioned
that
you
kind
of
organized
it
by
epic.
C
Personally.
For
me
how
how
I
work
is
I
might
put
everything
in
a
giant
figma
file
with
heaps
of
annotations
and
kind
of
show
that
to
the
team
and
have
like
lots
and
lots
of
debate
and
I,
probably
wouldn't
actually
create
issues
until
we
have
like
engineering
consensus.
So
that's
just
for
me
personally,
I
find
that
a
little
bit
like
sometimes
when
you're
working
on
a
large
initiative
like
being
able
to
see
the
vision
in
epics
with
with
sub
issues
and
yeah
I,
was
just
curious.
You
know
to
hear
more
about
your
approach.
C
A
So
as
a
designer
I
also
started
in
figma,
and
this
started
off
as
how
could
I
move
around
this
code
owner
block
so
I
started
moving
that
around
and
then
I
decided
hey
what
happens
if
I
could
move
everything
around
and
so
from
there
I
realized
that
a
lot
of
these
things
that
I'm
doing
we're
not
part
of
my
we're,
like
part
of
my
subconscious,
because
I
was
thinking
about
all
these
other
issues
at
the
same
time.
A
So
that's
when
I'm
like
okay,
let's
just
group
all
these
things
that
I'm
trying
to
tackle
together
in
one
Epic,
so
that
it's
visible
to
other
people
who
May
understand
this
but
yeah.
It
started
off
from
one
issue
that
was
trying
to
solve
that
I
was
moving
other
things
around
and
because
I
was
aware
of
these
other
issues,
I
could
see
how
they
were
all
connected.
A
I
think
you
can
do
both
I
think
you
can
work
both
in
figma
and
explain
it
to
your
engineers,
but
you
can
also
collate
those
existing
things
into
one
place
so
that
it's
another
way
for
team
members
to
consume.
That
thinking
so
I
think
both
are
valuable.
C
Makes
sense,
do
you
happen
to
have
any
tracking
all
actions
to
kind
of
help
validate
what
goes
in
the
Overflow
menu.
A
Yep,
so
if
you
click
on
the
Epic
there
at
the
bottom
and
there's
a
comment
that
has
the
different
stats
on
how
many
times
those
buttons
were
clicked
into
this
three
months,
so
it
gives
a
rough
understanding
of
the
priority
of
actions.
What
we
don't
really
understand
is
if
there's
a
connective
flow.
A
Like
you
know,
if
people
go
through
this
flow,
they
actually
use
these
two
in
tandem
or
do
they
use
other
things
intended,
but
I
we
have
an
understanding
of
how
which
buttons
are
used
and
we
have
our
own
gut
is
intuition,
and
we
have
like
references
to
other
platforms
that
implore
similar
kind
of
features
and
so
I
think
in
the
combination
of
those
three,
we
can
make
a
good
judgment
call
on
which
buttons
to
hide
and
not
hide,
and
as
long
as
we
make
it
consistent
like
you
know,
if
we
show
the
permalink
always
in
overflow,
let's
do
it
consistently
for
the
directory
and
the
file,
but
you
know
not
like
one
place,
we
do
it
one
way
in
one
place.
C
D
I
just
had
a
comment
as
well
that
I
really
love
the
design,
the
new
design.
All
of
the
changes
that
excuse
me
I,
think,
are
really
good
changes
and
any
any
work
that
we
could
do
to
stop.
That
gitlab
interface,
like
jumping
around
as
things
load,
is
excellent,
because
I
hit
that
literally
every
day
as
a
gitlab
user
I'll
be
clicking
through
with
muscle
memory,
and
then
things
will
be
jumping
around
and
I'll
miss
click.
So
anything
we
can
do
to
resolve
that
is
excellent.
D
Actually,
you
know
actually
happened
that
you've
previewed
doing
it
originally
is
great,
because
that
means
that
we
can
keep
up
with
the
docs
changes
that
would
be
required
as
well,
because
yeah,
if
you
could
drop
all
that
at
once
and
it'd
be
great,
but
it
would
impact
quite
a
lot
of
different
functionality
so
doing
it
iteratively,
even
though
it's
a
bit
slower
and
it's
not
the
final
result
as
quickly
is.
D
B
I
just
realized
I
haven't
been
mentioned
all
this
time,
so
apologies
for
any
noise
that
came
through
I
just
wanted
to
say:
yeah
I,
really
like
the
idea
of
using
an
epic
to
describe
the
big
feature
to
present
the
big
picture,
particularly
if
you're
talking
about
the
UI
design
you
know
of
even
if
it's
of
a
specific
page,
I
understand
that,
as
with
Katie
said,
you
know,
you
might
prefer
to
to
you
know
present
them
within
treatment,
but
certainly
the
Epic
allows
I
think
everyone
to
understand
the
sort
of
end
goal
which
you
then
having
to
find
that
you
then
may
break
that
down
into
a
specific
issues.
B
Because,
to
my
mind
you
know
the
the
issue
with,
and
the
issue
is
how
you
present.
What
do
you
want
to
do
and
then
a
merge
request
is
the
actual
implementation
of
that
specific.
B
You
know
change
that
you're
wanting
to
make,
but
an
epic
allows
you
to
to
draw
those
all
together
and
present
the
big
picture,
and
you
know,
as
Evan
said,
for
example,
it's.
The
incremental
approach
is
great
for
for
incremental
changes,
because,
particularly
when
it
comes
to
docs,
we
can
then
say:
okay,
we
want
to
shoot.
You
know
this
small
portion
of
you
know
over
here
or
make
this
in
an
incremental
change,
so
it
allows
that
allows
us
to
keep
the
docs
up
to
date.
B
You
know,
as
we
make
those
incremental
changes,
but
also,
if
we're
able
to
see
the
big
picture
through
something
like
an
epic
simply
can
say:
okay.
Well,
it
might
make
sense
to
maybe
not
shift.
You
know,
maybe
maybe
group
these
docs
changes
for
example,
so
you
know
don't
shift.
You
know
all
you
know
these
these
pieces
over
here
because
in
the
very
next
merge
request,
we're
actually
going
to
be
shifting
them
back
again.
B
So
you
know
the
Epic
allows
us
to
see
the
big
picture
and
then
say
Okay,
you
know,
what's
the
you
know,
aside
from
the
page,
you
know
MVC,
you
know,
maybe
maybe
clicking
that
aside
for
a
second
What's,
what's
going
to
be
the
most
efficient
method
of
of
doing
that
and
again
because
everybody
involved,
you
know
Engineers
designers,
technical
writers,
you
know
product
managers
because
everybody
can
see
the
big
picture.
I
think
it
allows
them
to
operate
more
efficiently
in
with
these
design
changes.
A
Thanks
Russell
yeah,
just
for
the
record,
like
the
this
whole
thing
actually
started
in
a
whole.
Fig
file
like
I,
went
mad
on
a
figma
file
than
to
explain
my
madness.
I
use
the
Epic
and
so
I
think
in
the
future.
A
My
takeaway
is
that
I
wanna
see
if
I
can
start
off
at
the
Epic
Level
and
then
start
grouping
this
as
it
goes,
comes
along
rather
than
waiting
to,
like
my
madness,
reaching
to
a
point
where
I'm
like
okay
I
need
to
solve
this
and
I
need
to
explain
to
people
trying
to
see
if
I
can
reverse
engineer
my
own
Madness
to
like
be
more
proactive,
so
yeah.
This
was
I.
Think
using
all
the
tools
we
have
is
really
helpful.
So
thank
you.
Everyone
for
your
feedback.
B
Can
I
just
say
also
I,
think
figma
works
really
well,
of
course,
for
those
people
who
are
already
familiar
with
figma
as
a
product
and
those
who
who
are
particularly
you
know,
visually
sort
of
adept.
You
know
people
who,
who
you
know,
can
sort
of
see
these
things.
Okay,
I
can
see
this
I
can
see
that
and
then
they
can
see
how
the
puzzle
pieces
might
fit
together.
B
Some
people
don't
work
very
well
visually
Some
people
prefer
to
to
have
you
know
this
describing
words
and
of
course
you
can't
describe
UI
design
changes
in
words,
but
if
you
can
at
least
present
the
idea
or
the
intent
of
the
design
in
words
that
I
think
works
well
for
people
as
well,
you
know
again,
they
may
not
be
able
to
visualize.
Quite
you
know
to
say
in
the
same
detail.
B
E
D
E
Thinking
basically
the
same
thing
as
Russell
there
that
that
kitty
said
that
she
she
likes
to
work
from
figma
for
the
most
part,
Michael
is
doing
epics
and
issues
and
and
for
me,
I
I
was
thinking
the
same.
That
for
designers
probably
were
working
from
figma
works
very
well.
But
for
me,
as
a
technical
writer,
I
I
do
like
to
to
be
pinged
in
an
issue.
Have
a
lot
of
the
texts.