News and analysis
AI in a design system: who accepts a component change?
Figma describes library upkeep and product-team experiences. Check tokens, states and the handoff from design changes to the application.
A product contains several similar buttons, each with different spacing or behaviour. An agent can quickly make the designs look consistent. One question remains after that edit: did only the drawing change, or did a rule change for the whole product? Two Figma articles dated 6 October help distinguish maintenance work from a design-system decision.
A library needs explicit context
In its design-system upkeep article, Figma describes documentation, naming and token checks, and finding deviations from the library. The vendor connects useful output with the design context supplied to the agent. Preparing that context means identifying the components and conventions the team actually considers current.
For a customer portal, start with one frequently used element, such as an input field. Define its normal, focused, error and unavailable states. Then identify values supplied by tokens and changes allowed on a particular screen. Otherwise a tidy visual update may preserve inconsistent rules for the same task.
Another team’s story is not your acceptance test
A second Figma article presents experiences from product designers at Uber, Granola and Atlassian, including documentation, design-system work and motion. These are team stories reported by the vendor, rather than independent guarantees of quality or time savings.
The connection is a repeatable process: library rules are supplied to the agent, it prepares changes, and the responsible team accepts them. A bulk component replacement affects more screens than the initially visible design. Give the reviewer a list of affected instances and the reason for each replacement.
Test the component in a working journey
Choose a form with invalid input and long text. Review the design change, then test the implementation on a narrow screen and with a keyboard. Establish that the error message belongs to the field, focus remains visible and the button communicates the allowed action.
If motion changes, agree its purpose: acknowledging an action, moving between stages or revealing information. Check reduced-motion behaviour and whether the effect interferes with reading. Token conformity alone does not establish accessibility or usability.
After acceptance, update the component description and record the developer handoff. The comparison suggests that upkeep has value when the next screen uses the agreed rule rather than another local interpretation. A small team can begin this cycle without rebuilding its entire system.
Our first customer-portal release guide helps choose a testable journey. The rental application project provides product context without claiming use of the Figma agent. For your customer product, discuss a component and its acceptance criteria.