Design prompting: describe the world, not the widget — Frigade

LoginAssistantManage your AI assistantEngageBuild onboarding flows

Get Started

Products<br>Assistant<br>Engage<br>Company<br>How It Works<br>Pricing<br>Updates<br>Blog<br>About

LoginGet Started

← All writing<br>Design prompting: describe the world, not the widget<br>We gave two Claude instances the same button to animate, one with a bullet-point spec and one with a metaphor about molten metal. The gap was wide, and not in the direction you'd expect.<br>Micah Snyder, Founding Engineer<br>·May 21, 2026·3 min read

Animations are hard to describe. Most of us don't have the vocab (keyframes, easing curves, durations) to spell out what we want, so we end up typing things like "make it pulse on hover, kind of a blue glow, soft, not too aggressive" and the model gives back something fine. Not what we wanted. We try again, hedge a few words, get something else fine. The loop is real.

The approach we've been getting good results from doesn't require learning that vocabulary. You describe a world for the animation to live in and let the model derive the timing and feel from there.

The story behind this post

A few weeks ago I was working on the highlight inside our assistant. The product is built around a small blue ping that travels across the screen and lands on the element it's pointing the user toward. Customers told us the landing didn't register clearly enough. The ping reached the target, but the moment of arrival was too subtle to feel.

The next version added an animated treatment on the border of the target element, triggered on landing. My first few drafts described the new treatment as a list of properties: an outline that grows, a glow that fades, a color, a duration. What came back looked fine and felt flat. I switched to describing the motion as a physical thing, something with weight and travel time and a place it starts and a place it ends. The version that came back from that clicked on the first try.

The move that mattered was switching from enumerating properties to describing a physical thing. The loop ended on the next try.

What metaphors actually do for an LLM

There's a mechanical reason this works. A metaphor ships with a coherent world attached, and a property list doesn't. When you tell a model "make it pulse softly, blue glow," you've given it a list of properties to satisfy and nothing to connect them. The model picks defaults for everything else and the result feels stitched together.

Try the other way. Imagine a stone trough that runs along the top of a castle wall in a siege, the kind defenders pour glowing liquid into. The liquid travels along the trough until it spills out the far end. The glow is the only thing alive on the wall. Everything else holds still.

A castle channel is slow because the liquid is heavy. A castle channel glows because the liquid is hot. A castle channel ends when the trough does. None of those are details the model had to invent.

There's a second thing the metaphor buys you: density. Describe an animation literally and you are stuck with a bad trade. Either you enumerate every property, which means knowing it exists and what it is called (the exact filter, the easing curve, the color stops), or you keep it short and let the model guess the rest. A metaphor refuses the trade. "Molten metal" is two words carrying temperature, color, weight, flow, and the way the glow dies when the source cuts off. That is the densest way to hand the model a world, and it never makes you name the parts.

Lakoff and Johnson made this argument forty years ago about humans, in Metaphors We Live By. We organize abstract reasoning in the shape of physical experience. The argument works on language models for the same reason it works on us: most of what we know is stored as worlds, not as specifications.

Try it: a button

Here's a plain button. No animation, no hover state.

Continue

We asked two separate Claude instances to animate it on hover. No shared context, same starting button.

Prompt A is how most of us actually describe animations:

On hover, do a little ring of gradient around the outside of the button. The ring should start from where the cursor enters and flow both directions until it meets on the opposite side.

Prompt B swaps the description for a world:

On hover, do a little ring of gradient around the outside of the button. Imagine the button border is a channel, and molten liquid is flowing through the channel and filling the perimeter. The liquid first starts from where the mouse enters the button, and flows both directions until it meets.

What came back from A (hover over the button):

Continue

What came back from B (hover over the button):

Continue

A spins. The gradient is a rotating loop of purple, pink, and amber, with a small gap that travels around the perimeter forever. The cursor entry sets where the gap starts. It looks fine, but it's not what I asked for. The prompt said "flow both directions until it meets on...