I wanted to test a question that felt more useful than whether AI could generate interface objects quickly: can an experienced designer use an AI agent to produce substantially more work while preserving the judgement, governance and quality standards of professional product design?
The goal was deliberately small: build an original mini design system with foundations, reusable components, states, documentation and enough real context to expose where the system broke. I would set the direction, constraints and quality bar. AI would help construct, revise and propagate decisions through the file. The experiment would be judged by what survived review, not by how much appeared on the canvas.
This was not an exercise in finding the perfect Figma prompt or demonstrating a particular AI feature. Figma was where the artefact lived; the conversation was where the work was directed. I worked with an AI production partner that could operate on the design file through tools and APIs, while I remained responsible for intent, critique, system quality and final decisions.
The working loop became:
That distinction matters. The value was not simply that AI could make pixels faster. It let me work at a higher level of abstraction: directing a system of work, interrogating the output, and deciding what was safe and useful to make reusable.
The AI produced a set of named components quickly. On paper, it looked productive. On inspection, several were effectively the same rectangle with different labels. The file had components, but not yet a credible component system.
That changed the experiment. I stopped measuring progress by how much AI could generate and started asking whether each component actually expressed its purpose, anatomy and states.
A component name alone does not guarantee its functionality or usability. It is essential to ensure that each component is not only named but also designed to fulfill its intended purpose, with clear anatomy and states.
As the library improved, the most revealing problems became less obvious. Components could look consistent while still being structurally wrong.
During review, I found focus treatments being recreated locally instead of inheriting cleanly from the system-level focus token. A Card master and its instance could diverge. Select hover geometry looked correct until the third option escaped its menu boundary. Button labels appeared centred until longer overrides exposed fixed widths and flipped surfaces.
Each time, the goal was to fix the system rather than patch the specimen: correct the master, bind the token, define the spacing rule, or clarify the component's purpose. Once the rule was sound, AI could propagate the correction much faster than I could manually repeat it.
Some decisions were about semantics, not pixels. Field validation belongs with the field. An Alert is contextual feedback. A Banner is page-level messaging. A loader should read as a conventional loading indicator, not as a decorative icon. Body text should default to the system's regular body style, with smaller copy used intentionally when a compact component genuinely needs it.
These distinctions matter because a design system is a shared language. If the rules are unclear in the library, inconsistency spreads into the product.
The same pattern continued with dialogs and loading. Warning and destructive actions needed different intent, colour and language. Button geometry had to be corrected at the master rather than patched per modal. Loading needed to become a real component with purposeful size variants instead of an icon that happened to look animated.
I also treated the Figma file itself as part of the system. Foundations come before the components that depend on them. Source components and reviewable examples are separated. Layers use semantic names. Usage and governance notes document what a component is for, which states exist and what is still open.
That structure made later AI-driven changes safer because the source of truth was clearer. It also changed the conversation from “does this look right?” to “what rule should make this stay right?”
AI did more than draw. It built and revised Figma objects, propagated system changes, proposed additions when it encountered missing foundations, helped document the system, and sometimes recommended that we stop expanding the library and test what already existed.
My role was different. I framed the experiment, set the quality bar, inspected what the output actually showed, challenged inconsistencies, decided which recommendations to keep, and turned individual problems into repeatable rules. The collaboration accelerated execution without transferring responsibility for judgement.
That is where my role mattered most: not delegating design judgement to AI, but directing AI execution while protecting the coherence, maintainability and intent of the system.
Once the system looked mature, I stopped improving it and used it. The question was whether AI could build with the system without quietly changing the rules to make the screens work.
I gave the AI a realistic consumer subscription brief: build a five-screen account-management journey with forms, preferences, validation, loading, failure, recovery and success. The point was no longer to prove that AI could make components. It was to find out whether the system could hold together in product context.
To keep the test honest, the AI could use existing components and variants, change copy and selected states, and compose the screens. It could not detach components, edit the source library, add one-off styling, or invent new reusable patterns without calling them out. That turned the exercise from “make five nice screens” into a real test of the system I had built.
%2001.png)
The answer was yes. Across five happy-path screens and six alternate states, the AI used 97 component instances. Nothing was detached. No new component families or variants were created during the run, and the source library stayed unchanged. One warning message needed shorter copy to fit a compact Alert. That was a normal content adjustment, not a design-system failure.
5 happy-path screens
6 alternate states
97 component instances
0 detached components
0 new components
Put simply: the system held, the AI followed the rules, and the layout model worked.
The 12-column grid also held across the flow. More importantly, the same system supported authentication, navigation, cards, forms, selection controls, preferences, validation, contextual feedback, loading, failure, recovery and success without hidden one-off UI decisions.
%2001.png)
This does not prove usability, desirability, complete responsive behaviour or accessibility compliance. It proves something narrower and more useful here: the system was coherent enough to support a believable desktop product flow, and the AI could work inside it without quietly changing the foundations.
AI made the work faster, but speed was not the most interesting result. The useful part was discovering where plausible output diverged from work I could actually defend.
The pattern became consistent: AI could generate structure and apply revisions quickly. Quality still depended on recognising when something only looked right, asking why it was wrong, and defining a rule that improved the whole system instead of one screen.
The final test added another lesson: AI performance depends heavily on the environment you create for it. Clear source-of-truth rules, explicit constraints, prepared test conditions and a definition of failure made the agent more useful without transferring responsibility for judgement.
AI literacy, in this context, is not knowing every feature in every design tool. It is knowing how to frame the work, set constraints, interrogate output, turn good decisions into reusable rules, and verify that those decisions survive real use.
AI made me faster. The quality still depended on my ability to recognise what good meant.
I stopped because the experiment had answered the question I set out to test. The system held across a complete product flow, and the AI worked within the rules without me quietly changing the foundations to make the result look successful.
If I return to it, it will be because a new product problem gives the system something genuinely new to prove, not because this case study needs more evidence.
This is Experiment 01 in my AI in Practice series.
