►
From YouTube: UX Design review: Plan/Manage/Ecosystem
Description
Libor, Austin, and Daniel meet to discuss:
00:00 - License and Compliance feature utilization, and promoting under utilized features
12:45 - Solution validation; how much validation is needed for small changes
A
Cool,
so
I
have
the
first
agenda
point
I'll
share
my
screen
kind
of
talk
through
it.
So
recently,
a
future
flag
was
turned
off
for
the
security
and
compliance
configuration
page
and
there
are
two
tabs
in
it
right
now.
The
first
one
focuses
on
security
testing,
so
it
tells
you
whether
you're
sas
to
das
and
container
scanning
is
all
set
up
and
then
gives
you
links
to
either
docs
or
ways
to
directly
kick
those
things
off
like
in
the
ui.
A
So
I
think
there
was
a
lot
of
thought
to
the
security
page,
the
compliance
one
I
think
just
got
shipped
very
nbc,
so
you
might
notice
that
the
actual
description
here
didn't
change
at
all.
It's
the
same
one,
but
it's
talking
about
security
stuff,
so
that's
gotta
be
updated.
If
you
didn't
know
this
already,
my
group
does
not
actually
own
license
compliance.
It's
actually
a
different
group,
so
there's
some
overlap
in
terms
of
how
users
might
perceive
compliance
and
how
we
break
apart
the
features
across
our
stages
and
groups.
A
So
I
was
trying
to
think
about
how
we
could
address
what
I
consider
ux
debt
at
this
point,
because
now
we
have
something
called
compliance
configuration
and
it's
it's
lacking
a
lot
of
our
feature
set.
So
if
you're,
actually
in
our
docs,
you
would
see
that
we
have
a
compliance
feature
page
and
it
has
a
bunch
of
features
listed,
the
tier
they
associate
to
whether
or
not
it's
something
that's
on
self-managed
or
sas.
A
A
So,
in
that
same
vein,
I
was
thinking
of
doing
this,
something
similar
for
the
compliance
side,
where
calling
out
the
different
compliance
features
that
we
have
documented,
but
perhaps
like
showing
some
details
that
aren't
necessarily
exposed
because
they're
buried
in
settings-
and
you
have
to
be
like
an
owner
to
see
them
so
being
able
to
like
what
what
restrictions
do.
You
maybe
have
around
your
ssh
keys
or
knowing
that
your
protective
branches
are
configured
like.
A
So
I
guess
where
I
was
trying
to
get
some
feedback
from
you
all
is
what
are
your
thoughts
around
this
type
of
page
and
communicating
both
the
utilization
of
a
feature,
but
also
perhaps
like
giving
them
a
direction
to
kick
off
the
configuration
if
they
haven't
done
so
already.
B
A
It's
a
good
question.
The
most
frequent
conversations
I've
had
around
with
growth
have
been
some
of
the
conversion.
A
States
is
what
I've
been
calling
them
like:
hey,
you're,
not
on
ultimate
try
this
feature
and
get
to
experience
it
for
the
first
time,
but
I
haven't
talked
to
them
directly
about
this
page
honestly,
I
just
kind
of
remembered
it
for
the
first
time
on
friday,
andy
was
the
one
working
on
the
security
like
the
designs
for
all
this
back,
I
want
to
say
in
like
the
spring
and
when
he
was
gone
on
fraternity
leave,
they
built
it
and
then
they
just
recently
removed
the
feature
flag.
A
So
I
think
maybe
we're
a
good
place
to
start
would
be
just
continuing
to
ask
andy
some
more
questions.
Maybe
he's
worked
with
the
growth
team
already
to
develop
like
why
this
page
should
exist,
because
it
is
kind
of
unique.
We
don't
really
have
any
other
configuration
sections
under
any
of
our
other
settings
or
sorry.
Any
of
our
other
feature
sets
it's
only
in
security
and
compliance.
C
Yeah,
when
I'm
looking
at
it
too
right
now,
austin
I'm
curious:
do
you
know
what
compliance
is
planning
or?
What's
what
their
plan
is
to
what
they
want
to
do
in
their
tab?.
C
A
Yeah,
I
don't
think
anybody
is
really
taking
direct
ownership
of
it.
I
think
what
andy's
initial
approach
was
was
all
right.
These
are
all
the
features
that
we
have
in
the
security
and
compliance
tab.
So
therefore
we
need
to
have
probably
something
associated
to
each
of
these
in
the
configuration
page
itself.
So
that
was
the
starting
point.
I
don't
think
anybody
specifically
owns
the
compliance
tab.
I
just
am
volunteering
myself
to
take
ownership
of
it.
If
that
makes
sense,
I
think
the
main
focus
for
andy
has
been
the
secure
side
and
it
was
like.
A
A
Yeah,
so
I'm
trying
to
find
like
a
good
mvc
forward.
One
way
I
thought
I
could
do
this
is
you
know
we
start
with
what
exists
today.
So
it's
just
the
license
compliance
and
maybe
we
add
on
just
one
of
the
compliance
features.
So
maybe
we
add
on
separation
of
duties,
and
we
tell
you
whether
or
not
you've
set
up
protected
branches
mix.
C
Got
it
yeah,
that's
interesting,
yeah.
I
do
like
your
your
idea
there
of
exposing
some
of
the
the
features
there
like,
for
example,
under
the
ssh
key
restrictions,
some
of
the
the
read-only.
A
I
think
the
complexity
for
both
security
and
compliance
themselves
is
a
lot
of
our
features
are
disjointed,
so
the
settings
are
buried
in
different
places
and
bringing
them
together
into
a
cohesive
space
that
gives
you
both
an
awareness
of.
How
are
you
utilizing
these
expensive
features
for
lack
of
their
description,
and
how
can
you
actually
take
advantage
of
them
would
help
streamline
that
experience
a
bit
more,
so
you
don't
have
to
have
so
much
discovery
which
goes
back
maybe
to
daniel's
point
of
growth
might
have
some
ideas.
B
A
B
A
B
Your
layout
visually,
I
think
it's
fine,
it
makes
sense.
I
think
your
mvc
proposal
also
makes
sense,
but
that's
my
only
concern
is
the
visual
presentation
at
this
point.
A
Yeah
I
agree.
I
brought
that
up
initially,
even
with
michael
when
he
was
designing
the
settings
sections
because,
like
all,
we
would
have
this
description
of
the
content
on
the
right
on
the
left
hand
side,
but,
as
you
can
even
see
in
here
like
it,
doesn't
scroll
with
the
content.
So
like
it's
just
kind
of
killing
space,
I
think
at
very
least
it
needs
to
be
pinned
so
that
it
scrolls
with
the
content
you
know.
A
So,
when
you're
at
the
bottom
of
the
page,
you
at
least
still
have
context
that
you're
working
with
the
security
and
testing
but
yeah
it
is,
it
did
kind
of
just
like
form
on
its
own.
I
don't
really
know
how
any
got
to
this
point
necessarily,
so
I
guess,
if
you're
a
smaller
design,
that
content
just
goes
to
the
top
of
the
page
but
again
yeah.
I
agree
with
you
100
like
the
white
space.
A
It
does
kind
of
fit
the
side-by-side
view
that
michael
was
going
for,
but
then
it
also
brings
in
these,
like
gray,
containers,
to
like
break
it
down
to
chunks,
which
is
not
necessarily
what
was
in
that
design.
That
michael
was
working
on
so
I
think,
there's
still
some
design
iteration.
That
might
happen
in
this
space.
A
C
Yeah
cool,
interesting
problem,
one
other
thing.
Sorry,
I
wanted
to
add
awesome.
Oh
yeah,
please
yeah!
I
just
wanted
to
say,
like
I
think
what
daniel
brought
up
too
is
interesting
is
I
was
thinking
about.
That
too,
is
how?
How
does
this
translate
to
like
self-managed
and
like
the
admin
settings
area
you
know?
Is
there?
Is
there
any
kind
of
duplication
or
happening?
Maybe
between
those.
A
No
and
yes,
there
are
features
that
exist
in
the
admin
area
that
also
exists
in
a
project.
If
that
makes
sense,
but
where
I
was
thinking
about
this
configuration
page
in
particular
would
only
be
displaying
the
implications
on
that
project,
so
I
believe
in
the
admin
area
you
can
set
your
restrictions
on
ssh
keys,
so
I
would
love
to
display
like
what
are
those
restrictions
in
your
project,
but
you
can't
necessarily
set
those
in
your
project
settings
if
that
makes
sense.
Yeah.
A
To
like
take
the
setting
out
of
the
admin
area,
I
just
want
the
people
in
a
project
to
know
like
hey
here:
are
your
restrictions
on
ssh
keys?
You
won't
know
this
until
you
try
and
add
one
because
it
won't
tell
you
until
you've
added
it,
and
then
it
tells
you,
oh
you're
not
allowed
to
have
this
fingerprint
style.
You're
required
to
have
this
one.
Oh
well,
thanks
for
telling
me
way
too
late.
B
B
Of
other
cases
where
that
behavior
pops
up
like
I
just
had
a
feedback
or
working
on
a
session
right
now,
where,
if
somebody
tries
to
push
via
https,
they
get
an
error
or
let
me
back
up
if
they
have
created
a
gitlab
or
account
logged
in
onto
the
gitlab
account
system
with
like
a
google
account
but
didn't
create
a
gitlab
account
password
and
they
try
and
do
a
push
with
https.
It
will
block
them
from
from
that
process
because
they
need
to
create
an
account
and
so
there's
feedback
saying
like
no.
B
I
don't
want
my
people
to
create
accounts.
We
don't
use
that
feature,
and
so
the
proposal
was
just
put
up
a
banner
saying
you
need
to
put
in
a
password
and
that's
where
that
rejection
came
back.
Saying
no
wait.
We
don't
want
anybody
to
set
up
a
password
because
we
don't
use
that,
and
so
it's
like
wait
a
minute.
B
Somebody
else
might,
but
you
don't
and
so
having
a
toggle
for
that
feature
on
and
off
at
the
admin
level
might
be
helpful
but
again,
like
I
said,
they're
not
going
to
encounter
the
problem
until
they
hit
that
wall
and
they
won't
know
until
it's
there
and
then
what
happens.
So
it's
another
another
type
of
iteration
on
that
problem,
yeah.
A
Sense
daniel
did
you
want
to
talk
about
some
feedback
for
solution,
validation,.
B
Yeah,
so
we
had
a
our
milestone
feedback
in
our
group
and
I
got
some
feedback
and
I
felt
really
bad
about
it.
Basically,
one
issue
came
up.
While
I
was
out
of
office,
my
dev
had
tried
to
get
just
ux
validation
on
the
fix
from
my
replacement.
While
I
was
out
of
office
and
they
proposed
a
new
change
to
that
iteration
and
that
caused
a
lot
of
back
and
forth.
So
the
dev
had
to
undo
some
change
and
go
back
and
do
start
over.
B
B
And
then
the
next
milestone,
another
dev
or
somebody
had
come
back
and
said:
hey
people
are
getting
complaints
about
this
because
it's
it
doesn't
apply
to
their
environment.
It
was
like
a
2fa
something
it's
similar
to
that
https
password
where
they're
not
supposed
to
set
up
2fa
and
we
put
a
warning
up
on
the
site
on
the
banner
says
you
need
to
install
2fa
and
again
it
felt
like
another
outlier
case
where
nobody
thought
about
it
between
the
four
of
us,
so
that
created
a
new
proposal
that
we
haven't.
B
I
don't
know
if
we
fixed
it
yet
or
not,
but
a
feedback
session
where
we
had
to
go
back
and
make
a
change
to
the
thing
that
we
initially
thought
was
a
totally
valid
change
before
so
I
want
to
know,
should
I
be
changing
my
solution?
Validation
process
should
I
I
think
I
should
slow
down,
but
these
felt
that
they
were
very
small
iterative
changes.
I
felt
that
they
went
through
enough
different
parts
of
the
organization
to
get
feedback
on
specifically
customer
success
and
tech
writing,
and
so
I
was
curious.
B
A
I
wanted
to
ask
a
question
around:
maybe
what
so,
what
specifically
made
you
feel
bad
about?
Getting
there
were
more
discussions
and
that
one
merged
request.
You
mentioned
that
your
teammate
covered
for
you,
while
you're
out
of
office,
and
then
there
was
another
instance
where
jason
kicked
back
after
having
gone
through
all
the
validation
cycles.
You
know
the
different
teams,
different
groups
of
individuals,
so
was
it
specifically
that
kind
of
like
man,
that's
not
cool.
B
I
guess
it
felt
more
like
I
either
didn't
follow
some
process
or
I
didn't
adequately
do
solution,
validation
or
I
felt
like.
Maybe
I
had
done
something
wrong.
Perhaps
that's
just
my
interpretation,
but
in
order
to
avoid
any
sort
of
experience
like
that
in
the
future,
I
want
to
make
sure
that
I
think
about
it
and
address
it
and
try
and
build
off
of
that
encounter.
B
I
can't
say
for
certain:
I
will
assume
that
the
back
and
forth
and
the
reiteration
on
the
prototype
or
the
the
final
visual
caused
my
dev
extra
work,
because
he
said
he'd
already
finished
the
task
and
was
ready
to
to
send
it
the
mr,
but
it
just
needed
me
to
validate
it,
which,
if
I
was
there
I
said
yeah.
It
looks
good
to
me
and
moved
it
on.
B
It
would
have
been
fine
until
the
second
person
who
was
doing
the
us
validation
says:
oh
wait
a
minute:
let's
do
this
and
reiterate
and
make
it
easier.
My
push
back
there
was
like
well,
arguably
that
should
have
been
a
different.
Mr
for
the
next
milestone.
You
know
mvc.
Let's
do
that.
Take
this
as
ux
debt
and
then
move
forward.
A
Got
it
I'll
share
my
two
cents
and
then
I'll
I'll?
Let
lebor
take
the
wheel
if
he
has
any
feedback
too.
I
totally
resonate
with
what
you're
saying
I
really
want
to
make
it
a
streamlined
experience.
Once
we
get
to
the
merge
request
that,
like
once,
you
get
the
designs
through
there,
I
can
check
them
out.
They
meet
our
intent.
If
we
run
to
speed
bumps
like
we
discover
a
technical
barrier
or
perhaps
some
late
game
feedback
comes
in
that
we
can
address
those
things
with
follow-up
issues.
A
Maybe
they
are
things
we
have
to
compromise
on
and
they
are
ux
debt,
or
maybe
they
just
are
better
ideas
that
we
can
follow
up
with
in
the
future,
and
that's
okay,
it's
like
okay,
that
something
small
goes
through
and
it's
not
the
ideal
thing,
and
we
can
just
take
it
on
the
next
milestone,
because
I
hate
the
idea
of
like
engineers
just
having
to
continue
to
spin
on
things,
because
we
didn't
refine
them
enough
in
our
validation
track.
So
I
personally
think
there
may
be
two
opportunities
here.
A
You
could
maybe
provide
some
coaching
to
whatever
designer
team
numbers
that
you
worked
with
in
those
merge
requests
around
like
how
we
might
consider
addressing
things
in
future
milestones
and
building
to
the
work
we
agreed
upon
going
into
it,
and
then
the
other
side
of
that
could
be
hearing
feedback
from
them
in
terms
of
what
they
think
could
have
been
addressed
earlier,
or
maybe
even
what
engineering
thinks
could
have
been
addressed
earlier
before
things
got
into
the
build
track
might
be
able
to
give
you
some
insights
for
the
future.
B
C
B
Yeah,
so
the
issue
was
around
implementing
utc
time
codes
in
the
profile.
B
That
makes
sense
and
that
went
to
the
mr
and
then
I
went
on
holiday
and
then
the
ux
reviewer
came
back
and
said:
hey,
wouldn't
it
be
better
if
we
put
the
actual
time
on
there,
not
the
utc
time.
So,
instead
of
saying
utc
minus
one,
the
proposal
would
be
put
in
5
25
p.m.
Actually,
back
up
a
second
one
of
the
things
that
they
were
saying
was
in
the
utc.
It
says:
utc
minus
5.75
for
like
these
time
zones
that
have
like
shifts
by
15
or
45
minutes.
B
So
it
was
a
weird
thing
as
I
go.
How
do
you
do
that
and
then
he
said:
why
don't
we
just
put
it
the
times
exactly
so
it
would
say
utc
or
local
time,
5
45
pm
instead
of
the
udc
minus
5.75
right
right,
and
then
there
was
another
feedback
around
saying.
Well,
wait
a
minute!
B
Not
everyone
does
the
12
hour
calendar
and
so
that's
a
whole
nother
discussion
topic,
and
so
all
this
back
and
forth
was
like
you
know
you
have
to
wait
till
somebody
responds
if
you're
not
in
the
same
time
zone
because
of
our
async
comms.
So
definitely
push
back
push
the
mr,
which
could
have
been
just
like
yeah,
that's
good.
Let's
move
it
to
probably
multiple
days
of
waiting
around
iterating
and
thinking
and
rewriting
the
dev
code.
B
So
until
it
finally
went
forward
with
now
it
says
the
time
zone
or
excuse
me,
it
says
a
little
clock
icon
and
then
the
local
time
based
off
of
a
12
hour
calendar
because
that's
what
we
use
throughout
the
environment,
so
that
was
from
my
pushback,
would
be
well.
Arguably,
that
should
have
just
been
the
next
iteration
right,
adding
an
icon,
adding
the
local
time
discussion
by
15
or
45,
or
you
know,
0.75,
that's
a
weird
discussion
topic
12
hour
versus
24
is
another
whole
discussion
topic,
there's
actually
a
big
issue
in
our
backlog.
B
That's
been
in
there,
it's
like!
Well,
we
have
to
change
that
across
the
entire
organization
and
it's
something
that
we
want
to
do,
but
so
it's
a
cultural
discussion.
So,
like
all
these
things,
like
cultural
time
zone
discussion
like
how
people
view
the
clock,
how
do
you
want
to
manifest
it
with
an
icon?
B
Or
just
you
know,
a
text
link
or
whatever
it's
like
all
that
really
could
have
been
done
on
the
next
iteration,
and
so
that
was
my
like
initial
pushback
in
the
in
the
comment
thread
when
this
was
brought
up
after
our
review
process,
and
I'm
just
saying
like
I
want
to
make
sure
that
all
of
that
topic
and
discussion
should
have
been
done.
Perhaps
before
the
first
iteration
went
out
or
the
counter
argument
is
no,
that's
totally
logical.
My
first
iteration
made
sense.
C
Okay
got
it
thanks
for
explaining
that
better
yeah
yeah,
you
think
about
that.
A
little
bit.
A
A
Then
it's
not
really
reasonable
to
keep
that
in
the
scope
plenty
of
times.
I've
just
said:
no,
we'll
just
do
a
follow-on
issue
great.
I
love
this
idea.
Let's
take
action
on
it.
Next
milestone,
it
just
embodies
our
values,
we
iterate
on
stuff,
and
we
will
continue
to
iterate
on
it.
It's
not
we're
going
to
ship
the
time
clock
once
and
then
never
go
back
to
it
again.
A
If
we
have
a
better
idea,
that's
also
a
problem,
then
there's
a
justification
for
the
future
unless,
like
obviously
it
is
like
significantly
degrading
the
user
experience
or
if
it's
completely
blindsided
by
something
that
maybe
is
offensive
to
like
a
cultural
group
or
something,
but
I
mean
otherwise,
yeah,
let's
just
iterate
on
the
future,
and
that
maybe
is
a
hard
conversation
of
being
able
to
say
we're.
Gonna
sideline
this
and
we'll
address
it
in
another,
milestone.
C
Yeah,
I
agree
with
that
yeah
with
the
spirit
in
the
spirit
of
iteration
yeah,
I'm
just
wondering
back
to
your
example
daniel.
I
was
wondering
so
it
sounds
like
you
kicked
off
this
as
an
mr
right
away.
There
wasn't
like
an
issue
beforehand.
B
And
it
came
as
a
real,
simple
thing
as
like
some
change
about,
we
want
to
show
utc.
I
was
like
okay.
I
just
looked
at
the
profile
page
like
this.
We
can
drop
it
in,
like
literally
I
just
a
10
second
fix
and
like
design
weight
of
one
and
just
didn't
think
about
it,
because
it
was
not
a
big
thing,
but
that's
the
reason
I
brought
up
the
topic
of
conversation
is
because
I
thought
the
same
thing
about
the
banner
change
with
like
putting
in
2fa.
I
was
like
oh
yeah.
B
If
you
don't
have
2fa
on
there
put
on
a
simple
banner
and
say,
please
make
sure
you
have
2fa
enabled
and
that's
why
I
made
sure
I
asked
for
a
feedback
session
amongst
the
other
organization
to
make
sure
that
it
was
logical
and
reasonable
until
after
it
went
live,
and
this
one
organization
says
no,
we
don't
want
2fa,
because
we
have
some
other
authorization
method
and
totally
screwing
everything
up.
I
was
like
my
bad
and
that's
kind
of
where
the
the
argument
came.
Should
I
slow
down
my
process
and
not
just
be
like?
C
Yeah
I'm
wondering
if
the
problem
wasn't
like
defined
well
enough,
maybe
in
the
beginning,
in
that
issue,
before
you
maybe
took
it
on
to
kind
of
you
know,
jumping
maybe
it's
possible
that
you
jumped.
I
think
it
sounds
like
your
process
is
fine.
I
wouldn't,
but
maybe
questioning,
maybe
the
the
initial
problem.
Maybe
more
maybe
would
have
you
know
helped
you
know.
Maybe
the
back
and
forth
would
have
started
sooner
before
it
would
have
been
vmware.
So
maybe.
A
C
A
To
slow
down
daniel,
I
want
you
to
like
just
feel
empowered
to
do
your
best
due
diligence,
because
the
worst
thing
to
get
stuck
in
would
be
like
to
feel
like
you
have
to
get
everybody's
handshake
to
get
anything
done
in
gitlab,
and
that
is
not
how
we
operate
like
you.
Do
your
best
to
tie
in
the
groups
that
do
that
like
are
related,
and
you
will
miss
things
like
I
presented
on
it
the
other
week
last
week
on
the
uk
showcase,
I
had
an
idea.
A
C
B
But
if
I
have
the
quote-unquote
authority
or
expertise
to
say
this
seems
like
a
logical
first
iteration
or
mvc.
Let's
go
ahead
and
do
this
and
I
think
I've
got
ample
validation
by
the
reasonable
stakeholders.
Then
we
can
move
forward
and
so
that's
kind
of
where
the
whole
I
felt
bad
about
it
feeling
came
from
and
that's
why
I
brought
it
up
in
discussion
today
to
see
what
else
people
are
thinking
about
that.