Debugging a design prompt before it becomes code

Question

I have started treating vague design prompts like vague bug reports.

“Something feels off” is hard to fix because it does not tell you where to look. “The primary action disappears below 768px and the proof section comes after decorative content” is annoying, but at least it is actionable.

The same idea applies before an AI builder writes a component. “Build a beautiful landing page” is a complaint waiting to happen. It gives the model no hierarchy, no proof requirements, no mobile order, and no boundaries around the common visual clichés.

Hey Design AI is one place I use to make the request more concrete. Its 350 visual prompt previews are accompanied by build guidance, so I can inspect a composition and read what it is supposed to do.

Write the acceptance criteria first

Before I generate a page, I write a few conditions that the output has to meet:

• A first-time visitor can state what the product does after reading the first screen.
• The primary action is visible at common phone widths.
• The page uses real product evidence; it must not generate logos, testimonials, metrics, or UI data.
• Keyboard focus is visible, and motion has a reduced-motion alternative.

Those statements are not a substitute for tests, but they are close enough to acceptance criteria that they expose a bad draft quickly.

Use a reference for structure, not identity

A visual reference can help answer where the message, image, proof, and action should sit. It should not give the model permission to recreate another company’s personality.

The prompt directions in Hey Design AI include that distinction. They describe typography, colour, imagery, and spacing as roles in a system. They also make room for negative constraints. I find that helps keep an AI builder from turning a decent hierarchy into a clone with different words.

Debug the request early. It is cheaper than debugging twenty generated components later.