Feedback round one
The staging site goes to the client for review. Four days later a Word document arrives with twenty-eight numbered points. Point six says "the image on the services page looks odd". There are four images on the services page. Point eleven says "the menu doesn't work", and it turns out the client was on an old iPad with a browser that has not been updated. Point nineteen contradicts point four.
The project manager spends an afternoon turning the document into tasks, emailing back with questions, and waiting. The developer fixes what she can understand. The client's second round of feedback includes several points from the first round that were already fixed, because they were looking at a cached page.
Why staging feedback is so hard to act on
- Clients describe visual things in words, which is hard for anyone.
- Screenshots are cropped and do not show the page, screen size or browser.
- Several people at the client send feedback separately, sometimes contradicting each other.
- Feedback arrives as one big document, so small fixes wait behind big questions.
- Clients cannot see which points have been fixed, so they repeat them.
The client knows exactly what they mean. The information that would let the developer know it too is lost between the browser and the email.
What unclear feedback costs
Project managers become translators, and developers spend time guessing. Rounds of feedback multiply because points are misunderstood or repeated. Launches slip. Clients become frustrated that simple things take several goes, even though the delay is in communication rather than the work.
The staging feedback setup we build
- A small feedback script is added to the staging site only, never to live.
- Reviewers click on the element they mean and type a comment. The comment is pinned to that element.
- Each comment automatically records the page URL, a screenshot, the screen size, device and browser.
- Comments become tasks in your project tool, such as Basecamp, Asana, Trello or Jira, with all that detail attached.
- The project manager can merge duplicates, mark contradictions for the client to resolve, and flag points that are change requests rather than fixes.
- When a developer marks a task fixed, the comment on staging shows as resolved, so the client can see progress and check it.
- Each round of feedback is kept, so the history of what was raised and resolved is clear.
| Detail | In an email | With on-page comments |
|---|---|---|
| Which element | Described in words | Pinned to it |
| Which page | Sometimes | Recorded automatically |
| Screen size and browser | Rarely | Recorded automatically |
| Status of each point | Unknown to the client | Shown on the page |
| Contradictions | Found later | Flagged for the client |
Tools such as BugHerd and Markup.io do the commenting part well. If one fits, we set it up and connect it to your project tool and change log rather than building our own.
Round one with on-page comments
The client's team review the staging site over two days, clicking and commenting. The project manager gets tasks with screenshots, page and browser already recorded. The old iPad issue is spotted immediately from the browser detail. Two contradicting comments from different people are sent back to the client's lead to decide. The developer fixes the rest, the comments turn green, and the client checks them the same week.
Is your staging feedback like this?
- Clients send feedback as long emails or Word documents.
- Screenshots are cropped and missing context.
- Developers regularly have to ask what a comment means.
- Clients repeat points that have already been fixed.
- Feedback from different people at the client contradicts itself.