A working guide from Less Studio
Design systems for AI-assisted development.
A practical refactor of the design-to-development workflow.
AI-assisted development makes a familiar design-system problem more visible. A screen can show what to build without explaining which parts are reusable, how a component behaves, or what happens outside the ideal state. People fill those gaps through conversation. AI tools infer them from the context they can access.
The practical goal is to make design intent explicit enough that a designer, developer or agent reaches for the same building blocks.
Start with one real flow.
Take a product journey your team is building. Can someone identify the canonical components, the role of each value, the available states, the responsive rules and the matching code? If those answers live only in people’s heads, a larger Figma library will not settle the handoff.
Name values by purpose.
A primitive records a value. A semantic token records its job. gray/900 might be the source, while color/text/primary tells the team where to use it. Figma variables, aliases and modes can express those roles. Component and layer names have a separate job: describing the objects and structure that use the values.
Define the component’s range.
A single button frame shows one appearance. Its component contract should state purpose, properties, variants, content limits and behavior. Include loading, empty, error and disabled states where the product needs them, plus accessibility requirements and correct-use examples.
Describe structure and behavior.
Names such as QuoteSummary and NextAction carry more information than Frame 42. Auto layout records how content changes the composition. Annotations explain transitions and exceptions a static frame cannot show. Check long copy, narrow widths and non-happy-path states.
Connect design to code.
A Figma component and a production component can share a name while differing in props or behavior. Map them explicitly. Begin with the components used most often, document approved usage and update the mapping when the code changes.
Test the system in a build.
Use a representative screen or workflow. Let a developer and an AI-assisted implementation workflow build from the same context. Inspect whether the result reuses the right components and tokens, handles responsive and failure states, and how much correction it needs. Turn recurring corrections into system rules.
The names and examples in this guide are illustrative. Each product needs its own vocabulary and code mapping.