Design feedback: how to give it to a developer

“Something is off, make it livelier” is the most expensive edit in a project. The developer guesses what you meant, redoes the work, shows it again, and the loop repeats. Time goes not into the work but into trying to understand each other.

Good feedback on a mockup or a test version of a site does not require design knowledge. It needs specifics, one place for comments, and an understanding of what can change at which stage. Below is how to set that up.

What exactly is wrong

Describe the problem, not a ready-made solution. “The phone number in the header is hard to see on the light background” is more useful than “make the phone number red.” The developer may know a better fix, but only if they understand what gets in the way.

  • Where: the page and the block, ideally with a screenshot
  • What is there now: how it looks or works
  • What is wrong: what bothers you or a client
  • What it should be, if you know for sure

One place for comments

Edits scattered across a messenger, email, and voice notes get lost. One contradicts another, a third stays in a chat nobody rereads. It works better to collect everything in one document or in comments on the mockup and send it as one list.

If several people approve the site, agree among yourselves first. The developer needs one final list, not three opinions to choose from.

Look at it on a phone

Most visitors will see the site on a phone, yet it is usually approved on a large monitor. Open the test version on your own phone and check how the text reads, whether the buttons are easy to tap, and whether anything scrolls sideways. Comments made on a phone often matter more than those made on a computer.

Taste versus the task

A color you personally dislike and a button a client cannot find carry different weight. The first can be discussed, the second has to be fixed. It helps to ask: does this edit help a visitor do what the site is for, or is it a matter of taste?

Taste matters too, the owner should like the site. It is just better to group those edits and discuss them separately rather than mix them with actual errors.

Stages and what to change when

Structure and block order are cheapest to change at the mockup or page outline stage. Once pages are built and filled, moving sections around means redoing work. So raise big questions early and leave small ones, such as spacing and wording, for the test version.

The number of revision rounds is usually stated in the quote. If it is not, ask in advance. An edit that changes the task, such as a new section or a different request flow, is further development with its own estimate.

A short checklist before sending

  • Every edit has a page address and a spot on that page
  • The problem is described, not only the desired result
  • Edits are collected in one place as one list
  • Disagreements between approvers are resolved
  • The test version was reviewed on a phone

How many revision rounds are included shows up in the quote, as the note on what a site costs explains. How to keep copy edits from turning into endless back and forth is in the note on website copy. To start a project, use the contact form.