How to give Claude Code visual feedback

You can see exactly what's wrong with the button. It's too heavy, it sits too close to the headline, and the green is a little cold. Then you open Claude Code and type "make the button softer", and the next version is wrong in a new way.

That gap between what you see and what you can type is the whole problem with visual feedback for AI coding tools. This guide covers what Claude Code needs from you to close it, and a workflow that gets UI changes right in fewer rounds.

Why text prompts fail at visual feedback

A sentence like "make it feel more premium" carries almost no information. You know what you mean because you're looking at the screen and you have a picture in your head. Claude Code has neither. It has your words, and it has the code.

So it guesses. It might add a gradient, swap the font, or increase every shadow. Each guess is reasonable on its own, and none of them is what you meant. You correct it, it guesses again, and three rounds later you're typing "no, different, but not too different".

Visual feedback works when it answers three questions the model can't answer by itself:

1. Which thing? The exact element, not "the card on the pricing page".
2. What's wrong with it? What you noticed, in your own words.
3. Where should it go? A picture of the direction, not an adjective.

Can Claude Code see screenshots?

Yes. Claude Code can read images, so you can paste a screenshot into the session, drag an image file in, or give it the path to an image on your computer. It will look at the image and use it alongside the code.

A screenshot alone is still ambiguous, though. A full-page capture with "fix this" leaves Claude to work out which part you mean. Crop to the area you care about, or draw on it: a box around the element, an arrow, a scribble over the part that feels off.

What good visual feedback for AI includes

The best feedback notes I've seen from designers working with Claude Code all have the same shape:

• The element. Its selector or component name if you know it (button.cta, PricingCard), plus where it sits on the page.
• A screenshot of the current state. Cropped, ideally marked up.
• What feels off. One or two plain sentences. "Too heavy. It needs more room around it."
• A reference. An image of something that gets it right, with a note on which part to look at.
• What to keep. "Don't touch the layout, only the styling." This stops the fix from turning into a redesign.

Written out, a note might look like this:

Element: button.cta in the hero
Screenshot: hero-cta.png
Note: Too heavy. Make it softer, with more room around it.
Reference: summer-objects.jpg, the lime pill shape, not its colour
Keep: the label and the position

That note is short, but every line removes a guess.

How to point Claude Code at the exact element

If you're comfortable in the browser's developer tools, right-click the element, choose Inspect, and copy its class or the component name. Paste that into your prompt next to the screenshot.

If you're not, describe it by position and content: "the green 'Get started' button under the hero headline". Avoid "the button", since most pages have more than one.

Either way, ask for one change per element. "Make the button softer and fix the spacing on the card and tighten the nav" is three tasks, and the quality of each drops when they're bundled into one sentence.

Show the direction with a reference, not an adjective

Adjectives like "premium", "playful" or "clean" mean different things to everyone. A reference image means one thing. If you want a softer button, find a softer button you like and save it.

Then say what you saw in it. A reference can show what you like, but it can't explain which part you mean. "This curve, just this curve" or "this amount of white space" turns a picture into an instruction. I wrote more about this in how to build a moodboard for AI-generated UI.

Send feedback in batches

Reviewing a page usually turns up five or six things at once. You can send them one by one, but it's often better to collect them first and send them together. Claude Code then sees the whole picture: it can spot that three notes are really about the same spacing token, and fix it once.

Keep each note separate inside the batch, though. A numbered list of notes, each with its own element, screenshot and reference, is much easier to act on than one long paragraph.

Giving Claude Code visual feedback with Moodbit

I built Moodbit because this workflow was slow to do by hand: screenshot, crop, save, find the reference, copy the selector, write it all up in the terminal.

Moodbit is a Chrome extension. Open your app on localhost, press Control+M to open the dock, and click the exact element you want to change. Write what feels off, draw what you mean, and attach a reference you saved earlier. When you're ready, send one note or several together. Your Claude Code session gets your words, the screenshots, the element you clicked and the references you chose. If Claude is closed, the notes wait for it.

Common questions

Can I paste a screenshot into Claude Code?

Yes. Paste an image straight into the session, drag the file in, or give Claude Code the path to it. Crop or mark it up first so it's clear which part you mean.

How do I tell Claude Code which element to change?

Give it the element's class, ID or component name, plus a screenshot. If you don't know the selector, describe its position and its text, and avoid words that match several elements.

Does Claude Code understand design references?

It can read reference images and describe what's in them. It does much better when you say which part of the reference matters: the shape, the colour, the spacing or the structure.

What should I write in a design feedback note for AI?

Say what's wrong in one or two sentences, point at the exact element, add a reference for the direction, and say what must not change. Skip adjectives that could mean anything, like "modern" or "premium".

How do I stop Claude Code from changing more than I asked?

Say what to keep. "Only change the button's padding and radius, leave the layout alone" is specific enough that the fix stays small. Committing after every change you like also means you can always go back.