I shipped a Figma plugin. The AI was the easy part.

StoryCraft is a Figma plugin. You select a frame, it reads the screen, and it writes a hierarchical backlog of user stories — epics down to acceptance criteria — then pushes them into ClickUp.

I built it because I kept doing that translation by hand for financial-software teams, and it is exactly the kind of work that feels like thinking but isn't.

Here's what I expected to be hard: getting a language model to produce good user stories.

Here's what was actually hard: everything else.

The model part took a weekend

Genuinely. Reading a Figma frame gives you a tree of nodes with names, types, text content, and hierarchy. That's already a structured description of an interface. Handing that to Claude with a decent prompt produces usable stories on the first try.

The prompt went through a lot of iterations, mostly to constrain it rather than improve it. Left alone, the model wants to be helpful, and "helpful" means it invents requirements nobody asked for. Point it at a login screen and it will cheerfully generate stories about password strength meters, social auth, and account recovery — none of which are in the frame.

That's the first real lesson: most prompt engineering for a design tool is subtraction. You're not teaching the model to write stories. You're teaching it to stop writing stories about things it can't see.

The rule that fixed it was making the frame the only source of truth. If an element isn't in the tree, there's no story about it. Suddenly the output was boring and correct, which is what you want from a backlog.

The hard part was deciding what a "story" is

Here's the thing nobody warns you about when you put AI in a design tool: the model will happily produce output at any level of granularity, and choosing the granularity is the entire product.

Feed it a dashboard. Do you get:

• One story: "As a user, I can view my dashboard"
• Eight stories: one per card
• Forty stories: one per interactive element, each with acceptance criteria

All three are defensible. All three are what some team somewhere actually wants. And the model has no opinion — it'll give you whichever you ask for, with equal confidence.

This is a product design decision wearing an AI costume. I ended up defaulting to the middle — component-level stories, grouped under a screen-level epic — because that's the altitude at which a story survives contact with a sprint planning meeting. Too coarse and it can't be estimated. Too fine and you've generated forty tickets that all say "button exists."

No amount of model quality answers that question. You have to have shipped backlogs to have a view.

The parts that had nothing to do with AI

Rough accounting of where the build time went:

Licensing and payments. A plugin that costs money needs license keys, a validation endpoint, a paywall that degrades gracefully, and a way to not lock out a paying customer when your backend has a bad day. This was the single largest chunk of work and contains zero AI.

The ClickUp integration. Every project management API has opinions. Mapping a clean hierarchy of epics and stories onto someone else's task model — with their custom fields, their statuses, their rate limits — is fiddly, unglamorous, and the reason the plugin is useful rather than a text generator.

Figma's plugin sandbox. Plugins run in a constrained environment with a specific threading model. A lot of things you'd do casually in a web app you cannot do here. This is normal platform work and it takes the time it takes.

Waiting states. Generation takes several seconds. In a plugin panel, several seconds of nothing is an eternity — users assume it's broken and hit the button again. Streaming the output as it arrives fixed this, not because it's faster but because it's legibly working.

That last one is the closest thing to an AI-specific design problem I hit, and it's really just a latency problem wearing a new hat.

What I'd tell a designer building their first AI feature

Your differentiator is not the model. You're calling the same API as everyone else. What makes the tool good is knowing which output altitude is useful, what to refuse to generate, and where the human needs to intervene. That's domain judgment, and it's the part AI is worst at supplying.

Design the wrong answer. Every AI feature ships wrong output sometimes. Mine occasionally produces a story that's technically accurate and practically useless. The question isn't how to prevent that — you can't — it's whether the user can see it's wrong and fix it in two seconds. Editable output beats correct output.

Constrain aggressively, then loosen. Starting narrow and widening based on real complaints is much easier than reeling in a model that's been inventing requirements for a month.

The boring infrastructure is the product. Licensing, integrations, error states, and rate limits are what separate a demo from a thing people pay for. I've seen a lot of impressive AI demos this year. The gap between those and shipped software is almost entirely unglamorous.

The meta point

I keep seeing "designers need to learn AI" as though the skill is prompting.

The skill is product judgment about probabilistic output. Knowing what to generate, what to refuse, what altitude to work at, and what the interface does when the machine is confidently wrong. That's a design skill. It's the same design skill it always was — deciding what the product should do — applied to a system that will do anything you let it.

The prompting takes a weekend. The judgment is the job.

---

More on how I work with AI day-to-day in AI didn't kill product design.