Stealth-mode North Star: Rebranding in secret with feature flags

A presentation at reactJSday 2021 by Kathleen McMahon

https://noti.st/resource11
For those who like to follow along as I talk, my presentation is posted on Notist, that’s https://noti.st/resource11.

@resource11 Twitter | Instagram | GitHub
You can follow me at resource11 on Twitter, Instagram, and GitHub.
Let’s back up so I can introduce myself better…

Kathleen McMahon | Engineer • Designer • Speaker
So I’m an engineer and a designer and I like to speak about things…

[image] Me on a cyclocross bike, hopping over barriers and riding through mud.
And… I race bikes. Very badly.

[image] Me on a cyclocross bike, in Spam, Ninja Turtle, Nerds candy box, Medusa costumes
Mostly you’ll see me in costume, racing two laps to your six, at the back of the pack, on a singlespeed, — with a bunch of onlookers in the crowd laughing at me, toasting with their beverages.

UX Next
So while I’m an engineer, designer, and speaker, I’m a design engineer on the UX Next team at LaunchDarkly
Our team enables other designers and engineers to craft high quality experiences for our customers.

Maturing our design system
Part of our work includes maturing the design system.

If you’ve ever worked on a design system, you know there are a lot of things to consider.

[image] woman attempting to arrange 10 squirming kittens in a straight line, with varied success
Similar to herding kittens, maturing a great design system can be tough with so many moving parts.
If your squad is small, you have to be very strategic. Especially when your product roadmap changes. For example…

Hello… brand refresh.

What happens if you find out the creative team has refreshed the brand?

[image] Collection of LaunchDarkly brand assets

And your team is presented an updated brand North Star?

That’s definitely a Surprise Pikachu moment…

What is a brand North Star?

You may ask… what is a brand North Star?

“Your brand's North star is the promise that you are making to your customers.” — M81 Creative

There is this article by M81 Creative that gives a great explanation of North star:

“Your brand’s North star is the promise that you are making to your customers.”

https://www.m81creative.com/blog/what-is-your-brands-north-star

LaunchDarkly’s North Star is brought through in their core message:
Software powers the world. LaunchDarkly empowers all teams to deliver and control their software.

[image] Collection of LaunchDarkly brand assets

We lean into this mission with our colors, typography and signature logo.

Even the position of our logo mark, to the right of the logo type embodies our core beliefs:. In a world where every company is a software company, LaunchDarkly leads the way and saves the day.

Creating a strong brand takes time

Creating a brand North Star takes time to do right.

You have to do things like strategy competitive analysis, users and customers insights, creative explorations.

This process takes up to many months, sometimes up to a year.

And once that is done, you will have some key outputs like logos, colors, typography and such…

Creating a strong brand takes time

Once that North Star is established, it’s time for teams to go to work to roll those branding visuals into the marketing site and the product app.

This is where it gets tricky. While our team was informed about the brand refresh at the earliest possible moment, we had one wrinkle. And it’s a big one.

The time to the rebrand rollout to our customers is in 13 weeks

That means the time to internal rollout to our our teams is 10 weeks

[image] Ross from Friends repeatedly yells "pivot!" as Rachel and he maneuver a large chair up an awkward staircase.
So we had to pivot to figure out how to get things done, because of the inherent differences between a marketing site update and a product app.

[image] LaunchDarkly marketing site in 2014
If you look at our marketing site over the years, visual refreshes happen more often

[image] LaunchDarkly marketing site in 2015
If you look at our marketing site over the years, visual refreshes happen more often

[image] LaunchDarkly marketing site in 2018
If you look at our marketing site over the years, visual refreshes happen more often

[image] LaunchDarkly marketing site in 2019
If you look at our marketing site over the years, visual refreshes happen more often

[image] LaunchDarkly marketing site in 2020
If you look at our marketing site over the years, visual refreshes happen more often

[image] LaunchDarkly marketing site in 2021
If you look at our marketing site over the years, visual refreshes happen more often

Product visual refresh: less often
On the other hand, visual refreshes happen less often in the product app because…

…a rebrand impact established product roadmaps.

Outdated product visuals break brand promises

And you need to be careful when the visuals between your marketing site and product app gets out of sync. First, your product APP will start looking outdated and Second, outdated app visuals breaks your brand promise.

[image] Mars Babycat sleepily squints amid a cozy comforter
So our team regrouped and thought… how can we get this done?

[image] Shrimp and lime jello mold, plated with apple slices
Making dishes that include jello and shellfish.
It’s just just not a good look.
Thankfully, we work at a company that has a really cool product.

[image] Three baby raccoons nestled inside a tree trunk
We could set up a flagging structure and…

[image] Three baby raccoons nestled inside a tree trunk... with a calico cat disguising themself as a sibling
Rebrand in stealth mode.
We could make all of our changes alongside other teams, not disrupt other squads roadmaps…
All while the other product squads are not aware that the brand refresh was happing in the product.

How did we use flags?
So what did we use flags for in this case?

Well, we used them to control theming, data attributes, fonts, design tokens, HTML templates, and UI updates.

And! Since we had to do it all in 10 weeks…

[image] The Ruling Ring of Isildur's Bane
We used this one ring…

One flag to rule them all
One flag as the basis of most of our changes, and used it as a prerequisite for any other flags we needed for testing out additional features in isolation.

Feature Flag: enable-2021-rebrand
The flag that all our other flags were dependent upon was the enable-2021-rebrand flag

[image] Enable 2021 rebrand flag targeting view
This flag was a prerequisite for other flags.

Data attributes: data-theme=“osmo" data-theme=“legacy”
……to control whichever theme we wanted to serve up.

New font family: Inter
But we also wanted to use our new font, Inter, in our visual refresh so…

[image] Enable Inter flag targeting view
We added the enable-inter flag inter with the rebrand flag as a prerequisite…

Data attributes: data-theme=“osmo" data-theme=“legacy" data-inter=“true”
And added it to our set of data attributes for theming.

We paired those data attribute values with React Context…

And hooks…
import { createContext, ReactNode, useContext, useEffect, useMemo } from ‘react’;
type Theme = ‘legacy’ | ‘osmo’;
export type ThemeContext = { theme: Theme; };
export const ThemeContext = createContext<ThemeContext>(null as unknown as ThemeContext);
export function ThemeProvider({ isInterEnabled, theme, children, }: { isInterEnabled: boolean; theme: Theme; children: ReactNode; }) {
useEffect(() => { document.documentElement.setAttribute(‘data-theme’, theme); }, [theme]);
useEffect(() => { if (isInterEnabled) { document.documentElement.setAttribute(‘data-inter’, ‘true’); } else { document.documentElement.removeAttribute(‘data-inter’); } }, [isInterEnabled]);
const contextValue = useMemo( () => ({ theme, }), [theme], );
return <ThemeContext.Provider value={contextValue}>{children}</ThemeContext.Provider>; }
export function useTheme() { return useContext(ThemeContext); }

…to create a theme context
type Theme = ‘legacy’ | ‘osmo’;
export type ThemeContext = { theme: Theme; };
export const ThemeContext = createContext<ThemeContext>null as unknown as ThemeContext);

and a theme provider that we could use anywhere we need in our app,
export function ThemeProvider({ isInterEnabled, theme, children, }: { isInterEnabled: boolean; theme: Theme; children: ReactNode; }) {
const contextValue = useMemo( () => ({ theme, }), [theme], );
return <ThemeContext.Provider value={contextValue}>{children}</ThemeContext.Provider>; }

We created this useTheme function for wherever we wanted use a theme.
export function useTheme() { return useContext(ThemeContext); }

And used our theme provider in the app entry point, leveraging our rebrand flag value to set the theme
const theme = is2021RebrandEnabled() ? ‘osmo’ : ‘legacy’;
ReactDOM.render( <Provider store={store}> <ThemeProvider theme={theme} isInterEnabled={isInterEnabled()}> <HelmetProvider> <Router history={history}> {content} </Router> </HelmetProvider> </ThemeProvider> </Provider>, container, );

And pass the theme into the provider
<ThemeProvider theme={theme} isInterEnabled={isInterEnabled()}>

Which uses the useEffect hooks to set data attributes in the root element of our app.
export function ThemeProvider({ isInterEnabled, theme, children, }: { … }) {
useEffect(() => { document.documentElement.setAttribute(‘data-theme’, theme); }, [theme]);
useEffect(() => { if (isInterEnabled) { document.documentElement.setAttribute(‘data-inter’, ‘true’); } else { document.documentElement.removeAttribute(‘data-inter’); } }, [isInterEnabled]);
return <ThemeContext.Provider value={contextValue}>{children}</ThemeContext.Provider>; }

Design tokens. Before the North Star was revealed, our team was already refactoring our token architecture.
Once this rebrand was announced, we had to adjust our tokens work without losing any of our progress.

Design Tokens are an abstraction for everything impacting the visual design of an app/platform. — Sönke Rohde
If you’ve never heard of design tokens, Sönke Rohde Tweeted a great definition: Design Tokens are an abstraction for everything impacting the visual design of an app or platform

Design Tokens are design decisions propagated through a system. — Nathan Curtis
In other words, design tokens are design decisions propagated through a system.

Base tokens —color-blue-500: hsl(231.5, 100%, 62.5%);
Semantic tokens —focus-color: var(—color-blue-500);
Component tokens —Button-color-text-focus: var(—color-blue-500);
Generally tokens span three categories:
Base, the raw values.
Semantic, aliased to base values and shared across the application, and component.

Blended base + semantic tokens
Our legacy token system was a blend of base and semantic…
Blended base + semantic tokens —primary-green-base: hsl(165.1, 72.5%, 45.7%);

Not Scalable
…so it wasn’t scalable, due to the naming conventions used.
It didn’t make sense to have a color name in a semantic token if our primary color changed. Hence the refactor.
Considering the 10-week time frame…The tokens that we were most concerned about were our application-level tokens.

We chose to focus on using the data attribute to map our application-level tokens to base tokens in either the legacy or osmo theme.
Since our theme was controlled by a flag, we could target the data attributes in our CSS…
:root { —primary-color: var(—primary-green-safe); }
:root[data-theme=’osmo’] { —primary-color: var(—color-blue-500); }

…And change values by adjusting the data attribute
We used this 1:1 mapping of our values and tested our rebrand by toggling on our flag.
This was especially helpful because we could introduce a new set of semantic tokens quickly without much fuss.
:root { —primary-color: var(—primary-green-safe); }
:root[data-theme=’osmo’] { —primary-color: var(—color-blue-500); }

Now, we could have a separate set of base tokens…
:root { —color-error-dark: var(—danger-red-dark); —color-error-base: var(—danger-red-base); —color-info-base: var(—info-blue-base); —color-warning-base: var(—alert-orange-base); —color-success-base: var(—primary-green-base);
`--focus-color: var(--info-blue-safe); --primary-color: var(--primary-green-safe); --text-color: var(--gray-black); --text-color-danger: var(--danger-red-dark);`
}

Then we could create a new set of application-level tokens…
:root { —color-error-dark: var(—danger-red-dark); —color-error-base: var(—danger-red-base); —color-info-base: var(—info-blue-base); —color-warning-base: var(—alert-orange-base); —color-success-base: var(—primary-green-base);
`--focus-color: var(--info-blue-safe); --primary-color: var(--primary-green-safe); --text-color: var(--gray-black); --text-color-danger: var(--danger-red-dark);`
}

And change values by adjusting the data attribute
By leveraging those data attributes through feature flagging, we could test out our new token values in the app at runtime, without impacting any of the other teams’ work.
:root[data-theme=’osmo’]
:root[data-theme=’osmo’] { —color-error-dark: var(—color-system-red-600); —color-error-base: var(—color-system-red-400) —color-info-base: var(—color-blue-400); —color-warning-base: var(—color-system-yellow-500); —color-success-base: var(—color-system-green-600);
—focus-color: var(—color-blue-500); —primary-color: var(—color-blue-500); —text-color: var(—color-black-300); —text-color-danger: var(—color-system-red-600); }

Including re-mapping tokens for our font family, test, adjust values quickly
:root[data-inter=’true’]
:root[data-theme=’osmo’]

And set up some component tokens
:root { —Button-color-background-primary: var(—color-success-safe); —Button-color-background-primary-hover: var(—color-success-dark); —Button-color-background-primary-focus: var(—color-success-dark); —Button-color-background-primary-active: var(—color-success-dark);
—Button-color-border-primary: var(—color-success-dark); —Button-color-border-primary-hover: var(—color-success-dark); —Button-color-border-primary-focus: var(—color-success-dark); —Button-color-border-primary-active: var(—color-success-dark);
—Button-color-text-primary: var(—white); }

To theme and streamline our CSS
Even better, we could use this data attribute to wrap blocks of CSS code, and when it’s time to remove legacy styles, we can quickly remove blocks of code later on.
:root[data-theme=’osmo’] { —Button-color-background-primary: var(—color-blue-500); —Button-color-background-primary-hover: var(—color-blue-600); —Button-color-background-primary-focus: var(—color-blue-700); —Button-color-background-primary-active: var(—color-blue-700);
—Button-color-border-primary: var(—color-blue-500); —Button-color-border-primary-hover: var(—color-blue-600); —Button-color-border-primary-focus: var(—color-blue-700); —Button-color-border-primary-active: var(—color-blue-700);
—Button-color-text-primary: var(—white); }

Performance optimizations
We also used flags in other ways for performance optimizations

we used the Go SDK and Go templates on the back end to bootstrap our flag data into our HTML templates to give us just enough information to render our pages.

And used the enable-2021-rebrand feature flag to set the data-theme attribute as a performance optimization.
This way, we could have the HTML templates check for this flag and render the correct theme while we wait for the JavaScript to load and initialize the HTML, to avoid a flash of incorrectly-styled content
{{% if ._flags.Enable2021Rebrand %}}
<html lang=”en” data-theme=”osmo”> {{% else %}} <html lang=”en” data-theme=”legacy”> {{% end %}}

We also used the enable-inter flag value preload this variable font only if the flag was on.
This way, our app performance wouldn’t take a hit from loading any unnecessary fonts if the flag was off.
{{% if ._flags.Enable2021Rebrand %}}
<html lang=”en” data-theme=”osmo”> {{% else %}} <html lang=”en” data-theme=”legacy”> {{% end %}}

Left nav
We used feature flags to control whether we would show/hide content in our left nav

For example, if our rebrand flag was off
import { forwardRef, Ref } from ‘react’; import { useTheme } from ‘theme’;
export function AppNavItem({ className, name, icon, href, itemRef, …other }: AppNavItemProps) {
const { theme } = useTheme();
const navItem = React.createElement( ‘a’, { className: classes, href, …other, ref: itemRef }, [ theme === ‘legacy’ && icon && React.cloneElement(icon, { key: ‘icon’, className: ‘AppNav-itemIcon’, ‘aria-hidden’: true }), <span className=”AppNav-itemText” key=”name”> <span className=”AppNav-itemName”>{name}</span> </span> ], );
return navItem; }
export default forwardRef<Element, AppNavItemProps>((props, ref) => <AppNavItem {…props} itemRef={ref} />);

…the legacy theme would be true, and we’d show icons in the left nav
const { theme } = useTheme();
const navItem = React.createElement( ‘a’, { className: classes, href, …other, ref: itemRef }, [ theme === ‘legacy’ && icon && React.cloneElement(icon, { key: ‘icon’, className: ‘AppNav-itemIcon’, ‘aria-hidden’: true }), <span className=”AppNav-itemText” key=”name”> <span className=”AppNav-itemName”>{name}</span> </span> ], );
return navItem; }

[image] LaunchDarkly left nav in legacy view
So our users would have the expected UI experience

[image] LaunchDarkly left nav in rebranded view
While we worked on the rebranded nav in secret

[image] LaunchDarkly legacy view without top nav
We didn’t have a top nav before…

[image] LaunchDarkly rebranced view with top nav
…and now we do.

[image] Topbar Spike feature flag targeting view
By adding the topbar-spike flag

We could add the top nav into the rebranded UI by turning on the topbar-spike flag.
import classNames from ‘classnames’; import { useTheme } from ‘theme’; import Topbar from ‘components/Topbar/Topbar’; import ‘stylesheets/components/App’;
export const App = ({ className, children, isTopbarSpikeEnabled, }: AppProps) => { const classes = classNames(‘App’, className, { ‘App—with-top-bar’: isTopbarSpikeEnabled, }); const { theme } = useTheme();
return ( <div className={classes}> <SkipToContent /> {isTopbarSpikeEnabled && <Topbar />} <AppNavContainer theme={theme} isTopbarSpikeEnabled={isTopbarSpikeEnabled} /> <main className={classNames(‘App-main’, { ‘App-main-with-topbar’: isTopbarSpikeEnabled })} id=”content” > {children} </main> </div> ); };
export default App;

Since this flag was dependent on the enable-2021-rebrand flag, we could test this in isolation.
const classes = classNames(‘App’, className, { ‘App—with-top-bar’: isTopbarSpikeEnabled, });
return ( <div className={classes}> <SkipToContent /> {isTopbarSpikeEnabled && <Topbar />} <AppNavContainer isTopbarSpikeEnabled={isTopbarSpikeEnabled} /> <main id=”content”> {children} </main> </div> ); };

[image] LaunchDarkly Switch environment dropdown view
Environment Switcher
With LaunchDarkly, whenever you create a new project you get two default environments, production and test, and they are set specific colors by default.

[image] Rebrand Env Colors flag targeting view
We wanted to test out new default environment colors, so created the rebrand-env-colors multivariate flag

[image] Rebrand Env Colors flag variations view
…and use blocks on JSON in our variations to test out color combinations on the fly.

And used Go to store the values.
if post.Environments == nil { colors := accounts.EnvironmentColors{} if err := json.Unmarshal(ctx.Flags.EnableRebrandEnvColors(), &colors); err != nil { return err } envs = accounts.MakeDefaultEnvironments(“”, colors)

Lastly… Favicons. It’s always a nice touch to have your favicon ready to go when you rollout your rebrand rather than scrambling to update at the last moment.
Especially if you are using them in more than one environment.

[image] Favicon Env variations flag targeting view
By adding the favicons-env-variations multivariate flag

[image] Favicon Env variations flag variations view
We could use strings in our variations…

And serve up whichever favicon version we needed, depending on the environment, in our HTML template.
{{% if ._flags.Enable2021Rebrand %}} <link rel=”icon” type=”image/svg+xml” href=”{{% ./img/{{% ._flags.FaviconEnvVariations %}}.svg”> <link rel=”icon” type=”image/png” href=”{{% ./img/{{% ._flags.FaviconEnvVariations %}}.png”> {{% else %}} <link rel=”icon” type=”image/png” href=”{{% ./img/{{% ._favicon %}}” /> <link rel=”mask-icon” href=”{{% ./img/mask-icon.svg” color=”#055177” /> {{% end %}}

We could implement a substantial amount of changes to our product…

Link for this presentation:

HTML code for embedding:

<p data-notist="resource11/yKCLsK">View <a href="https://noti.st/resource11/yKCLsK">Stealth-mode North Star: Rebranding in secret with feature flags</a> on Notist.</p><script async src="https://on.notist.cloud/embed/002.js"></script>

Share on social media:

Kathleen McMahon
@resource11

1 / 113

Great products combine valuable features with strong branding to a target audience. Defining your brand’s North Star is the key to delivering the standards of that promise to your customers in a compelling — and memorable way.

Occasionally though, your visual brand is redefined and you need to course-correct your UI to align with a new direction, while the rest of your team is meeting their own product goals. However! What if details of the rebrand are not widely shared within your organization? How do you get that rebrand in without sharing the details until it’s time?

In this talk, we’ll take a look at how you can use feature flags to roll out an updated UI in stealth mode — without impacting the work or velocity of your fellow teammates.

Stealth-mode North Star: Rebranding in secret with feature flags