►
Description
Topics:
- [Cross-stage collaboration](https://youtu.be/AMZKHwL5vSY?t=26)
- [Lo-fi wireframing](https://youtu.be/AMZKHwL5vSY?t=1192)
A
A
Yep,
so
I
was
curious
to
get
other
designers
feedback
or
rather
thoughts
around
when
you're
trying
to
bring
forth
a
visionary
idea.
It
often
looks
like
small
incremental
changes,
but
when
you're
trying
to
communicate
that
through
epics
and
issues,
it's
sometimes
hard
to
keep
them
connected
for
other
groups.
A
So
a
way
this
is
appeared
for
me
with
working
with
source
code
and
code
review,
is
compliance
is
trying
to
introduce
a
feature
where
we're
just
trying
to
expose
the
status
of
these
apis
within
a
merge
request,
and
I
get
some
feedback
around.
This
seems
incomplete.
This
seems
like
not
a
great
user
experience,
and
I
will
admit
that
I
even
don't
love
the
user
experience,
but
to
get
a
first
release
out,
we
can't
do
everything
under
the
sun
so
like.
A
I
would
love
to
build
towards
something
that
is
more
insightful
that
provides
more
feedback
to
the
user
of
like
what
to
do,
but
what
we
had
validated
with
customers
and
users
already
was
just
at
least
knowing
the
pass
fail.
Situation
of
a
specific
api
is
more
useful
than
nothing
because
today
those
customers
are
having
to
our
users,
are
having
to
leave
the
gitlab
platform,
go
check,
those
things
and
then
come
back
in
we're,
trying
to
keep
them
within
gitlab
and
not
having
to
jump
back
and
forth
between
everything
just
to
go
discover
something.
A
So
I
guess
my
question
is:
how
have
you
kind
of
helped
communicate
that
this
vision
I
have
right
here
on
the
right,
might
not
actually
be
where
we
ended
up
going.
It's
like
what
I
have
painted
in
my
head,
but
the
first
thing
that
we're
like
shipping
is
much
smaller
and
it
just
tells
you
like
the
name
of
something
created
and
its
corresponding
api
would
show
up
in
a
pop
over
here,
but
you're
not
going
to
get
much
more
feedback
in
terms
of
that.
Just
because
we
don't
know
a
lot
of
information
about
it.
D
So
as
long
as
you
show
them
in
in
context
and
explain
your
reasoning
as
to
why
you
are
iterating
with
this
particular
approaches,
it
seems
seems
absolutely
fine
to
be
shipping
stuff.
Like
this.
I
think
the
the
product
principle
of
having
a
low
level
of
shame
comes
to
mind
here
as
long
as
it's
service.
As
long
as
it's
servicing
some
part
of
the
job
that
that
you're
trying
to
serve
it's,
it's
a
good
stepping
stone
and
then
you
can
just
incrementally
add
stuff
onto
there.
D
C
A
A
D
A
They're
all
passing
okay,
good
we're
this
merge
request
is
healthy.
Then
we
can
approve
it
knowing
that
the
apis
are
ready
to
go,
it's
not
removing
the
entire
need
to
go
and
check
these
things,
but
at
least
tells
you
okay.
I
definitely
need
to
go
look
at
the
villains
api
and
go
figure
out.
What's
going
on
there.
A
E
A
Cool
yeah,
I
think
I
was
on
the
same
track
as
like
what
nick
was
saying
and
u2
alexis
of
just
keeping.
It
short
toes,
and
the
thing
that
I
struggle
with,
though,
is
I
don't
want
to
always
mock
up
a
vision
to
help
illustrate
where
things
might
go
one
day,
because
I
don't
want
people
to
attach
themselves
too
much
to
like
aui
per
se.
A
D
D
So
there
I
think,
there's
an
inherent
understanding
that
visions
will
change
over
time.
So
you
could
communicate
that.
But
I
also
think
people
understand
that
as
well
for
the
most
part
and
then
also
the
concept
of
taking
two
steps
forward
and
then
one
step
back
as
a
way
to
design
within
gitlab
as
well.
D
So
thinking
about
where,
where
are
we
going
with
this
and
then
cutting
it
back
to
make
it
an
mvc
as
much
as
possible
and
that
showing
showing
the
the
two
versions
of
of
the
very
smallest
nbc
and
like
the
next
steps
to
after
that
in
tandem
is,
is
really
useful.
There's
a
number
of
like
really
well,
it's
very
useful
for
developers
to
understand
how
they
should
configure
their
code
in
in
a
particular
way,
which
starts
to
set
them
up
in
in
a
particular
direction.
D
C
D
Though
your
certainty
on
what
it
will
be,
as
you
go
out
longer
term,
is,
is
narrower
and
narrower.
I
think
showing
those
two
designs
is
really
useful
if
you
have
the
time
to
do
it,
but
obviously
it
takes
time
so
balance
the
amount
of
time
that
you
have
with
what
you're
trying
to
convey
and
the
more.
A
D
Also,
there's
also
a
discipline
within
futurism
called
scenario
planning,
and
you
can.
You
can
read
up
a
lot
about
scenario
planning
within
you
can
just
type
it
in
google
and
find
a
lot
of
stuff
there.
But
scenario
planning
also
talks
about
particular
scenarios
based
on
on
what
sort
of
emerges
as
you
as
you
go
along
the
time.
That's.
A
C
C
C
C
If
somebody
has
to
go
through
an
extra
step
to
like
enable
it,
then
we've
put
a
barrier
to
our
learning.
Let's
see
there
was
another
yeah
you're
answering
it:
did
you
invite
contribution
to
your
vision
and
figma,
so
somebody's
pushing
back
kind
of
hard
just
say
you
know
not
just
but
invite
them
to
help,
make
it
look
more
less
minimal
or
what
was
the
phrase
that
they
used
incomplete,
say
well,
let
let's
ping
pong
some
ideas
here.
A
Incomplete
would
be
my
summarization
of
the
back.
I
think
what
I
am
learning
I
didn't
do
enough
early
on
was
get
more
agreement
across
the
board
early
on,
and
so
it's
just
been
a
little
bit
more
painful.
Getting
into
the
build
track
of
now.
Questions
are
arising.
It's
like
you,
know
we're
kind
of
late
in
the
game
to
be
going
back
and
making
all
these
revisions
it's
causing
tension
around
how
we
actually
plan
the
next
couple
milestones,
but
I
did
want
to
address
your
first
question
about.
Is
there
a
pattern?
A
I
won't
dive
too
much
into
it,
because
I
want
to
talk
about
this
more
as
a
like,
broader
question,
not
necessarily
specifically
just
to
this
one
but
we'll
be
working
with
mike
other
mic
mike
nichols
on
more
of
a
think
big
session
to
incorporate
all
the
different
styles
of
the
merger,
os
widgets.
That
could
be
introduced
into
the
mr
page
to
make
that
experience
a
little
bit
cleaner
and
make
more
sense,
because
now
we
have
a
lot
of
them.
It's
not
just
like
one
or
two.
A
It's
like
six
or
seven,
or
something
like
that.
So
now
that
we
have
like
numerous
options,
I
think
it
does
make
sense
to
start
defining
a
pattern.
So
I
guess
in
the
spirit
of
iteration,
this
won't
be
a
part
of
making
that
holistic
vision,
but
it
will
be
incorporated
in
the
future
into
a
better
experience
for
configuring
and
then
probably
the
way
that
they
all
render
to
in
the
merge
requests
would
be
awesome
but
yeah.
A
A
A
A
A
A
E
A
Yeah,
well,
I
mean
first
of
all,
we
haven't
even
released
the
first
feature
at
all,
so
we
just
have
had
so
much
discussion
around
it
and
the
biggest
thing
has
been
trying
to
scope
it
down
to
be
small
enough
that
we
can
technically
implement
it
within
like
one
or
two
milestones
and
not
stretch
it
out
over
like
10..
So
that's
probably
been
the
thing.
B
E
A
Yeah,
I
think
my
tension,
I
feel
is
it
might
change
like
we
might
release
this
first
feature
and
find
out
it's
really
not
yet
valuable
at
all.
We
just
kill
it,
so
I'm
not
even
promising
that
that's
the
future
iteration
I
kind
of
want
to
see
how
this
first
one
performs
and
better
understand.
Even
my
assumptions
of
what
makes
sense
for
the
next
iteration
are
valuable
because
I
don't
even
know
yet.
E
So
that
sounds
like
maybe
a
discussion
with
the
team
of
like
yeah.
These
are
ideas
that
we
need
to
validate
like
don't
get
stuck
on
them,
and
but
you
know
you
still
want
to
document
things
and
then
maybe
it's
documented
as
like
we're
still
validating
this
idea,
but
like
we
might
get
to
it,
we
might
not,
depending
on
validation.
G
Yeah
I
mean
what
I
keep
hearing
is
that
there
are
like
many
assumptions
floating
around.
You
know
like
even
saying
like.
There
are
certain
things
that
are
not
validated,
and
I
mean
even
from
a
research
perspective,
you
could
aim
for
some
validation
before
it's
being
implemented,
just
to
get
a
gut
check
and
it
might
even
help
with
you
know,
convincing
the
rest
of
the
team
or
like
just
having
better
arguments.
It's
just
a
matter.
If
you
have
you
know
time
to
do
these
things.
G
If
you
want
to
prioritize
it
and
how
much
of
a
technical
effort
it
is
to
implement
it,
you
know,
like
that's,
always,
usually
the
trade-off.
If
you
want
to
do
the
validation
before
or
after
but
yeah
it
almost
sounds
like
there
are
a
lot
of
things
unvalidated
and
it
might
be
useful
to
check
some
of
these
things
beforehand.
A
We
thought
we
had
enough
validation
around
the
initial
mvc
that
we
wanted
to
approach
with,
and
then
it
was
as
we
were,
getting
to
actually
try
and
schedule
it
like
in
1312,
now
we're
kind
of
needing
some
resistance.
So
that's
where
the
tension
point
arises,
daniel
I'll!
Let
you
carry
on
to
your
point.
F
Oh,
no,
it's
just
like
a
quick
check
on
on
the
wireframes.
I
don't
know
if
anyone
else
has
been
using
them,
but
I
went
into
it
for
the
first
time.
I
was
like
there's
nothing
wireframing
here
and
I
wanted
to
know
what
the
state
of
it
was,
and
so
I
just
realized
that
libor's
working
on
it,
which
is
good
but
yeah
like
I
was
concerned.
If
I
was
looking
at
the
right
thing
or
the
wrong
thing,
or
just
trying
to
get
a
context
on
it,.
B
Yeah,
just
to
give
you
some
more
context,
daniel
said
I
proposed
this
a
while
back
and
we
were
still
kind
of
going
back
and
forth
on.
You
know
where
it
should
live
so
and
then,
as
fig
as
you
know,
since
it
was
kind
of
an
older
issue,
figma's
released
a
lot
of
newer
updates
with
variants
and
stuff,
so
I
kind
of
came
back
to
with
the
newer
proposal,
and
so
there's
some.
B
If
you
look
towards
the
end
of
the
issue
with
some
comments,
we
were
you
know
debating
whether
we
should
use
a
create
variants
for
the
different
wireframes
and
then
looks
like
now.
The
decision
is
going
to
be
to
create
a
whole
new
wireframe
kit.
That's
like
works
in
parallel
with
the
existing
component.
Ui
kits.
What
it
will
do
is
it'll
pull
in
those
components
from
the
from
the
existing
component,
library
and
it'll
just
be
kind
of
styled
to
look
wireframe.
B
B
So
you
know
some,
and
so
this
way
it
will
kind
of
divvy
up
the
work.
So
someone
might
take,
for
example,
the
the
button
component,
and
then
you
know
finish
that
someone
might
style
up
or
wire
frame
up
the
the
table
component,
for
example,
so
that's
kind
of
where
I'm
seeing
this
going
next,
but
I
just
haven't,
had
a
chance
to
really
work
on
it
in
the
past.
A
couple
milestones,
so
I'm
going
to
try
to
fit
it
in
this
one,
so
I'll
I'll
make
sure
to
mention
you
guys.
There.
F
I
don't
know
it's
all
good,
like
I
said
I
wasn't
sure,
like
the
context
around
it,
if
it
was
kind
of
like
just
a
initial
proposal
or
whatever,
and
so
I
went
poking
around
in
there.
I
was
like
wait
a
minute.
It
doesn't
really
seem
like
a
wireframe
just
yet
the
idea
that
you
said
that,
like
having
it's
connected
to
the
current
component
library,
I
have
like
apprehensions
on
that,
because
if
the
idea
is
that
it's
gonna
be
a
one-to-one
with
just
different
styling,
I
would
argue.
F
That's
still
not
necessarily
the
wireframe
idea
that
still
ties
too
closely
to
the
architecture
that
we
have,
whereas
the
idea
could
be
for
a
wireframe.
I
want
to
look
at
this
in
a
really
rough
state,
with
no
real
ties
to
past
structure
or
past
ideas
of
what
something
should
be
and
keep
it
a
little
more
loose.
That
way
we
can
say
well,
this
doesn't
necessarily
make
sense
or
instead
of
having
to
say
well.
D
So
what
are
the
initial
things
that
we
want
to
be
using
this
wireframe
library,
for
sometimes
using
wireframes,
is
used
to
like
just
speed
up
the
design
process
a
little
bit
and
work
in
lower
fidelity,
but
I
suppose,
if
you're
mapping,
one
to
one
like
dan
says
the
speed
isn't
isn't
so
much
a
factor
because
you
can
do
high
fidelity,
stuff
and
prototype
stuff
at
the
same
time.
So
I
wonder
like
if
we,
if
we
have
a
very
specific
use
case
for
what
is
this
wireframe?
D
What
what
is
the
job
that
this
write,
a
job
statement
had
or
whatever
it
may
be?
What
is
the
job
that
this
wireframe
library
is
going
to
support
and
help
people
within
gitlab
specifically?
Do
that
that
would
be
useful.
So,
for
example,
I've
used
wireframes
in
the
past
to
communicate
stuff
at
moderate
fidelity
in
order
to
separate
out
people's
concerns
with
future
visions
and
the
ui
and
so
on,
and
just
use
it
to
convey
concepts
of
what
may
happen.
D
You
can
also
use
wireframes
to
just
discuss
the
the
information
architecture
of
a
page
or
whatever
it
may
be.
So
my
question
is:
what's
the
job
that
we're
trying
to
satisfy
with
this
particular
wireframe
kit
and
how?
How
is
it
going
to
be
differentiated
from
the
pajamas
kit
that
we
have,
which
I
think
is
reiterating
with
that
and
saying.
B
Yeah,
that's
that's
a
good
good
feedback,
dan
and
nick.
I
should
add
that
to
the
to
the
description
of
the
issue
there,
but
I
mean
for
me
it
is
be
able
to
be
able
to
just
quickly
illustrate
an
idea
with
the
existing
and
existing
components
that
we
have.
For
example,
you
could
quickly
throw
in
you
know,
set
of
tabs
or
table
or
whatever
and
make
sure
that.
B
F
Kind
of
expand
on
that.
I
think
if
we
reduce
the
fidelity
that
will
save
a
lot
of
work,
a
lot
of
detail
from
having
to
translate
stuff
one
to
one
is
just
like
here's
a
box:
it's
got
a
heading.
Next
I
mean.
Obviously
I
could
do
that
myself,
but
the
idea
of
kind
of
expanding
on
that.
How
can
I
make
this
box?
The
next
iteration
right.
B
F
B
Totally
agree,
I
know
there
was.
I
was
thinking
about
that
as
well.
I
mean,
for
example,
we
have
so
many
different
button
variants.
You
know
the
different
sizes
of
the
buttons,
for
example,
and
you
don't
necessarily
need
all
those
different
sizes
in
the
in
the
to
illustrate
an
idea
that
this
is
a
primary
button,
and
this
is
a
secondary
button.
You
know
to
go
through
a
quick
flow
or
something
like
that
so
yeah.
B
A
But
yeah,
like
you
guys,
are
saying,
like
it's
generally,
just
like
a
bunch
of
rectangles,
almost
a
bunch
of
different
versions
of
rectangles,
with
maybe
like
a
unique
looking
attribute
for
a
button,
since
it's
our
primary
call
to
action
on
a
user
interface,
so
yeah
anything
that
helps
just
generalize
areas.
It's
almost
like
the
skeleton
of
like
an
html
page.
Just
like
I
saw
a
quick
preview
from
everyone
sharing.
It
was
like
here's,
the
editing
section,
here's
the
main
body.
A
It's
almost
like
what
are
those
tags
that
you
would
show
not
necessarily
like
all
the
detail
of
them,
because
I
actually
really
love
using
our
current
pajamas
system
and
figma,
because
it
gives
me
a
ton
of
control
over
the
fidelity
of
it
in
terms
of
like
high
fidelity
and
it's
very
easy
to
use
as
a
sticker
components.
So
if
I
was
going
to
try
and
use
something,
less
specific
I'd
want
to
be
like
very
vague.