Import your design system (*)

Prompt-to-design / prompt-to-prototype tools like Claude Design or Figma Make promise you can import your existing design system and let the LLMs output compliant screens. No reviews needed, no designers, no effort. No need to read the documentation. Do you want that?

What would be the benefits?

Delegating it all to AI sounds attractive because it does chores for us. Nobody likes to learn a complex ruleset, then have to manually check for compliance. It's the worst part of any game night: you want to play, not to spend hours reading the rules. So offloading all of that tedium, all of those responsibilities to a machine is appealing.

The AI toolset is also attractive because it bypasses the skill barrier. Imagine your sink is leaking. You've never considered pipes or drains before in your life. But at the click of a button, you can have all of the experience and know-how of a battle-worn plumber. Who wouldn't click?

Using your design system is a lot like fixing that leaky sink. It requires skill, and skill is friction in a company setting where people are increasingly incentivised to be "full stack". It requires "special people" who are limited in their bandwidth by human nature.

Why is it not so easy for everyone?

Because regardless of the tool you use (Claude Design, Figma Make, v0, Lovable), they essentially work the same way: they don't design the way you're used to, and most don't use your production-ready codebase. They "just" generate HTML / CSS / JS websites. They do so based on similar stacks, using the popular CSS framework Tailwind and generic UI kits like shadcn. It makes sense for them to be generic: their job is to be able to build anything, for any company that's willing to pay for it.

Your design system is not likely meant to build anything for anyone. You're building it so it can build your product for your users.

Components are the best example of that great divide between generic and specific.

In an existing product, components form a binding contract between design and codebases. They don't just look the same and are named the same, they also follow the same constraints. We do this because it cuts on delivery costs: a design is cheap to translate to code when what has been planned in Figma reflects the codebases' capabilities. No surprises, no misalignment, no hidden cost.

Importing colour values and "close enough"-looking components is not the same thing as importing your design system. Your design system is its rules, its context, and the end-to-end connection from design to user-facing codebases. And those rules are difficult to transfer reliably when systems are complex and documentation is heavy. The high skills required of component creation and maintenance actually apply both in traditional pipelines and in AI ones.

Strategies to mitigate when it's not easy

If you can't import without tremendous effort, treat that as a diagnostic moment, not an immediate gap. Ask what the resistance reveals.

If the friction comes from business-specific components, strict rules, semantic tokens, or deep code alignment, your system is likely optimised for delivery productivity in your real context. That is not technical debt. That is specialisation. What you'd gain from migrating all that to the pipeline focused on short-lived prototypes is not worth what you'd lose: the robustness of your perennial design-to-production system.

Still, you can try a few things to mitigate. First, don't treat the tool as you would a user-facing codebase. Truly consider it as a tool for non-consumers, using an adapted facsimile of the design system for prompt-to-prototype.

If system compliance is truly important in that context (but that is still worth questioning), invest then and only then in dedicated agentic steps: prompts whose job is to check that rules have been followed by the prototyping AI. You'll want to avoid dumping all your documentation blindly; package it in usable slices. Keeping human review in the loop will remain necessary where systemic contract risk is high, for example when those prototypes are getting closer to production.

That facsimile should still be owned by current design system owners so drift remains controlled and translation back to system compliance stays feasible. But it no longer focuses on exactitude: it focuses on bridges and resemblance.

That still requires maintenance and stewardship to avoid drift, so don't expect it to be free. But it'll be cheaper than forcing a tool made for flexibility to adopt your specific constraints.

Where else to invest with AI for mature and/or complex systems

In mature systems, compliant AI prototypes can have value for exploration and opening up the experimentation field to broader audiences. But your current audience would benefit more from AI-assisted QA: consistency checks, contract verification, and faster detection of non-compliant output are useful, in and out of the generative AI paradigm.

That matters even more when complexity is the bottleneck, documentation is dense, and designers are frustrated by the level of skill required to create and maintain components correctly.

So the decision is simple: easy import, do it. Hard import, learn from it. In both cases, prioritise AI-powered design system QA, because it helps expert and non-expert consumers alike. Then use AI-friendly facsimiles for broader exploration: it's not your design system per se you need to import, it's just what's enough to enable new consumers.

I'll close this on a final caveat. Design system facsimile or not, a prompt-to-proto tool today is often just that: it stops at the prototype. Getting this into your users' hands is something else. If that prototype is what your implementation team has to work with, consider what you're giving them compared to the current Figma deliverable. Is the translation effort going down or just moving? This is even more challenging for native app teams, because prototype tools today are much more web-oriented.

But your prototyping stack may already be your production stack, and the gap would be minimal. However, you're most likely very much in the present. In that case, consider what the true value of prototype output should be: is it that it looks production-ready, or is it that it improves the eventual outcome in terms of speed, quality or conversion.