Figma's Opacity Variables Fix a Small Design-System Pain

Opacity has spent years living in the slightly embarrassing gap between a design token and a designer’s local adjustment. A color belongs in the library, but the 40% version for a disabled button, a scrim, or a soft overlay often gets applied by hand. That works until the color changes, the component multiplies, or someone asks why the dark theme looks like it was assembled during a fire drill.

Figma’s new “Control opacity at scale” update addresses that gap. You can apply opacity on top of a color without detaching the color variable, alias opacity separately, and use a number variable for the opacity value. It’s a small feature with a fairly large consequence for teams that maintain shared libraries: transparency can become part of the system instead of a collection of charmingly inconsistent exceptions.

What changed in Figma

Previously, a designer who wanted to use an aliased color at a different opacity had an awkward choice. Detach the color and lose the library connection, or create another color variable for every possible alpha value. Neither option is attractive when a product has multiple themes, brands, or product surfaces. The new workflow lets the base color stay linked while opacity is controlled independently.

Figma describes three useful paths in its release note:

• Alias opacity while keeping the color connected to the library.
• Set a color variable’s opacity with a number variable, with scope for color variables.
• Update opacity across disabled states, overlays, scrims, and similar patterns from the variables modal.

The Figma variables documentation adds an important implementation detail: number variables can apply to opacity on color variables and layers, and values below 0 or above 100 are clamped to the valid range. That guardrail is useful, although it shouldn’t become an excuse to name a token “opacity-ish-final-2.”

Why design-system teams should care

Opacity is usually treated as decoration, but it often carries meaning. A disabled control, a modal scrim, a selected row, and a muted icon are all communicating state. When their values are scattered across component files, the system becomes difficult to audit. One designer uses 40%, another uses 48%, and a third has a gray fill that looks similar until it lands on a different background.

Separating color from opacity gives the system two clearer responsibilities. Color variables describe the visual identity or semantic role. Number variables describe intensity. That division makes a token easier to reuse, compare, and adjust. It also gives design leads a better question to ask in review: is this opacity part of the component’s meaning, or is it a one-off visual treatment?

A practical naming scheme might include opacity.disabled, opacity.scrim, opacity.muted, and opacity.selected. The exact names depend on your system, but semantic names are preferable to a shelf full of unexplained percentages. If the product team later decides that disabled content needs more contrast, one token can move instead of a search-and-replace expedition through every file.

Three ways to use the update

1. Keep primitive colors primitive

Start with your base palette and resist creating duplicate colors for every alpha step. A neutral surface should remain a neutral surface. Apply a separate opacity variable when a component needs a translucent treatment. This preserves the relationship between the semantic color and the underlying primitive, which matters when the brand palette changes or a light theme becomes a dark theme.

2. Turn states into recipes

Document the combination of color, opacity, and background for common states. A disabled button might use a semantic text color plus a disabled opacity, while a scrim might use an overlay color plus a scrim opacity. The recipe belongs with the component guidance, not only in a designer’s memory. If engineers consume tokens through a handoff or code workflow, make sure the opacity token travels with the semantic role instead of arriving as an unexplained decimal.

3. Treat overlays as a system

Scrims, selection fills, hover treatments, and focus-adjacent highlights tend to proliferate because they’re easy to add and hard to police. Create a short approved scale, then test it against the surfaces where it will actually appear. A value that looks restrained on white can become a dense gray over a photograph. The variable makes the adjustment faster, but it doesn’t make the judgment optional.

A sensible rollout plan

Don’t convert every existing color variable on a Friday afternoon. Pick one component family with several opacity-based states, such as menus, data tables, or form controls. Inventory the current values, group them by meaning, and decide which ones deserve semantic tokens. Then build a small test file with light and dark modes, real content, and the backgrounds your product actually uses.

1. Create a number-variable collection for approved opacity values or semantic state tokens.
2. Apply the number variables to color variables and layers while keeping the base colors aliased.
3. Compare the result across themes, surfaces, and component states.
4. Record the intended use, range, and accessibility caveats in the design-system documentation.
5. Ask engineering to confirm how the tokens map to production code before expanding the pattern.

Keep an eye on accessibility while you test. The W3C guidance for WCAG contrast says normal text generally needs a contrast ratio of at least 4.5:1, with different thresholds for large text and certain exceptions. Opacity changes the final color seen against a background, so checking the source color alone isn’t enough. Test the composited result, especially for muted text, icons that convey status, and controls that users need to identify quickly.

Where AI fits, and where it doesn’t

AI can help a team explore the context around a token. For example, pixelbrief.ai can generate an AI-powered design brief or image direction for a campaign, which gives the team realistic surfaces to test overlays and translucent treatments against. It shouldn’t decide the final opacity scale. That decision depends on contrast, hierarchy, platform behavior, and the wonderfully stubborn fact that people have to read the interface.

The small fix is the point

Figma’s opacity update won’t make for a dramatic conference headline, and that’s probably healthy. Design systems improve through the removal of repeated friction. Keeping color aliases intact removes one source of token sprawl, while number variables give teams a clearer way to describe intensity across components and themes.

Start with one state-heavy component, test the composited colors, and publish the rules with the library. If the pattern survives a real product surface and a real handoff, expand it. The best result is a system where transparency has a name, a purpose, and a responsible owner, rather than a mystery percentage hiding in a panel.

Further reading: Figma product release notes, Figma’s variables, collections, and modes guide, and the W3C contrast guidance.