►
From YouTube: UX Showcase Workspace The First 90 Days
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
All
right,
so
my
name
is
mike
nichols.
I
am
a
staff
product
designer.
I
work
on
the
manage
workspace
team.
So
what
is
the
workspace
group?
The
workspace
group
is
responsible
for
rationalizing
the
data
model
for
containers
and
resources
within
gitlab
kind
of
a
mouthful,
but
really
it
comes
down
to
defining
and
applying
settings
to
all
your
group.
Subgroups
projects,
aggregating
data
from
all
of
those
things,
organizing
data
containers-
and
we
do
some
hardware
controls
as
well
as
a
little
bit
with
the
user
profile.
A
So
what
is
the
big
problem?
We're
trying
to
solve
so
today?
Gitlab's
features
exist
at
three
levels:
the
instance
the
group
and
the
project.
This
leads
to
a
few
problems.
One
three
ways
to
build
a
feature
leads
to
a
lot
of
engineering
and
efficiency,
we're
really
restricting
the
audience,
to
instance,
level
features.
A
So
where
do
we?
Where,
where
do
we
begin
this?
When
I
was
moving
over
to
this
group,
this
sounded
like
an
interesting
and
challenging
problem.
But
where
do
we
begin
well
so
on
april
12th
85
days
ago?
Hence
the
first
90
days
title.
I
joined
the
team,
so
the
first
thing
I
want
to
point
out
is:
I:
have
I've
switched
a
few
teams
in
the
past.
We
always
create
these
transition
issues,
but
this
is
the
first
time
that
I
really
like
leaned
into
it
and
leveraged
it.
A
So
I'd
like
to
encourage
everybody
to
to
not
take
this
as
like
a
step
that
you
have
to
check
off,
but
a
really
like
a
useful
thing,
so
one
it's
a
great
place
to
organize
and
and
just
kind
of
get
all
the
information
about
links
to
stuff,
ongoing
efforts,
priorities,
team
meetings
and
that
stuff,
but
what
I
really
used
it
for
is
a
bookmark
when
you
first
join
a
new
group
you're
to
be
lost,
so
this
kind
of
serves
as
an
anchor
point
to
reach
back
to,
but
the
one
I
really
wanted
to
point
out
was
a
pro
tip
from
marcel
this
time.
A
A
This
is
what
we
really
need
to
focus
on
during
this
time.
In
addition,
that
marcel
also
provided
me
a
lot
of
context,
links
and
a
lot
of
the
design
stuff.
A
So
the
first
thing
I
did
was
read
and
kind
of
read
everything.
So
the
workspace
group
did
not
start
with
me.
It
started
long
before
that.
I
traced
it
back
as
far
as
august
2020,
so
there's
been
a
tremendous
amount
of
issues.
Videos,
epics
discussions,
lots
of
stuff.
So
what
I
did
first
was
I
read
all
the
issues.
The
important
thing
was
reading
the
whole
issue,
all
the
comments,
every
single
one
of
them
and
that's
important
to
not
just
get
the
outputs
of
it
but
see
the
discussion.
A
A
At
this
point
like
reaching
out
of
any
linked
things
watched
all
those
videos
read
all
those
discussions,
but
then
I
did
it
all
again
and
again
and
again
and
the
reason
I
point
that
out
is
because
when
you
read
things
the
first
time
a
lot
of
times
you're
like
oh,
I
don't
know
about
that
that
I
I
you
kind
of-
have
preconceived
notions
about
that.
But
once
you
read
the
entire
body
of
work
oftentimes,
your
opinion
changes
on
the
things
that
you
read
at
the
beginning.
A
A
I
had
fallen
into
this
for
weeks,
but
I
kept
reminding
myself
that
it's
important
to
pound
this
information
in
my
brain,
because
any
solution
without
the
information
is
probably
going
to
be
incorrect
and
also
just
great
kudos
to
gitlab,
because
without
our
linked
issues
and
the
way
we
document
things,
all
this
information
could
have
been
lost.
But
it
was
all
there
from
years
ago
and
I
was
able
to
find
it.
A
So
as
I'm
going
through
this
this
tire,
this
this
mountain
of
information,
I
realized
it
needed
to
start
taking
notes.
So
I
created
a
a
issue
in
my
personal
project
and
I
think
it's
important
to
have
a
place
where
you
can
dump
unrefined
thoughts.
So
if
you
were
to
read
this
issue
a
lot
of
it
probably
wouldn't
make
sense
to
anybody
but
me,
but
having
a
place
that
you
can
just
dump
on
all
this
information
ideas,
hope
streams.
A
A
A
What's
the
top
level
mechanism
and
already
planning
to
change
the
name
spots,
namespace
model
organization,
inheritance
model,
so
the
goal
of
this
question
was
really
to
understand
the
bounds
of
the
problem
where
we
could
go
where
we
couldn't,
where
solutions
might
be
more
difficult
to
achieve,
and
what
I
did
with
this
was
kind
of
talk
to
everybody.
Talk
to
the
engineering
folks
talk
to
product
people,
talk
to
people
that
have
worked
out
from
as
in
the
past
and
just
kind
of
get
everybody's
opinion
on
this.
A
Also,
as
you
can
tell,
I
probably
see
from
my
screenshot
here,
I
do
like
to
talk
with
my
hand,
so
I
try
to
find
the
most
ridiculous
example
of
that,
and
I
think
I
did
that
so
if
you've
watched
it
in
my
showcase
before
you
know
that
kind
of
my
core
belief
as
a
designer
is
getting
to
the
root
of
the
problem.
A
So,
as
I
was
reading
through
all
of
the
discussions,
I
started
taking
a
look
at
sus
verbatims.
Our
pm,
christina,
is
doing
customer
interviews
at
the
moment,
so
reviewing
all
those
we
started
to
generate
a
giant
list
of
problem
statements
more
than
just
the
three
ones
that
I
started
with,
but
you
know
kind
of
a
raw
list
of
of
everything.
So
we
collected
all
those
problem
statements
in
an
issue
and
then
I
was
able
to
utilize
the
recently
introduced,
drag
and
drop
feature
to
reorganize
them.
A
Right
now
we
have
a
consolidated
list,
but
we're
determining
whether
or
not
we
believe
that
they
are
root
cause
or,
if
they're
still
a
little
bit
deeper.
We
can
go
so
the
end
goal
of
these
root
cause
problems
is
to
be
used
as
a
tool
as
an
investigation
serve
as
an
anchor
in
discussions
and
ultimately
use
for
the
criteria
of
evaluating
the
success
of
design
solutions.
A
So
then
we
started
exploring
the
solutions
with
the
context
problem.
With
the
context
from
the
reading
and
the
problem
statements
in
hand,
we
would
start
looking
at
possible
solutions,
but
the
goal
wasn't
necessarily
to
derive
at
a
final
solution.
It
was
more
to
like
explore
ideas
and
see
where
they
might
take
us.
So
I
tried
out
a
number
of
configurations
and
determined
what
would
be
needed
for
each
so
basically
like
what
would
it
take
from
a
design,
an
engineering
standpoint
to
to
get
them
accomplished
for
each
one?
A
I
would
like
to
take
a
moment
to
take
a
make:
a
quick
plug
for
flow
maps.
I
love
them.
They
turned
out
to
be
a
great
tool
for
this
problem
solving,
but
I
think
we
are
under
utilizing
them
as
a
tool.
I
I
find
that
it's
a
great
way
to
iterate
quickly
through
ideas,
because
they're
low
fidelity
enough,
but
they
have
just
enough
ui-
that's
kind
of
grounded
back
in
the
product
figma
jam
was
was
a
tool
I
was
using
for
that.
A
So
this
is
kind
of
the
dun
dun
dun
moment
of
the
talk
here,
so
I'm
guessing
a
lot
of
people
were
hoping
that
I
would
go
through
these
solutions
today,
but
unfortunately
there's
a
lot
of
them
and
it
takes
about
five
ten
minutes
to
go
through
each
one.
So
this
format
just
wouldn't,
have
been
possible
for
that.
I
would
have
already
been
out
of
time,
but
I
have
an
issue
linked
there
that
has
a
write-up
on
each
one
of
them
and
each
one
of
them.
A
I
recorded
a
kind
of
walk-through
video,
so
I'd
invite
everybody
to
who's
interested
in
the
solution,
investigation
to
go
check
out
that
issue
and
watch
those
async,
but
we
do
have
some
takeaways
that
I'd
like
to
talk
about.
So
we
learned
that
there's
an
inherent
dichotomy
that
exists
so
an
example
is
like
access
versus
confidential
confidentiality.
A
You
might
want
to
add,
like
everybody
to
the
root
group,
so
that
everybody
has
access
to
everything,
but
then
that's
inherently,
then
nothing
can
be
confidential
if
everybody's
in
everything
that's
an
example
of
that
or
like
content
optimizing
for
content
consumption
oftentimes
leads
to
an
admin
experience
that
that
isn't
there
so
as
we're
going
through.
We
know
that
there
are
certain
things
that,
like
there
just
isn't
it's
always
going
to
be
in
either
or,
and
we're
going
to
have
to
account
for
those
things.
A
A
Groups
and
projects
are
either
going
to
need
to
converge
or
diverge
so
as
name
spaces
as
features
become
available
as
name
spaces
and
more
there's
becomes
more
feature
parity
between
there
we're
either
going
to
need
to
make
a
decision
on
whether
we
make
groups
and
projects
look
a
lot
like
each
other
or
use
them
as
completely
separate
tools,
meaning
like
jobs
to
be
done
that
are
focused
on
groups
versus
jobs
to
be
done
that
are
focused
on
projects.
We
know
we
need
to
improve
the
navigation
and
wayfinding
between
spaces.
A
We
also
need
to
evaluate
context,
switching
so
the
example
I
like
to
use
for
this.
If
I
go
to
a
group-
and
I
click
on
an
issue-
I
take
it
out
of
that
group
and
I'm
placed
into
a
project
now-
I'm
not
so
necessarily
saying
that
that's
bad,
but
we.
What
we
may
have
unintentionally
done
is
completely
switch
the
context
on
our
users.
There
we're
doing
this
context
switching
a
lot,
and
the
thought
is
that
this
might
be
contributing
to
the
I
feel
lost
in
gitlab
problem.
A
We
also
need
to
take
a
look
at
improving
landmarks,
so
a
user
can
orient
orientate
themselves
to
where
they
are
in
the
organization,
and
we
know
that
name
spaces
are
going
to
be
part
of
any
final
solution,
so
one
more
thing
consolidating
groups
and
projects-
and
this
probably
could
have
been
its
own
talk
in
itself,
but
engineer
engineering
work
is
currently
underway
to
consolidate
groups
and
projects
behind
the
scenes
so
from
an
engineering
standpoint,
they're
moving
to
name
spaces.
A
We
know
namespaces
will
be
part
of
any
workspace
solution,
so
this
is
a
good
time,
even
though
we
don't
have
the
final
solution
of
what
the
overall
workspace
vision
is
going
to
look
like
doesn't
mean
we
can't
start
thinking
about
what
it
might
mean
if
your
features
in
your
group
move
to,
let's
say
a
project
or
a
group,
or
vice
versa,
so
teams
are
likely
to
face
many
of
the
same
challenges
when
they're
migrating
these
features.
A
So
what
my
ask
is,
please
ping
me
if
your
group
is
planning
to
planning
to
move
these
evaluating
whether
they
want
to
move
these
or
already
in
the
process
of
moving
these
features
between
different
levels.
My
goal
here
is
to
assist,
but
also
like.
I
want
to
learn
what
the
challenges
are,
so
I
can
help
other
teams
and
then
also
apply
that
solution,
and
I
am
hoping
to
develop
an
issue
template
to
help
groups
go
through
this
process
and
I
have
started
that
there.
A
B
All
right-
and
I
am
going
to
keep
recording
for
the
discussion
hopefully-
and
I
believe
tory
has
at
least
the
first
question,
and
I
see
some
coming
in
right
now
so
tori
you
wanna,
go
ahead.
C
Yeah,
I
was
wondering
just
because
we
have
a
little
bit
of
extra
time
if
you
would
be
willing
or
able
to
share.
Maybe
one
of
the
explorations
that
you
worked
on,
maybe
the
one
that
you're
feeling
most
confident
about
to
kind
of
give
me
and
everyone
else,
a
sense
of
where
workspace
may
potentially
be
going.
C
A
A
There
are
some,
I
recorded
them
with
blair,
so
there
is
a
little
bit
of
you'll
get
a
presentation,
but
you'll
also
get
some
kind
of
feedback
and
follow-up
questions
from
blair
on,
though
so,
if
you
don't
mind,
I'd
rather
just
just
defer
to
those.
D
D
The
next
question
you
know,
as
you
pointed
out
earlier
in
your
presentation,
this
problem
has
existed
for
a
long
time.
There
was
first
formed
around
it
in
early
2020
and
personally,
it's
something
I've
been
watching
for
a
long
time,
because
it's
very
relevant
to
my
area.
In
your
opinion,
why
has
there
not
been
a
lot
of
traction
on
solving
it
in
the
past
and
sort
of
with
that
in
mind?
You
know,
how
are
you
approaching
the
problem.
A
Yeah,
I
I
think
that
there
there
definitely
has
been
work
on
it
the
whole
time.
I
think
it's
maybe
perceived
as
not
having
traction,
because
we're
kind
of
now
just
getting
to
the
what's
the
workspace.
What's
the
top
top
thing
on
there,
but
the
work
that's
been
going
on
for
consolidation
of
groups
basically
was
determined
that
whatever
solution
there
was
gonna,
be
so
much
engineering
efficiency
gained
by
consolidating
groups
and
projects
into
a
name
space
that
it
was
decided.
A
A
It's
also
just
a
complex
problem
that
is
fraught
with
those
dichotomies
that
I
was
kind
of
mentioned.
It's
it's.
There,
isn't
a
silver
bullet,
easy
solution.
So
it's
it's
just
the
kind
of
thing
that's
going
to
take
some
time
to
work
through.
A
A
Anything
that
any
kind
of
vertical
tree
structure
leads
you
to
a
place
where
you
need,
let's
say
an
asset
here
that
needs
to
be
available
in
a
project
over
here,
so
there
just
isn't
a
way
that
what
I
mean
by
that
is
it
doesn't
matter
what
you
do
put
it
at
the
top
bottom
left
right,
wherever,
like
one
thing,
can't
solve
that
it,
it
has
to
be
a
different
mechanism
that
allows
you
to
share
horizontally
because
there
just
needs
to
be
a
way
to
get
across
things.
A
A
I
also
think
I
explained
that
better
in,
like
the
fourth
video
on
that
issue
that
I
linked,
I
think
that
one's
it's
definitely
in
one
of
those
solutions
there
I'm
trying
to
remember
what
that
I
phrased
that
better.
I
think
in
that
video
right
blair.
B
Yeah
definitely-
and
I
will
add
a
mic
sort
of
hint
to
this
intori's
question.
But
the
videos
are
a
company
not
just
the
problem
statements
but
also
have
great
web
flows
with
each
one
and
it's
kind
of
a
a
conversation
between
mike
and
I
so
there's
a
little
bit
of
back
and
forth.
B
And
there's
about
eight
or
nine
of
them,
so
that's
kind
of
why
take
it
at
your
own
time.
B
It
looks
like
the
end
of
the
questions
I
believe
justin's
filling
out
the
rest
of
the
notes.
I'm
gonna
hit
stop
here.