How to give website feedback that ends the project

Building a website involves a series of decisions, and they are yours. The developer proposes, you respond, and the project moves forward. How well you respond has a large effect on how long it takes and how many rounds of changes it needs. This is a practical guide.

Agree who decides

Choose one person to give final feedback for the business. If three partners each send separate comments that disagree, the developer cannot proceed, and each conflict adds days. Collect opinions inside the business first, and send one set of notes.

Say what you want, not only what you dislike

“I don’t like it” is hard to act on. “The phone number is hard to find on my phone; I want it at the top of every page” is easy. Try to say:

where (the page, the section, the screen size);
what you see;
what you would like instead, or what problem it causes.

Screenshots with a circle or an arrow help more than a paragraph. Use the page address and a name for the section.

Sort your notes into three kinds

Mistakes. The text is wrong, a link is broken, a price is wrong. These should be fixed without argument and without using up a revision.
Preferences. You would like a different colour or layout. These are what revision rounds are for.
New requests. Something not in the agreed scope: a new page, a new feature. These are outside the revision allowance and may need a new quote.

Telling these apart helps both sides. A developer who sees a preference labelled as a mistake can be unfairly blamed, and a new request disguised as a revision is how projects overrun.

Group changes into rounds

Send all the changes for a stage together, rather than one at a time. Each round costs setup and testing time. My packages include two revision rounds on the design direction, and what happens beyond that is stated in the proposal. A round is a set of changes, not a single change.

Reply on time

Many delays are waiting for approvals and content. Agree a reply time at the start, such as two working days, and say if you cannot meet it. If you are away, say when you will be back.

Check the content before you approve

Read every word and check every number, name, phone number and address on the pages you approve. Mistakes found after launch cost more to fix than mistakes found in a draft. If someone else knows the facts, such as a technical figure, let them check it.

Do not approve what you have not looked at

Look at each page on your phone as well as your computer. Click every button and link. Ask for the staging address, which is the version of the site not yet public, and test on a real device.

A worked example

Weak feedback. “The home page needs to look more professional. Also change the products page. Also my partner wants a blue theme.”

Useful feedback. “Home page: (1) make the phone number larger at the top on phones; (2) replace the photograph in the second section with the factory photo I sent on Monday; (3) the heading says 24 products, we have 28. Products page: this is a new request, I want a separate page for each product size. Please quote it. Colours: we have not agreed on blue, I will confirm by Friday.”

The second set is clear about what is a fix, what is a preference, what is new and when the missing decision will arrive.

The end of the project

When you are satisfied, say so in writing. Approval starts the support period in your package. For what to expect then, see what you should receive when the website is finished. To start a project with clear stages and a written proposal, message or call Harman.