How to give feedback an AI can actually fix
Six steps from a messy prototype to a prompt you can paste into the tool that built it.
Prototyping · Aug 30, 2026 · 4 min read
Most feedback on AI prototypes fails for a boring reason. It is written for a person who will ask follow-up questions. The AI won't ask. It will guess. So the notes need to be clear enough that guessing is not needed. Here is how we do it.
The six steps
- Open the prototype and review one screen at a time. Don't skim the whole app and write a summary. Finish a screen, then move on.
- Comment on the element, not the page. Click the button, the heading, the input. A note that says "the checkout is confusing" is a conversation. A note on the Pay button is a fix.
- Say what is wrong and why. "Button is hidden under the fold on mobile. People won't see it before they leave." The why lets the AI pick a better fix than the one you had in mind.
- Tag it. Bug, design, copy, idea, or question. Tags let the builder do the bugs first and park the ideas.
- Batch the notes into one prompt. Don't send them one at a time. One prompt with all the notes, each with its element, means one pass and fewer regressions.
- Paste it into the tool that built the screen. v0 for a v0 screen, Lovable for a Lovable app, Cursor if the code lives in a repo. Then review the result the same way.
Step 2 is the one people skip
Page-level feedback feels faster to write. It is slower to act on. If you say the pricing page is cluttered, the AI has to decide which of forty elements you meant. If you pin three elements and say what each should do, it just does it.
A good element note has the element, the problem, and the intent. It does not need to be long. "Secondary CTA: same weight as the primary, so nothing stands out. Make it a text link." That is enough.
What a good fix prompt looks like
Here is the shape of a prompt that works. The element comes first so the AI knows where to look. Then the note. Then a line about the viewport if it matters.
Fix the following on the landing page. 1. `button.cta-primary` (Bug): hidden under the fold at 375px. Move it above the feature grid so it is visible on load. 2. `h1.hero-title` (Design): wraps to four lines on mobile. Reduce to around 32px on small screens. 3. `a.nav-pricing` (Copy): says "Plans" but the page is called Pricing. Rename to "Pricing". Keep everything else as is.
Notice the last line. Telling the AI what not to touch saves you from the rewrite that breaks three other things.
Doing it by hand vs with Vizhound
You can do all of this in a doc. Write the selector, describe the element, paste a screenshot. It works. It is also slow, and most people stop after the third note.
Vizhound does the tedious part. Paste the prototype link, click an element, type the note, pick a tag. The element selector, its styles, and a screen grab are captured for you. When you are done, export the review as one fix prompt for Claude, Cursor, or v0, or as a task list for Trello or Jira.
A few limits to know. It works with anything that opens in a browser, so Lovable, v0, Replit, and Vercel previews are fine. Pages behind a login won't load yet. Not Figma files. And on apps that render everything client-side, pins are position-only, without the element data.
Before you send it
- Read the prompt once. Would a stranger know what to change?
- Check every note has an element and a reason.
- Bugs first, ideas last.
- Say what should stay the same.
That is it. The build is fast. Make the feedback match.
