How do we give design feedback that actually changes the page instead of stalling it?

Because we build redesigns on our own design system rather than drawing each page from scratch, the cost of a change is almost entirely determined by how deep into the system it reaches. Every comment you leave lands in one of three buckets, and the difference between them is roughly one hour, one day, and one week.

A token change adjusts a value that the whole site already reads from: a spacing step, a text size, a border radius, a colour. Because every component references the token, changing it once changes it everywhere, consistently. “The body text feels tight” is usually a line-height token. These are the cheapest changes we can make and the ones with the largest visual effect per hour of work.

A component variant adds a new configuration to something that already exists: a card with an image on the left instead of the top, a button in a quieter style, a section with a narrower measure. The component is already built, tested and documented, so we are extending it rather than inventing it. Budget a day, including the documentation and the responsive checks.

A new component is a shape the system has never held: a pricing comparison table, a filterable index, an interactive map. It needs design, build, states, keyboard and screen reader behaviour, responsive rules, and an entry in the documentation so your team can use it after we leave. A week is the honest figure, and it is the bucket where a redesign timeline quietly slips, because a new component always looks like a small change in a screenshot.

Work through these five in order. In our projects, a comment containing the first three is almost always actioned the same day; a comment containing only the last two is almost always a meeting.

You do not need design vocabulary for any of this. You need to point precisely and describe honestly.

1. Name the element. Not "the top of the homepage" but "the hero heading" or "the second card in the three-up row". If the page has a URL and the element has a label, use both.
2. Describe what you observe, not the fix you have imagined. "I read the price before I read what the plan includes" is more useful than "move the price down", because the reading order might be fixed by weight or spacing rather than position.
3. Say what it costs you. Who is misreading it, what they do wrong, what you lose. This is what lets us sort forty comments into an order that matters.
4. Guess the bucket. "I think this is a spacing thing" or "this probably needs a new kind of card". You will guess wrong sometimes and that is fine — the guess tells us how large you expect the change to be, which is the fastest way to find a disagreement about scope.
5. Mark it as blocking or not blocking. A comment that must be resolved before launch and a comment you would like considered eventually are different work items. If everything is blocking, nothing is prioritised.

In our project history, no version of “make it pop”, “needs more energy”, “feels a bit flat” or “can it be more premium” has ever produced a change we shipped. Not because the reaction is wrong — it is usually correct, and it is usually the most important comment in the round — but because it names an emotion without naming a mechanism, so the only response available to us is to guess. We guess, you react to the guess, and a round of review is spent narrowing down what the original sentence meant.

The reason those comments feel so hard to make specific is that visual flatness is almost never caused by the thing you are looking at. It is caused by everything being the same: three text sizes that are nearly identical, four spacing values within eight pixels of each other, one weight of type doing all the work. Those are token problems, which is why the fix is usually cheap once it is named.

So when you feel the reaction and cannot locate it, say that instead: “this page feels flat to me and I cannot tell why — can you look at hierarchy?” That sentence is actionable. It hands us a diagnosis job rather than a mind-reading job, and it tells us the bucket is probably tokens, not new components.

These three are composites of comments we receive on nearly every project, with the rewrite that turned each one into work.

First: “The pricing section doesn’t feel trustworthy.” Rewritten, it became “On /pricing, the three plan cards look identical at a glance and I can’t tell which one we want people to choose — our sales team says everyone asks for the cheapest.” That is a component variant: a featured state for the recommended plan, with a badge, a heavier border and a lift in the card’s own background. One day, and it changed which plan people asked about.

Second: “The whole thing feels a bit corporate and cold.” Rewritten: “Every heading on the site is the same weight and the same colour as the body copy, so nothing feels like a voice.” That was two token changes — heading weight and a tighter heading line-height — applied across every page in about an hour. The reaction was about warmth; the mechanism was type hierarchy.

Third: “Can the case study pages be more visual?” Rewritten: “We want to show before-and-after screenshots side by side, with a slider, on every case study.” That is a new component: two images, a drag interaction, keyboard controls, a sensible fallback on small screens, plus documentation so your marketing team can add the next one without us. A week. Naming it as a week meant it got scheduled deliberately rather than absorbed into a review round and discovered late.

Collect all feedback in one place and send it once, at an agreed time, from one person. In our projects the single largest cause of stalled pages is not vague feedback but contradictory feedback arriving separately from three people over five days, where the second comment undoes the first and nobody on your side has seen both.

Nominate one person who owns the final call on the page. They do not have to have the best design taste; they have to be able to say “we are going with the first version” when two colleagues disagree. If your organisation genuinely cannot appoint that person, tell us early and we will schedule a live review instead, because asynchronous comments cannot resolve an internal disagreement.

Batch by page, not by person. A list of forty comments grouped under the eight pages they belong to gets worked through in a day. The same forty comments spread across four email threads takes three days, most of it spent reconciling.

Expect two rounds of review per page and treat the second as narrower than the first. Round one is for structure, order and content — the things that are expensive to change late. Round two is for tokens and detail. If round two raises a structural objection, that is a signal something went unsaid in round one, and it is worth a call rather than a comment.

Three kinds of feedback are worth pausing a page for: something is factually wrong, something is unusable for a real audience, or the page does not do the job it was commissioned to do. Wrong prices, an unreadable contrast ratio, a form your legal team cannot approve, a landing page that never states what you sell — those are stop-the-page comments and we would rather hear them loudly and early.

Everything else is a queue, not a block. Preference between two acceptable options, a change that only one person on a team of nine wants, a detail that will be invisible at the size a phone renders it — these are worth recording and worth revisiting after launch with real behaviour to look at, when you can see whether the thing you disliked actually costs you anything.

The distinction matters because a redesign has a fixed number of days in it. Every new component you add is roughly five token changes you will not get, and token changes are where most of the visible quality of a page comes from. Spending your feedback deliberately is the whole skill.