Component Feature Flags: Opt-in to Breaking Changes
Component feature flags are a temporary opt-in switch for new versions, letting you adopt breaking changes before a major release. Design systems use them to roll out updates without forcing an immediate migration.
Why it exists
Major version upgrades of a design system can be painful, requiring teams to update dozens of components at once in a risky, all-or-nothing migration. Component feature flags were created to de-risk this process by allowing for a gradual, controlled rollout of breaking changes.
The mental model
Think of a feature flag in a design system as a temporary toggle switch built into a component. By default, it's "off," showing you the old, stable version. Flipping it "on" reveals the new, upcoming version. This lets you test drive the future without leaving the current stable release.
How it works
When a design system prepares a new major version, it introduces flags for components with breaking changes. These flags are off by default for backward compatibility. In a design tool, it's a boolean property in the component's panel. In code, it's a configuration setting for the framework (e.g., React). When the next major version is released, the flags are removed, and the new behavior becomes the one and only default.
When to use it
As a consumer of a design system, use these flags to get ahead of a major migration. Your team can incrementally adopt new component APIs or visual styles on your own timeline, turning the flags on one by one. This is a proactive way to manage upgrade debt and reduce the workload of the final migration.
When not to use it
Do not use these flags as a permanent configuration option. They are temporary migration aids. If you need a permanent variation of a component, that should be a standard component property or a separate component altogether. Do not keep flags enabled long after the new major version has been released; at that point, you should migrate fully.
One canonical example
IBM's Carbon Design System uses flags for its v12 release. A component like Modal has a v12 flag. In a design file, a designer toggles this boolean property on a Modal instance to see the v12 design. In code, a developer enables the flag in their React setup to get the new component behavior, all while their project is still on Carbon v11.
Interview question
What is the primary purpose of component feature flags within a design system?
- a.To facilitate a gradual, controlled adoption of breaking changes before a major design system release.Correct
- b.To allow developers to dynamically switch between different design systems in a single application.
- c.To offer permanent, configurable variations for components based on project needs.
- d.To enable A/B testing of new component designs with a subset of end-users.
Why? this is the answer
The card explicitly states that component feature flags were created to "de-risk this process by allowing for a gradual, controlled rollout of breaking changes" before a major release. Option C is incorrect as the card warns against using flags as permanent configuration options.
Just read this? Test yourself on what you have been reading.
Read the original → carbondesignsystem.com
- #design systems
- #feature flags
- #versioning
- #frontend
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design systems — each one lists the topics its interview covers.
See open roles