►
From YouTube: UX Showcase: Issuables interaction design framework
Description
Pedro Moreira da Silva, Staff Product Designer (Create:Code Review), explains his work on the issuables interaction design framework.
Epic: https://gitlab.com/groups/gitlab-org/-/epics/3637
Conceptual model issue: https://gitlab.com/gitlab-org/gitlab-design/-/issues/1222
Figma: https://www.figma.com/file/J68bePHXIN5OPWqaFFY9ri/Conceptual-model?node-id=51%3A18
Narrative object model: https://medium.com/@hpadkisson/object-modeling-for-designers-an-introduction-7871bdcf8baf
Semantic layout issue: https://gitlab.com/gitlab-org/gitlab-design/-/issues/1223
Figma: https://www.figma.com/file/shVF8UZwrQtkNfMDjcrsyH/Semantic-layouts?node-id=50%3A217
Pajamas MR to add object documentation for Merge Requests: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2136
A
So
I
don't
have
a
presentation
today.
So
I'll
just
I
don't
know,
go
go
with
the
flow
and
talk
with
you
about
something
I've
been
working
on,
which
is
called
the
issuables
interaction,
design
framework
and
a
little
bit
of
the
the
work
that
I've
been
doing
is
about
documenting
what
we
already
have
today.
So
let
me
share
what
that
looks
like.
A
So
the
this
framework
that
I've
been
talking
about
is
basically
having
a
solid
foundation
for
all
issuables
to
work
on
and
issuables
or
issue.
Issuable
objects
are
the
ones
that
share
the
same
foundation
of
issues,
so
those
are
epics
issues
and
merge
requests.
Those
are
the
most
common
ones,
but
now
we
also
have
other
similar
objects
that
fall
in
the
issual
category,
like
incidents
or
requirements,
and
maybe
others
in
the
future,
and
they
all
share
this
same
way
of
interacting.
A
Where
you
have
this
header,
you
have
the
sidebar,
you
have
a
content
area,
it
may
be
some
related
objects
and
then
you
have
a
stream
of
activity
like
an
activity
feed,
and
you
can
leave
comments
and
things
like
that.
So
this
is
the
the
base
of
the
model,
but
we've
noticed
over
time,
especially
as
we
have
progressed
to
have
separate
teams
and
and
people
and
designers
working
on
these
objects.
A
So
perhaps
to
start
I'll
show
you
a
little
bit
what
the
conceptual
model
is,
and
so,
if
you're
familiar
with
uml
class
diagrams,
this
looks
extremely
complex
and
you
have
to
know
the
language
and
know
what
it
means
to
read
this
kind
of
diagram.
So
I
found
this
article
talking
about
something
called
the
narrative
objects
model
and
it's
a
translation
of
the
uml
class
diagram
into
something
much
simpler,
and
that
is
a
bit
more
descriptive.
A
But
again
it's
a
narration
of
what
happens
between
the
object.
So
this
is
an
example
of
a
tweet
or
sorry
an
example
of
objects.
In
twitter,
where
you
have
a
tweet
and
then
you
have
an
account
and
you
have
a
direct
message
and
a
moment
and
the
relationships
between
them
and
inside
the
boxes
inside
each
of
these
objects.
A
You
can
then
describe
things
like
the
attributes
of
a
tweet.
The
actions-
and
this
is
also
explained
down
here-
what
you
can
do
and
add
to
this
model.
So
it's
a.
I
found
it's
a
very
simple
way
to
communicate
this
more
conceptual
way
of
looking
at
a
system,
and
so
I
started
working
on
this
figma
file
and
I
thought
it
would
be
better
to
do
it
in
figma.
So
let
me
bring
that
up
yeah.
A
So
this
is
currently
the
conceptual
model
that
I've
been
working
on
for
merch
requests,
and
I
try
to
keep
things
as
simple
as
possible.
But,
as
you
can
see,
merge
requests
are
already
quite
complicated.
They
have
a
lot
of
actions
and
the
actions
are
detailed
here
below
they
have
a
lot
of
attributes
and
then
it's
looking
at
the
relationships
between
all
of
the
other
objects
and
the
ones
in
blue.
I
try
to
make
use
also
of
the
the
links
in
figma.
A
So
you
can
see
here
under
objects,
you
have
the
merge,
request,
object
and
it
details
the
conceptual
model.
So
this
is
what
I
was
just
showing
you
right
now
and
it
also
details
something
that
is
the
semantic
layout
and
so
the
semantic
layout
is
could
be
described
as
the
visualization
of
the
conceptual
model
on
top
of
a
layout
right.
A
I've
made
some
changes
here
and
there,
based
on
on
feedback
and
jeremy
elder,
gave
me
a
great
idea
of
trying
to
use
letters
for
the
different
legend
types
here,
so
that
it
would
be
easy
to
scan
the
the
this
this
this
visualization
and
also
for
people
that
are
colorblind.
It
would
be
easier
for
them
to
to
read
so.
This
is
basically
overlaying
the
existing
ui
of
the
merge
requests
page
with
all
of
the
information
that
we
have
in
the
conceptual
model.
A
A
Are
they
grouped
in
a
certain
way
in
the
ui,
and
this
is
what
the
semantic
layout
allows
you
to
do
and
again
semantic
layout,
because
it's
bringing
meaning
to
the
way
we
lay
out
the
actions
entry
attributes
of
an
object
so
yeah
I'll.
This
is
what
I've
been
working
on
and
I'll
stop
there
for
questions.
I
wanted
to
make
this
really
short
so
that
this
can
be
a
more
free
flow
conversation.
B
A
Yeah
great
great
question
nick
and
I
was
hoping
someone
asked
that
so
let
me
give
you
a
concrete
example
of
what
this
allows
so
looking
at.
In
this
case
the
conceptual
model
of
merge
requests.
I
don't
know
if,
if
holly
is
on
the
call,
oh
there
you
are
so
you
might
be
able
to
to
also
comment
a
bit
on
this,
but
so
holly
has
been
working
on
an
issue,
a
very
challenging
issue
where
we're
trying
to
simplify.
A
Let
me
see
if
I
can
bring
up
this,
what
I'm
talking
about,
where
we're
trying
to
simplify
this
interaction
of
commenting
and
trying
to
remove
this
notion
of
commenting
and
starting
a
thread.
So
you
have
these
two
actions
and
each
action
does
a
different
thing,
and
this
is
also
it
has
more
variations
for
merge
requests
as
well
when
you
have
resolvable
threads
and
things
like
that,
and
so
this
model.
A
Looking
at
what
we
have
today
already,
you
can
already
see
how
complex
it
is
just
to
leave
a
comment
in
a
merge
request,
and
this
is
a
more
extreme
example.
So
let
me
show
you
how
that
could
look
like
in
an
issue.
For
example,
and
so
this
is
what
commenting
in
an
issue
looks
like,
and
you
have
the
ability
to
have
top
level
comments
and
then
reply
comments.
But
then,
when
you
reply,
you
have
a
reply,
comments
to
top
level
comments.
They
all
become
a
thread
and
it's
it's
already.
A
A
So
this
would
need
to
be
updated
when
we
do
significant
changes
to
the
actions
or
the
attributes,
but
I've
tried
to
keep
it
as
simple
as
possible,
so
the
maintenance
is
is
low,
but
I
think
this
is
good
not
only
for
design
but
also
to
have
better
conversations
and
more
efficient
conversations
with
engineers
and
with
with
the
whole
product
team.
Basically
does
that
help
answer
your
question.
B
Yeah
for
sure
you
illustrated
beautifully,
like
the
the
use
case,
for
how
you
can
increase
understanding
between
different
designers
and
different
stage
groups
who
are
using
the
same
object.
I'd
love
to
understand
if,
if
I'm
not
hogging
the
questions,
I'd
love
to
understand
how
you
you
imagine
this
being
used
with
with
product
in
particular,
or
maybe
a
little
bit
more
illustrative
of
how
it
may
be
used
with
engineering.
Although
I
think
that
one
example
is
probably
a
little
bit
more
obvious.
D
C
C
Example
that
you
just
gave
with
the
issue
with
the
resolvable
comments,
one
of
the
considerations
that
this
was
helpful
with
was
whether
or
not
we
should
have
resolvable
comments
within
issues.
We
currently
only
have
them
in
merge
requests,
and
so
gabe
has
been
considering,
adding
in
resolvable
comments
to
issues
as
a
future
feature.
A
A
A
great
one
holly
one
one
thing
I
wanted
to
add
quick
example.
I
also
don't
know
if,
if
libor
is
on
the
call
that
you
already
were
so,
I
was
giving
feedback
on
a
design
that
libor
was
working
for
integrations
and
at
certain
points
I
I
feel
like
having
a
similar
conceptual
model
for
integration
would
be
great
because
that
we
were
talking
about
the
terminology
of
using,
for
example,
reset
button
activate
deactivate,
enable
disable
clear
all
of
that
terminology.
A
It
would
be
great
if
we
just
have
a
quick
way
of
visualizing
it,
and
so,
for
example,
as
I
was
telling
libor
in
the
issue.
Well,
I
don't
know
if
this
term
makes
sense,
because
we
have
activates,
we
have
the
ability
to
save
an
integration.
We
have
the
ability
to
maybe
reset
it,
but
I
don't
I'm
not
sure
about
uninstalling
right.
Do
we
have
the
install
action?
Do
we
have
the
opposite?
So
this,
I
think,
would
be
would
have
been
a
great
support
for
that
conversation.
E
D
E
F
A
F
D
So
I
love
that
you're
documenting
this
in
pajamas.
That
was
when
you
started
the
presentation.
That
was
the
first
question
that
popped
into
my
head
and
I
do
think
that's
the
right
place
for
this
content.
I
also
think-
and
let's
just
build
on
what
everyone
said-
this
would
be
so
valuable
outside
of
ux
for
product
managers
and
for
developers.
D
So
I
would
like
for
us,
as
you
move
further
along
this
path,
to
start
to
think
about
how
we
drive
those
cross-functional
partners
to
this
content
so
that
they
know
that
it's
available,
because
I
I
don't
think
they
spend
much
time
on
design.gitlab.com,
but
it's
probably
because
they
don't
know
always
with
value.
Is
there
for
them.
A
Yeah,
I
I
think
yeah
without
trying
to
go
too
much
over
time.
Apologies!
Sorry,
but
yeah!
I
so
there's
two
things
to
that.
So
the
first
one
is.
This
conceptual
model
was
approved
by
daniel
gresso,
andre
and
michelle,
so
product
manager,
frontend
engineering
manager
and
backend
engineering
manager
for
source
code.
A
So
they're
already
aware
of
this,
so
that's
the
first
thing
and
the
second
thing
I
actually
think
having
this
kind
of
content
is,
would
be
more
helpful
to
product
managers
than
the
then
what
the
the
content
that
we
have
today
in
pajamas.
So
the
content
that
we
have
today
is
very
geared
towards
designers
and
front-end
engineers.