Why I stopped designing AI apps in Figma
Figma works great until your design depends on motion, timing, and real model output. For AI apps, none of those translate to a static frame.
I picked up Figma fairly recently, for a few of the products I’ve worked on. For most of the regular UI, it does the job fine. For the AI parts of those apps, the workflow keeps breaking down. Here’s why, and what I do instead.
A Figma mockup represents a moment frozen in time. One screen, one state, one piece of content. That works for most UIs. A settings page is a settings page, and it looks roughly the same whether you’re a new user or a power user.
AI app UIs don’t sit still. The response area is generating text right now, but five seconds ago it was empty, and in another five it will be twice as long. The chat history has zero messages on first use, three messages mid-conversation, two hundred messages after a week.
You can mock those states in Figma. You can make a frame for each. What you can’t do is see the streaming, or feel whether the layout judders as tokens arrive, or experience the timing of the loading state cutting over to the actual content. What you’re really designing is motion and timing. Figma shows posed snapshots.
The fake-content problem
In Figma, you fill placeholders with text like “User asked: How does this work?” and “AI response: This is how it works…”
In production, users ask things like “can you compare q3 numbers but only for north america and only for sku 8842 and exclude returns” with three typos.
The placeholder version is a clean two-line interaction. The real version is a wall of text with awkward line wrapping, followed by a multi-paragraph response with bullets and a table.
What looked balanced in the mockup is now lopsided. The padding was tuned for a sentence. The font size was tuned for short responses. The card layout breaks at the third bullet point.
This isn’t really a Figma problem. It’s what happens when you design with placeholder content for an app where the actual content is much more variable than your placeholders can suggest. With AI apps, the gap between fake content and real content is bigger than for almost any other class of software.
What I do now
Most of my AI app design happens in code now. Not in Figma.
I’ll sketch the basic layout in Excalidraw. Two minutes, just enough to know roughly where things go. Then I build a working prototype with real model calls. Tailwind for speed, a real endpoint hitting whatever model I’m targeting. Usable in a browser within a couple of hours.
Then I iterate on the actual thing. Adjust spacing as real responses arrive. Tune the loading state by watching how it feels. Fix the layout when a long response from a real user breaks it.
Figma still has a role. Component documentation, brand work, exploring visual direction. But the core design of how the AI feels to use happens with a real model in the loop.
When this is wrong
The design-in-code approach is overkill for non-AI features. If I’m adding a settings panel to an AI app, I’ll still mock it in Figma like everyone else. One state, predictable content, no real advantage to skipping the mockup.
It’s also wrong for early concept exploration. Sometimes you need to compare ten visual directions cheaply, and Figma’s ability to copy a frame and tweak it is hard to beat for that.
The shift only really matters once you’ve picked a direction and you need to feel how the AI interaction actually behaves. At that point, anything you do in Figma is at best preparation for finding out what’s wrong in code.