In short
Good website feedback always names three things: the exact place, the observed problem and the desired outcome. Providing all three typically saves an entire correction round.
Why most feedback emails fail
“The button top right should look different” sounds specific, but it is not: on mobile there is no top-right button, and “different” is not a target state. Misunderstandings almost always come from missing reference to the element and a missing target image, not from a lack of effort.
1. Always name the place
“Top” and “bottom” do not exist – on mobile the order changes, and spacing shifts with screen size. Use the element itself as the reference by leaving feedback directly on it instead of describing it.
2. Separate observation from request
First write what you see, then what you want. “The headline wraps onto two lines” plus “please shorten it to one line” is actionable. “Looks off” is not, because it names neither a cause nor a goal.
3. One note per item
Bulk emails with twelve items create partial completions and arguments about status. One item, one note, one status – so each point can be resolved individually without blocking the rest of the list.
4. Attach context automatically
Browser, operating system and screen size often decide whether a problem exists at all. A layout bug in Safari on iOS may be invisible in Chrome on Windows. Tools like nootiz capture this data automatically with every note.
5. Distinguish bugs from taste
Mark clearly what is a defect (a broken layout) and what is a preference (a different colour). Both are legitimate, but only one of them is objectively wrong and urgent.
6. Set priorities
If everything is important, someone else decides the order – usually by gut feeling. Flag what blocks the launch and what can wait for the next version.
7. Use examples instead of adjectives
“Too small”, “too busy”, “too colourful” are opinions without a unit. Link a reference example instead, or name a concrete value such as a font size or a spacing.
8. Give feedback while you look at the page
Notes written days after viewing a page lose detail. Comment while you are looking at the site, not afterwards from memory.
9. Assign an owner
A note without a recipient stays untouched. Assign each item to a person so nobody assumes someone else is already handling it.
10. Example wording for common cases
Use these patterns as a template for your own notes:
- Instead of “image looks weird” → “image is distorted on mobile, please crop to a 4:3 ratio”
- Instead of “text too long” → “paragraph has 140 words, please shorten to max 60”
- Instead of “don’t like the colour” → “please change the button colour to brand colour #1A73E8”
- Instead of “loading is bad” → “page takes over 6 seconds to first content on 4G”
11. State approval explicitly
Feedback ends with a decision. Mark resolved items as done instead of going silent – silence otherwise gets misread as either approval or an open item.
Giving feedback when you work remotely
If you're not in the same place as the team, a note left directly on the element replaces looking at a screen together. Write it exactly as concretely as if you were standing next to the person, and add a short screen capture or a timestamp of when you noticed the issue if there's any ambiguity. That keeps feedback traceable even when nobody reads it live.
Checklist for every feedback note
Before you send a note, check these four points:
- Place: marked on the element, not described
- Problem: stated observably, not as an adjective
- Request: a concrete, measurable outcome
- Priority: flagged as blocking or not
Frequently asked questions
How many feedback rounds are normal?
Two to three rounds are common in practice. Additional rounds usually come from unclear attribution rather than genuine disagreement.
How do I give feedback on text and layout at once?
Split them into two notes. Text and layout changes often have different owners and otherwise get mixed up.
What if I can't explain the problem technically?
Describe what you observe, not how it happens technically. “The text is cut off on mobile” is enough – the team will find the cause.
How do I handle conflicting feedback from several people?
Collect all notes on the same spot so the conflict becomes visible, then let one responsible person decide.
Do I need to attach screenshots?
Not if the feedback is left directly on the element on the page – the screenshot is already the context.
How do I phrase feedback about loading times?
Name the device, the connection and the measured time, e.g. “6 seconds to first content on 4G”, instead of “loads slowly”.
How often should I give feedback while a project is running?
As soon as a section is presentable – continuous, small feedback is easier to act on than one large list at the end.