Most advice on how to give design feedback is about manners: be kind and be specific. Designers do not fail to act on rude comments. They fail to act on comments that name no goal, no place and no decision, and those are the politest ones, because politeness is what remains when a comment says nothing else.
The politest comment is the one nobody can use
Read a round of feedback from the designer’s side. Somebody writes that they are not sure about the blue. Somebody else says the page feels busy. A third person likes it but wonders whether the hero could pop more. Each of those was written with care, and each sends the designer to a call to find out what was meant, because none of them contains a thing to change or a reason to change it.
| The comment as written | What the designer has to ask back | The comment that needed no reply |
|---|---|---|
| Not sure about the blue | Which blue, where, and what should it do instead | The blue on the primary button reads as disabled next to the grey one beside it |
| The page feels busy | Busy where, on what screen, compared with what | On my laptop the pricing section shows three cards and two banners above the fold and I cannot find the plan names |
| Could the hero pop more | Pop for whom, and what is it failing to do now | The headline is the fourth thing I read on the page; I read the image, the nav, and the badge first |
| Have you considered a carousel | Is that a request or a thought | Question, not a request: does a carousel fit the brief’s line about one message per screen |
| Looks great, one small thing on mobile | What thing, which phone, which page | On a phone the footer links wrap onto each other on the contact page |
Every rewrite in the third column is longer, and every one of them is blunter. That is the trade. A comment a designer can act on says what is wrong, where it is wrong, and what the design was supposed to do there, and there is no way to say those three things gently enough to lose them.
Name the goal before you name the fix
The most common shape of unusable feedback is a prescription with the diagnosis left out. Make the logo bigger. Move the button up. Use a photo instead of the illustration. Each of those is a solution to a problem the commenter noticed and did not write down, and the designer receives the solution without the problem, which leaves them choosing between doing something they think is wrong and guessing what it was for.
The fix is to write the expected and actual result, in the same shape a tester uses for a bug. I expected to know who the company was before I scrolled; I did not. I expected the main action to be the first thing I saw; the first thing I saw was the badge. A comment in that shape gives the designer the goal and the failure, and leaves the solution to the person whose job the solution is. Often it is bigger logo. Often it is something the commenter would not have thought of, because the commenter is not a designer, and the whole reason the design was commissioned is that somebody else is.
Prescriptions are still allowed. They go after the goal, marked as a suggestion, so the designer knows they may decline it if they hit the goal another way.
Say where you were standing
A design is seen from somewhere, and a comment that does not say where it was seen from is a comment about a different design from the one the designer is looking at. The stakeholder who opened the PDF on a phone from a train saw a page shrunk to fit a phone’s width. The one who opened the live link on a wide monitor saw the layout stretched to a width the design was never set for. Both wrote that the type was the wrong size, and both were right about the thing in front of them.
So a usable comment carries an address: the page, the device or viewport, the state the page was in (signed in, scrolled, after an error), and the version. On a mockup, that has to be typed. On a built page, it does not. Website feedback filed from the page itself arrives with the address attached. In Notarus, the stakeholder on the train and the one on the wide monitor each file their comment from the page they were looking at, and each report records the viewport, the browser and the device it was made on, so the designer sees at once that the two type-size comments describe two widths. The evidence capture page lists what travels with a report.
That changes what the commenter is responsible for. The address is handled; what remains for the person is the goal and the judgement, which is the part no tool can supply.
Say whether you are deciding or wondering
A product manager writes have you considered a carousel. A junior designer reads it as an instruction and builds one. A senior designer reads it as a thought and ignores it. Neither was told which it was, and the manager, who meant it as a question, is surprised either way.
Feedback carries authority whether the writer intends it to or not, and the reader guesses at the weight from the writer’s title. The guess is often wrong. Three labels remove it.
| Label | What the designer does with it | Who is entitled to use it |
|---|---|---|
| Decision | Applies it, or argues the case before the round closes | Whoever signs off the round, and nobody else |
| Question | Answers it, and changes nothing until the answer lands | Anybody in the round |
| Preference | Weighs it against the brief and the other preferences | Anybody, and it is weighed by who owns the result |
The first row is the one that needs agreeing in advance. A round in which several people can issue decisions is a round that produces conflicting instructions, and a designer receiving two decisions that cannot both be applied will pick one and be wrong about it for somebody. The friction blamed on tone is a stakeholder issuing a decision they were not given the authority to issue, in a wording that gave nothing away.
Interaction feedback waits for the staging build
Some of the most important feedback cannot be given on a mockup at all, and giving it there wastes a round. How the page feels while it loads. Whether the transition between two states reads as one page or two. What the form does when a field is wrong. How the layout copes with a real product name that is three times longer than the placeholder. A static image contains none of it, and a comment about it made on a static image is a prediction rather than an observation.
The build arrives late in the schedule, and the round in which interaction feedback can be given is short and close to launch. A commenter who spends the mockup rounds on the hero and saves nothing for the build will give their interaction feedback at the end of the schedule, when the cost of acting on it is highest, or will give it after launch as a complaint. The better plan is to hold a list: the things that could not be judged from the mockup, written down during the mockup rounds, and walked through on the staging site in one sitting, each one filed against the element it concerns.
