Feature flags are triggers that you code into prototypes. You have both the control & variant coded in your live store. The variant is turned off and the control is turned on. In your experiment, you write some code that turns the variant on and the control off. That’s the whole experiment.

Feature flags can be used pretty much anywhere, but in practice they’re best for triggering dynamic functionality or more complex prototypes. Let’s explore a ridiculously simple feature flag that you would never put into place in practice, and then let’s fan it out and talk about how to work with them.

The boringest example: your headline

The easiest way to show how a feature flag would work is in the place where you’d be least likely to do it: your headline.

Normally, you’d swap your headline out in your experimentation framework. This takes 1 line of code in practice. Let’s do it with a feature flag for the heck of it!

Here, you have two H1s with one hidden:

<header> <h1 class="control">Welcome to Our Store</h1> <h1 class="variant">Our Store Solves All of Your Problems</h1> </header> <style type="text/css">.variant { display: none; }</style>

And in your variant, you write a tiny bit of CSS that swaps them out:

<style type="text/css"> .variant { display: block !important; } .control { display: none; } </style>

That’s it. You just created a feature flag.

CSS isn’t the only way

Feature flags are usually implemented in one of three different ways:

• CSS. Usually this manifests in the form of visibility: hidden or display: none.
• JavaScript. In practice, this is mostly jQuery hide() and show().
• GET queries. This works great when you need to run page redirect tests, such that the new page has a GET query that triggers the variant. For example, when your page is example.com, the variant could be example.com/?variant=true. You pull the GET query using your templating language or JavaScript and trigger the variant that way.

Applications for feature flags

If that riveting hello-worldy headline swap didn’t get you excited to spray feature flags all over the place, let’s talk about some more realistic examples of feature flags:

• Cart & PDP upsells. Leave them hidden by default, un-hide. Or swap one for another.
• Filtering & sorting mechanisms. If you have large product databases and get enough qualified traffic going through collection pages, it might be worth wildcarding your collection page experiments and using feature flags to hide & un-hide different sets of filtering or sorting mechanisms.
• Nav, especially mobile nav. If you’re creating a whole new prototype of navigation, it’s probably worth building your nav twice and hiding one by default.

Generally speaking, any sort of dynamic functionality or experiment URL wildcarding is well-suited to feature flags.

← Back to the Blog Check Out Draft’s Store →