Put the work in front of the client, and let them point at exactly what they mean.
01 Feedback on the thing itself, not in a spreadsheet
Design and build review usually happens at arm’s length — screenshots pasted into a doc, a list of comments that no longer line up with the screen they describe, a thread where nobody is sure which version they are looking at. The feedback and the work drift apart, and reconciling them is its own job.
Proof closes that gap. It serves the actual artefact — composed wireframes, or a live preview environment proxied through — behind a simple login, and injects a feedback widget into every page. Reviewers pin a comment directly onto the spot they mean, grab a screenshot, and carry on a thread in place. Each view keeps its own set of notes, so a tabbed artefact or a multi-slide deck never muddles one screen’s feedback with another’s.
Then it syncs every note back into the repo as markdown, where the people building the work already live. We built it to run our own client reviews, and it is the base image our project previews are served from.
02 Review where the work actually is
Pin-point annotations
Reviewers click the exact element they mean and leave a comment there — with a screenshot — instead of describing it from memory in a separate document.
Per-view threads
Comments key to the page and the view you were on, so a deck, a tabbed layout or a preview route each carry their own feedback without cross-contamination.
Synced to the repo
A sync step exports every annotation and answer to markdown in the repository, so client feedback lands next to the code that has to act on it.