A lot of website work happens before there's a website. Sitemaps, wireframes, copy decks, brand guidelines and design exports all get reviewed as PDFs or images — and that review is often messier than anything that happens on staging.
Someone replies to the email with "see comments." Someone else prints it out. A third person pastes a screenshot into Slack with a red circle. By Friday nobody is sure which version the comments refer to, or which ones were dealt with.
Here's a cleaner way to run it.
Why document review goes wrong
Comments lose their location. "The second paragraph on page four" works until the layout changes. Then it points at nothing.
Feedback is spread across channels. Email, chat, sticky notes in a PDF reader, a call nobody minuted. Someone has to gather it all, and that someone is rarely billable while they do it.
There's no status. A comment in a PDF can't be assigned or marked done. So the designer works through the list from memory, and the reviewer checks the next version hoping their note was seen.
Versions blur. Feedback on v2 gets applied to v3, contradicting a decision made in between.
All four problems have the same fix: treat each piece of feedback as a trackable item pinned to a location, not as a sentence in a thread.
Pin feedback on the document itself
The simplest improvement is to let reviewers click the spot they mean and comment there.
In pinreview, your team uploads a PDF or an image (PNG or JPG) to the project and opens it in the review view. Clicking anywhere on a page drops a pin with a comment. Multi-page PDFs keep each pin on the right page, so "page four, second paragraph" becomes a pin on that paragraph.
Each pin becomes a task on the same Kanban board as your website feedback. That means design feedback, copy feedback and staging bugs all live in one place, with one set of statuses and owners.
A review workflow for documents
1. Upload one version per round
Upload the file for this round and name it clearly — "Homepage copy v2" rather than "final_FINAL.pdf." When the next version is ready, upload it as a new file. Comments stay attached to the version they were made on, which is exactly what you want when someone asks "didn't we already decide this?"
2. Give each reviewer a scope
"Please review" produces thin feedback on page one. Scoped asks work better:
- Copywriter: tone, clarity, calls to action
- Designer: hierarchy, spacing, type, image choices
- Developer: anything that will be hard or slow to build
- Project lead: does this match what the client signed off?
Four focused reviewers catch more than ten people told to "have a look."
3. One comment, one issue
A pin that says "font's too small, also can we swap this photo, and the date is wrong" becomes three pieces of work that get one-third fixed. Ask reviewers to split them. It feels slower and is much faster.
4. Triage like you would bugs
Once the round closes, go through the board:
- Merge duplicates — three people will flag the same headline
- Decide conflicts — the copywriter and the client disagree; someone with authority picks
- Set severity so the must-fix items get done first
- Assign an owner to everything that remains
Our guide to triaging on a Kanban board covers this routine in detail; it works the same for documents as it does for bugs.
5. Close the loop visibly
When a change is made, move the task to done. Reviewers can see their feedback landed, and the next round starts from a clean slate rather than a re-read of every old comment.
What to review as a PDF or image — and what not to
Documents are the right place for decisions that are cheap now and expensive later:
- Sitemaps and page structures, before any page is built
- Copy decks, before copy gets pasted into templates
- Wireframes and design exports, before development starts
- Brand guidelines and style tiles, before they spread into every page
- Print and PDF deliverables that ship as documents anyway
Once there's a working page, move review to the page itself. Feedback on a live build captures things a mockup can't: responsive behaviour, real content, interactions, browser differences. pinreview handles that too — pin comments on the page with the feedback widget or the browser extension, and everything lands on the same board.
Mockups vs the live site: close the gap
A common source of rework is the gap between the approved mockup and what gets built. Two habits help:
- Keep the approved mockup in the project so developers and reviewers can check against it.
- Review the build against it explicitly — spacing, type sizes, colours, states — and pin each difference on the live page.
That turns "it doesn't look like the design" into a list of specific, fixable items.
The bottom line
Document review fails for the same reasons website review does: feedback loses its location, scatters across channels and never gets a status.
Pin every comment on the spot it refers to, keep one version per round, and track each item on a board until it's done. With pinreview, PDFs, images and live pages all feed the same board, so design feedback doesn't live in a separate world from the rest of the project.