►
From YouTube: UX Showcase: Feature Flag Redesign
Description
Mike shares UX work on redesigning Feature Flags in GitLab Release
A
Okay,
so
Mike
Nichols
senior
product
design
working
on
release
today,
we're
gonna
talk
about
feature
flags
and
a
little
bit
of
redesign
that
we
went
through
so
little
intro
work
in
the
release
stage
on
the
progressive
delivery
group.
We
are
in
the
midst
of
doing
a
team
split.
We
will
be
splitting
to
recive
delivery
and
release
management.
We
are
talking
about
doing
that
split
right
now,
so
we're
going
through
the
face
of
that
and
we
talked
today
about
feature
flags
which
you
can
see,
isn't
a
viable
maturity
level
right
now.
A
So
what
is
a
feature
flag?
Not
everybody
knows
what
it
is.
So,
let's,
let's
pause
for
a
minute
and
discuss
what
they
are
so
feature
flag,
is
used
to
hide
or
enable
or
disable
a
feature
during
runtime
the
features
are
hidden
or
sometimes
called
toggle
Dolf,
so
they
don't
appear
in
the
application.
This
allows
many
small,
incremental
versions
of
software
to
be
delivered
without
constant,
branching
and
merging
feature
flags
unless
unlock
faster,
more
agile
work
workflows
by
providing
control
over
the
flexibility
of
deployment
to
specific
environments
and
or
audiences.
A
In
addition,
it
reduces
the
risk
of
reduction
in
the
case
where
a
problem
is
detected.
You
can
just
simply
turn
the
feature
off
not
so
some
common
use
cases
are
targeting
a
specific
environment
targeting
a
specific
audience,
a
lot
of
times
developers
will
check
in
code
or
merge
in
code.
That's
not
complete.
You
don't
want
that
shown
to
front
end
users,
so
you'll
just
hide
it
behind
the
feature
flag
until
it
is
ready
to
be
shown.
A
Looking
this
for
more
of
a
user's
perspective,
there's
lots
of
personas
involved
here.
So
an
example
of
a
job
to
be
done
is
as
a
release.
Manager
I
want
to
be
able
to
control
what
features
are
active
within
my
application,
so
I
can
increase
the
agility
of
my
workflow,
some
other
ones.
Our
developers,
developers
are
often
the
ones
that
are
creating
the
feature.
Flags
QA
engineers
often
have
to
turn
on
and
off
features
as
part
of
their
workflow
release.
A
A
A
Another
factor
to
consider
here
with
feature
flags,
so
while
this
ultimately
will
be
a
customer
facing
feature,
this
is
something
that
we
practice
that
we
use
very
much
it
get
lab,
and
currently
we
are
using
a
solution
called
flipper
that
has
presented
a
number
of
problems
and
there
is
a
ongoing
effort
and
a
lot
of
desire
to
switch
over
to
our
own
solution.
That
is
based
on
unleash,
there's
a
link
to
the
issue
that
is
outlying.
A
That
effort
making
a
switch
so
where
we
have
today
I
so
currently,
like
I
mentioned
before
we're
at
the
Bible
viable
level
of
maturity.
We
have
supported
two
strategies:
percent
rollout
and
user
ivy.
We've
taken
a
very
MVC
approach
to
this,
and
unfortunately
that
MVC
approach
has
both
proved
to
be
a
problem
and
also
a
potential
solution.
A
So
a
problem
is
in
the
sense
that
we
made
a
few
decisions
in
trying
to
implement
the
smallest
possible
feature.
Unfortunately,
in
doing
that,
we
have
introduced
some
some
roadblocks
and
some
user
problems,
so
the
upsides
of
the
MVC
approach
is.
We
are
not
so
far
down
the
road
that
we've
been
able
to
get
some
feedback
from
our
internal
customers.
The
engineers
that
are
working
on
this
and
just
within,
get
lab
itself
and
identify
these
problems
early
on
in
the
process
when
we
can
do
something
about
it.
A
So
out
of
the
discussions
were
on
the
functionality
for
feature
flags
and
some
user
feedbacks
and
some
issues
that
are
being
raised,
that
it
was
became
evident
that
the
current
design
was
not
meeting
user
expectation.
It
was
causing
confusion
and
it
was
probably
going
to
limit
our
future
enhancements.
Some
of
those
key
problems
are,
it
was
not
matching
well
with
the
unleash.
A
So
at
first,
we
attempted
to
just
make
some
small
incremental
changes
see
if
we
could
address
these,
but
we
began
to
realize
this
was
going
to
be
an
uphill
battle
and
implementing
new
features.
Moving
forward
was
going
to
be
a
challenge,
so
we
needed
a
new
plan,
so
we
could
took
kind
of
a
three
pronged
approach.
First,
we
needed
to
get
a
clearer
vision.
A
This
group
that
had
been
together
has
not
been
together
very
long,
both
myself
and
the
product
managers
we
hadn't
worked
together,
so
we
had
yet
to
have
a
deep
dive
kind
of
clear
vision.
Conversation
about
that,
so
that
was
kind
of
step.
One
working
with
the
product
manager
took
a
step
back.
Look
at
the
larger
vision
and
the
competitions
and
see
we
were
wanting
to
go,
there's
a
deep
dive,
video
with
the
product
manager
and
myself-
that's
linked
there
if
you're
interested
in
watching
that
we
also
had
done
very
little
research
in
this.
A
We
didn't
have
a
great
idea
of
our
personas.
What
what
our
users
were
looking
for
out
of
this,
so
we
needed
to
correct
that
so
working
with
the
research
team,
specifically
Laurie,
she
started
conducting
some
user
interviews,
start
helping
us
flush
out
our
personas
and
really
understand
what
our
customers
are
looking
for.
But
then
we
started
to
get
the
idea
that
we
might
need
to
burn
this
thing
down.
A
The
the
unfortunate
scary
like
we
might
need
to
redesign
this
thing,
so
we
went
through
an
exercise
to
do
that
and
we
did
it
in
a
somewhat
unkillable,
a
somewhat
experimental
approach
of
not
thinking
about
making
small
changes,
but
it
said,
let's
just
see
what
we
need
to
do
to
fix
this
thing.
Let's
tackle
all
the
feedback,
all
the
problem,
all
the
usability
concerns.
A
Let's,
let's
look
at
what's
upcoming
and
see
if
we
can
include
that
and
then
we
use
that
not
as
as
a
thing
to
be
built
but
to
drive
a
conversation
of
what
now
now
we
understand
where
we
want
to
go.
Can
we
break
this
down
into
smaller
changes
that
might
actually
be
accomplishable?
So
here's
a
link
to
the
issue
where
that
was
documented,
so
the
new
direction.
So
armed
with
a
new
vision,
it's
user
data,
an
idea
of
what
we
needed
to
be
implemented.
A
Product
management
engineering
myself
were
able
to
break
down
the
monster
redesign
issue
into
and
organize
them
into.
Two
epics
36
issues
were
created
out
of
this
they're,
a
mix
of
foundational
usability,
but
also
features
to
ensure
that
we
continue
to
add
breadth.
We've
scheduled
these
out
over
the
next
2-3
milestones.
A
A
So
these
36
issues
well
a
lot
of
them
had
the
groats
broad,
strokes
of
them
to
find
they're
not
fully
fleshed
out
and
need
to
still
worry
about
the
details,
the
heads
cases-
and
we
still
need
to
do
the
usability
testing
validation
on
those,
so
some
takeaways
from
this
experimental
process
right.
This
proved
to
be
a
very
efficient
way
to
do
it,
tackling
36
in
the
individual
issues
with
much
longer,
but
by
tackling
a
lot
of
these
that
at
the
same
time,
we
were
able
to
produce
context.
A
A
We
were
initially
hesitant
to
do
this
big
redesign.
You
never
want
to
step
back,
and
there
was
a
fear
that
we
would.
We
would
lose
a
lot
of
time
in
this,
and
this
ended
up
not
to
be
the
case
by
removing
the
restrictions
and
thinking
about
the
redesign
we
were
able
to
come
up
with
something
that
actually
was
pretty
close
to
the
original
design.
We
just
need
to
get
to
the
core
root
problems
and
then
turns
out
a
lot
of
the
design
could
be
salvaged.
A
This
is
not
the
kind
of
exercise
that
applies
to
most
of
what
we
do
at
get
lab.
This
was
kind
of
the
perfect
storm
where
we
were
early
on
in
an
MVC.
We
had
identified
some
problems
that
needed
to
be
addressed
and
we
still
had,
and
we
had
a
pretty
good
idea
of
what
was
upcoming
in
the
future.
So
this
type
of
mass
redesign
would
not
be
something
I
would
recommend
applying
to
most
your
work
day.
A
It's
a
key
way
to
address
to
roll
out
a
feature
to
a
specific
user
set.
It's
one
of
the
major
use
cases
of
feature
flags.
Unfortunately,
the
way
we
had
designed
it
it
was,
it
would
require
a
lot
of
rework,
so
you'd
have
to
define
a
list.
Potentially
you
got
ten
feature.
Flags
you'd
have
to
define
that
list.
Ten
times
this
obviously
gets
unmanageable
in
in
large
organizations.
A
If
you
have
hundreds
of
feature
flags
and
large
user
groups,
updating
and
maintaining
that
across
hundreds
of
feature,
flags
would
be
just
a
nightmare,
so
we
introduced
the
idea
of
groups.
So
groups
is
a
new
kind
of
data
set,
allows
you
to
define
the
the
set
of
users
and
an
external
reusable
container,
and
then
you
can
apply
that
container
to
the
feature
flags.
So
this
has
the
benefits
of
avoiding
the
repetition.
It
simplifies
the
user
management.
You
can
change
the
lists
just
one
time
and
it
updates
all
the
feature.
A
Flags
groups
can
now
be
assigned
per
environment,
and
also
this
is
an
example
of
where
the
redesign
helps
lay
the
foundations
for
two
upcoming
features.
The
import/export
&
parametric
generated
lists
are
now
set
up
pretty
easily
by
this,
whereas
the
previous
UI
would
have
been
difficult
to
implement
those
two
things.
The
other
fundamental
shift
was
to
switch
from.
We
were
defining
environments
and
then
adding
strategies
to
them
so
flipping
that
idea
upside
down
and
finding
strategies
and
add
environments
to
them
again.
This
this
aligns
much
more
with
unleash
API.
A
It
was
removed
a
lot
of
the
headaches
that
engineering
was
was
facing
with
our
current
implementation
in
a
worst
case
scenario.
This
this
results
in
the
exact
same
number
of
rules
that
need
to
be
created,
but
more
likely.
In
the
best
case
scenario,
it
will
greatly
reduce
the
number
of
rules
required,
as
you
can
apply
in
multiple
environments
to
a
single
strategy.
A
It
also
helps
to
avoid
the
confusion
of
what
rule
in
one
environment
applies
in
what
situations
by
allowing
you
to
define
multiple
environments
for
a
strategy,
you
kind
of
avoid
the
collisions
of
those
environments,
I
think
that's
all
I
had
one
quick
shout
out
to
the
folks
that
I've
met
since
he
Rory
and
Russia
Nia
Jason
Darby
John.
This
was
not
the
kind
of
effort
that
happened
by
one
person.
This
was
a
group
conversation
and
these
people
were
instrumental
in
that
process.
B
A
So
it's
worth
noting
that
these
users
are
external
to
get
lab,
so
these
are
not
our
groups
that,
like
would
apply
to
your
get
lab
normal
kind
of
groups.
These
these
users
live
outside
of
our
database.
Eventually
we
are
hoping
to
build
in
like
a
LDAP
database
kind
of
integration,
but
right
now
these
are
users
that
live
completely
out
of
our
system,
who
really
have
no
insights
into
that?
So
I'm,
not
sure.
If
that's
answering
your
question,
but
it's
not
the
gitlab
group,
it's
it's
an
external
group
yeah.
C
That
part
I
got,
but
we
have
a
concept
of
groups
already
in
git
lab
whether
it's
forgivable
internal
get
lab
users-
or
you
know
our
broader
wider
get
lab
community.
So
my
question
was
around:
are
we
just
taking
that
same
group
model
that
already
exists
and
now
applying
it
to
feature
flags,
or
is
it
that
we
have
a
groups
concept
within
the
product
that
exists
and
then
the
group's
content
for
feature
flags
is
a
slightly
different
concept,
and
this
by
the
way
is
not
me,
is
starting
an
opinion
on
I.
Don't.
A
I,
just
it's
it's
a
separate
entity
for
feature
flags
which
I
think
will
become
evident
why
it
needs
to
be
that
way.
Once
we
get
into
the
parametric
kind
of
way
where
you
can
define
so
when
I
say
parametric,
that
would
be
a
thing
like
a
user
that
has
been
around
for
30
days
right.
That
might
be
a
way
to
define
a
group
or
a
user
that
is
met
some
criteria
essentially
as
a
way
to
define
groups,
so
they
will
inherently
be
kind
of
a
separate
entity.
I
guess
cool.
C
A
C
B
I
also
want
to
point
out
order.
You
shared
this
in
the
comments
but
like
defining
that
story
and
then
breaking
it
down
like
that
is
the
gitlab
way
right
any.
She
makes
a
great
point
like
no
understanding
that
journey
and
then
getting
to
the
MVC
is
in
walking
it
backwards,
and
you
know
you
did
a
really
good
job
of
that
or
the
team
did
a
really
good
job
of
that.
So.