A step-by-step guide to an agent-ready design system

For the Figma agent to produce designs that look and feel like your product, it needs a design system it can understand, thoughtful component design, consistent naming conventions, and descriptive documentation, then layering on guidance for agents with examples, guidelines, and skills. Let's dive into some best practices that will pay off for your teammates and their agents. First, audit and refine the components you already have. Well-designed components teach the agent how to use them by building in information about their purpose, structure, and behavior into the design itself. Here are a few improvements you can make. Start with meaningful layer names. Descriptive and consistent layer names give the agent valuable information about a component structure. For example, card footer gives the agent much more information than frame 437. If you're running short on time, you can use the agent to rename layers in bulk. It analyzes the layer's content and surrounding context and applies a descriptive name. Next, check how your components resize. When you resize a component on the canvas, it should accurately reflect that component's responsive behavior. Use auto layout or constraint settings to make sure that your components resize correctly. That way, when the agent uses your components at different sizes, they'll work the way you expect. The agent can help you evaluate the responsive behavior of your components. Just ask it to lay them out at different sizes so you can easily scan for and fix any issues. It's also important to set up component properties for each component. Component properties show the agent which aspects of a component are customizable and which should stay fixed. Be sure to configure them for each customizable aspect of your component. You can also use the Figma agent to audit your components and suggest properties priorities you may have missed. Some properties include settings that give the agent more specific information. For example, including a slot in your component tells the agent that it includes a free-form content area. Then, preferred instances and the slot's description tell the agent what belongs inside. Let's talk about variants. Use them to represent things like style or state variations, like a primary and secondary button, not structural differences, like two completely different card layouts. If an option has a significantly different structure or purpose, it may be better as a separate component. In general, it's also best to keep the number of variants to a minimum and rely on component properties instead. This helps keep each component's purpose clear and focused, making it easier for the agent to understand what it's for and when to use it. Lastly, be sure to include a brief overview of the component and how it should be used in the component's description. You can also include any aliases that may help people and agents find the right component when searching other terms. This gives the agent more context about what each component is for, so it can choose the right one. If you've already got your component descriptions on the canvas, consider using the agent to easily add all that same info to the component descriptions. You can also ask it to provide keywords and aliases for each. Now that we've covered components, let's take a look at styles and variables. When the agent composes layouts using your system, it reaches for your styles and variables to define how components are arranged together and sometimes create entirely new layouts. Make sure every color, spacing value, corner radius, and text style in your system maps to a style or variable, and use them consistently in your components. That way, the agent can draw from your system when creating layouts, instead of making those design decisions from scratch. If you don't have a variable system yet, ask the agent to create one from your existing designs. It can identify recurring values and organize them into variables, saving you time on setup. Semantic naming conventions help the agent understand how to use variables, component properties, and variants. As a general rule, choose names based on what something does, not what it looks like. For example, when naming variables, BGWhite describes a color, but BGPrimary describes its purpose. Or for component variants, BlackButton and GrayButton provide less context than PrimaryButton and SecondaryButton. Both naming conventions point to the same value, but only the latter carries information on how to use it, which helps the agent produce more consistent results. Consistency is key. Choose your conventions and stick with them. The Figma agent can help audit and improve your naming conventions. You can use it to propose naming conventions based on your existing system and apply them in bulk. If you already have a naming system, the agent can suggest improvements. You might ask it to flag any names that describe appearance instead of purpose or find inconsistencies like muted in one place and subtle in another. Once the foundations are in place, you can layer on tailored guidance for the agent. Chances are your team has already created some polished designs using your design system. You can include these examples in your library file to help the agent understand how your system comes together to create cohesive designs. Just turn each design into a component and add them to a page called examples or add the underscore example suffix to each component name. Then publish them with your library and the agent can reference them as best practices for future outputs. Guidelines add additional instructions for agents to your library. You can include things like do's and don'ts, common mistakes, and other guidance that will help the agent navigate ambiguous decisions. When someone uses the agent with your library attached, the agent will automatically refer to its guidelines for decision making. Skills help agents handle recurring tasks like accessibility audits, component migrations, or design QA consistently. They give the agent a clear process to follow, including things like questions to ask before starting, rules for edge cases, and what the final output should look like. For example, say you're deprecating an old accordion component in favor of a new one. Instead of asking every designer on your team to follow a set of written instructions to migrate their designs, you can encode those instructions in a new component migration skill that they that they can run against their designs. You can create skills by prompting the agent, Then publish them to your org for your team to rely on, or find ready-to-use skills for design systems on the Figma community. To recap, start with the fundamentals, then add tailored guidance for the agent. Keep refining as you learn what works, and in time you'll end up with a system that helps both your teammates and their agents achieve quality designs. If you're just getting started with design systems, Check out our Intro to Design Systems course and make sure to subscribe for more videos.