Named Variant

A named variant is one master component that exposes its differences through named properties the machine can query directly. You build a single Button in Figma then create a property called variant with allowed values of primary, secondary, tertiary, and destructive. You create another property called state with default, hover, focus, disabled, and error. Each combination of those properties maps to a unique set of layers, tokens, and styles. The machine no longer opens five different frames to guess which button is the canonical primary button in hover state. It reads the property values and pulls the exact definition you created. This approach turns every component into a reusable rule set instead of a collection of pictures. In 2026 Figma AI and Claude Design generate from these named variants the same way a code generator pulls from a well typed React component library. The clearer your property names the closer the output stays to your intent. Name them after the decision not the visual result. Intent primary beats color blue every single time the machine makes choices. This structure is the exact legibility layer the machine needs to treat your design system as source code instead of a screenshot.

A named variant is not a pile of duplicate components with slightly different names. It is not having Button, Button Primary, Primary Button Active, Button Hover Final, and Submit Button v3 all living as separate masters in your file. That approach forces every AI tool to play detective with your mess. It is not a set of auto layout frames you grouped together and called a component without defining the actual properties. The machine cannot read your mind or your layer hierarchy if you have not spelled out the variants. It is not a component you detached and modified for one screen then left in the file as a quiet contradiction. Every detached instance becomes another competing rule the AI will follow with confidence. The result is generated screens that look like your design system at first glance but break every rule when inspected closely. Five visually similar buttons that live in five different components create five competing sources of truth and the machine will use all five in the same flow.

The clearest concrete example lives in Shopify Polaris. Their 2025 component catalog uses one Button master with four named variants for the main styles and five explicit states for interaction. A designer sets the properties and every instance stays connected to the source of truth. No more hunting for the right version across 12 symbols. No more updating the same change in seven places. Material Design 3 takes this further with their tiered token system feeding directly into named component variants for filled, outlined, tonal, text, and elevated buttons. When Google released their updated AI design tools in 2025 those tools performed dramatically better on Material files than on typical agency files because the named variants created perfect resolution paths with zero guesswork. A mid sized SaaS company copied this approach in Q3 2024. They audited their Figma file and found 14 competing button styles plus 23 input variations. After two days of work they reduced everything to single masters with named variants. Their first test with Claude Design produced a full user onboarding flow that required only 20 percent manual cleanup instead of the usual 80 percent. The named variants did not make the AI smarter. They simply stopped it from guessing wrong.

A second example comes from a banking app redesign in early 2025. The team started with 29 variations of their form components. Text inputs had six different border treatments. Error states were drawn as separate overlays instead of variants. The AI prototype tool kept generating forms with inconsistent error styling, mixed input sizes on the same screen, and hardcoded red values that ignored their danger token. After the team invested one week to create named variants for size, type, and state the output quality jumped. The machine began pulling the exact error state variant with the red border token and correct helper text every time. Similar results appeared at teams using Atlassian Design System and GitHub Primer. Their named variant approach for navigation items, buttons, and cards allowed internal AI tools to generate entire flows that matched the system without human correction in most cases. These stories repeat across teams that ship real products. The ones winning with AI in 2026 share one trait. Their components speak clearly through named variants instead of forcing the machine to interpret visual noise.

Use named variants on every element that repeats or changes state in your interface. Start with the highest traffic components. Button, input, select, card, navigation link, toggle, accordion. Define properties using intent language your team already understands. Status success instead of variant green. Size compact instead of height 32. This language survives across tools and handoffs to developers. Add every interactive state as an explicit variant even if you think it looks obvious from the mockup. The machine does not understand obvious. It understands defined properties. Do this before you have more than 50 screens in your file. Cleanup becomes exponentially harder after that point because detached instances multiply. This directly supports machine readable design systems. Without named variants your components are not legible to the machine and it will treat every slight difference as a new rule. That is how you end up with AI generating seven shades of your primary color because it saw seven slightly different buttons. Named variants close that door. They force consistency at the structural level where it matters most to the machine. Convert components to named variants before pointing any AI tool at your file.

Avoid named variants during pure ideation sketches or for unique visual elements that appear once. A custom hero illustration for a landing page does not need variant properties. A one off dashboard widget you are testing also does not benefit. The overhead adds nothing when the element has no siblings. Do not create fake variants just to check a box. If an element truly has only one state then a simple component without properties works fine. The danger comes when you treat everything as a one off and then suddenly ask AI to generate from that collection of contradictions. At that point the machine accelerates the exact mess you avoided cleaning up. The rule is simple. If it repeats or if it has states then give it named variants before the AI ever sees it. You can select multiple similar components in Figma and use the combine variants feature to turn them into one master with properties. The tool even suggests some property names based on your existing layer names. Use that as a starting point then clean up the names to reflect intent rather than description.

Named variants replace interpretation with declaration and that single change decides whether AI multiplies your quality or your debt.