Key Takeaways — brief reading, less than 30 seconds
- Which format a reviewer reaches for is usually decided by which tool they opened, not by what the feedback is.
- Match the format to the question: discussion-shaped feedback wants a comment, spatial feedback wants a markup, audit-bound feedback wants a structured annotation.
- Every format fails at scale in the direction of its strength, and the failure surfaces months later, when nobody who was in the room is left to translate.
- Pin the markup-plus-comment pair to the exact version reviewed, so round-3 notes still read correctly while round-4 is on screen.
- PDF-by-email survives exactly one round, because the redlines live on a snapshot that stops matching the working file the moment edits begin.
- Feedback belongs where the asset lives — in the DAM or review tool — not in the venue where the conversation happened.
Glossary8 terms
- Comment: Text attached to an asset or a region of it, usually threaded and replyable with @-mentions. Optimized for discussion and ambiguity, not for audit.
- Markup: A drawn mark on the asset itself — arrow, circle, redline, freehand stroke. Communicates location and visual intent fast, but carries no meaning without an attached note.
- Annotation: A structured pin with required fields like severity, category, status, owner, and due date. Higher friction to fill in, but produces a sortable, filterable audit trail.
- Redline: A hand-drawn or vector-drawn correction overlaid on a proof or PDF. Historically a print-production term; survives in legal and brand review as the default markup style.
- Threaded reply: A nested response under a parent comment. Keeps a single point of discussion together instead of fragmenting it into separate top-level remarks on the same asset.
- Anchor (pin): The coordinate or timecode a comment, markup, or annotation is attached to. A pinned anchor survives version changes only if the tool re-resolves it; otherwise feedback drifts off the asset.
- Version pinning: Locking feedback to the specific version it was given on (v3, not “the design”). Required so the designer can read round-3 notes in context while working on round-4.
- MLR (medical/legal/regulatory review): The structured sign-off process used in pharma, finance, and other regulated industries. The reference example for why annotations exist: classification and audit trail outrank reviewer convenience.
Editor's note: This article is the “how to deliver feedback” companion to the earlier piece on what feedback to give. The format choice changes whether the next round of work uses the feedback or has to ask what it meant.
Frame.io calls it the Annotation tool. Acrobat calls it a markup. Figma calls it a comment. All three produce a mark next to a picture, and none of the three means the same thing when the campaign is audited a year later. A comment is a remark — text that wants a reply. A markup is a mark made directly on the thing, an inheritance from the print-shop redline. An annotation, in its older sense, is a note added to a record — structured, classified, kept for later. Three words, three different jobs, and using them interchangeably is how a revision round quietly goes wrong.
The sister article covers what to say; this one covers how to deliver it. The format choice is the part most teams under-think.
The Three Formats Defined#
- Comments. Threaded, replyable text attached to the asset or a region of it — think Figma(opens in new tab), Google Docs, or a GitHub PR review.
- Markups. Marks drawn directly on the asset — the red lines, arrows, and circles of Frame.io drawings and Adobe Acrobat(opens in new tab) redlining.
- Annotations. As this article uses the term: structured pin-and-text with required fields like severity, status, and owner — the shape review takes in regulated settings such as pharma MLR and accessibility audits.
One honest caveat before the taxonomy does any work: in some review tools, “annotation” just means the drawn mark — Frame.io literally names its drawing feature the Annotation tool(opens in new tab), and Filestage uses the word the same way. This article uses the narrower, older meaning: a note attached to a record, with fields you can sort and audit by. The vendors don’t keep that distinction; the distinction is still the useful one.
The three formats look interchangeable because they all put a note next to the work. They behave differently because each encodes one thing well — a comment holds the discussion, a markup holds the location, an annotation holds the classification — and whatever the format doesn’t encode has to survive in somebody’s memory.
When Each Format Wins#
Comments win for nuanced feedback. “The tone here feels off, but I’m not sure why” is a discussion, not a directive. The thread gives the brand lead room to hedge and the designer room to ask follow-ups, so the ambiguity gets worked out in replies instead of being flattened into an instruction nobody actually meant.
Markups win for precise spatial feedback. “Move this 4px left,” “the negative space here is wrong,” “the eye should land on this element first.” The visual directness of a circle plus an arrow communicates faster than a paragraph of text. Low cost to produce, immediate to read.
Annotations win for high-stakes review. Legal review, MLR, brand governance, accessibility audits, regulatory sign-off. The audit trail matters more than the convenience. The reviewer who fills out a structured annotation accepts the friction because the structure is the point — future reviewers can filter, sort, and prove the review happened.
The signal that decides which format: how much of the feedback is about WHERE on the asset, vs WHY about the asset, vs WHO has signed off. A markup answers where, a comment answers why, and an annotation answers who and under what category.
How Each Format Fails#
Each format’s strength is also its failure mode at scale.
Comments lose context. The reply chain reads fine in the moment; six months later, “we said it’s fine” doesn’t reveal what was actually fine, which version it referred to, or whether the concern underneath it was resolved or just abandoned when the thread moved on. The original ambiguity persists into the audit trail, and every reader after the fact inherits it. The thread is intact; the signal isn’t.
Markups lose meaning. A month later the arrow is still on the frame and nobody can say whether it meant “move this” or “delete this,” because the only place that was said was out loud. A markup without an attached comment is a riddle for whoever picks up the project after the original team rotates off.
Annotations create friction. Required fields slow people down, so reviewers tend to either skip the system or fill required fields with placeholder text until the audit trail is technically complete and practically empty.
The team that picks one format and uses it for everything ends up failing in that format’s specific way.
The Hybrid That Works#
Markup for spatial feedback plus text comment for the why, attached together. The markup says where; the comment says why and what. The combination preserves both the visual specificity and the verbal context, and the asset reads sensibly to anyone who picks it up later. This isn’t a novel proposal — Frame.io’s documented flow already pairs the note and the drawing into one submission.
The non-negotiable: pinned to the version of the asset that was reviewed. The annotation, comment, and markup all stick to v3 of the design. When v4 lands, the previous round’s feedback stays visible in context. The designer who reads round-3 feedback while working on round-4 sees what was said about the version they’re responding to, not a generic comment that could mean anything across versions.
Feedback pinned to version is what makes the next round actually productive; the version-control article covers the design side of that pairing. The broader review-and-approval-process article covers where this hybrid fits in the workflow as a whole.
The Default Most Tools Settle For (and Shouldn’t)#
Most teams fall back to “PDF with hand-drawn redlines emailed around.” For a single review it does the job, which is exactly why it survives — and it fails to scale for predictable reasons.
- The PDF isn’t the file the designer edits. The audit is gone the moment the designer makes the changes — there’s no link from the annotated PDF to v4 of the source file. The redlines were on a snapshot; the snapshot diverges from the working file the second the designer opens it.
- Email loses the audit trail. Same problem as the Slack-approval anti-pattern. The thread scrolls, the attachment versions multiply, the canonical “here’s the approved redline” gets buried.
- Hand-drawn redlines are markups without comments. Meaning dies with the meeting where they were drawn. When the agency rotates the account team, the redline-on-PDF is unreadable to anyone who wasn’t in the original room.
- PDF annotations are fragile across viewers. Notes made in one app go missing or turn invisible when the file is opened in another(opens in new tab) — if a PDF redline has to survive an audit, test your exact viewer path before relying on it.
The PDF-by-email default isn’t wrong for tiny teams or one-off reviews. It’s wrong as the standard pattern at any team that ships work regularly. The same artifact-vs-venue logic that makes Slack the wrong place for approval makes email the wrong place for feedback. The thing under review is the asset, so the record of the review has to live wherever the asset lives — not in whichever inbox the PDF happened to land.
The fix is the hybrid above: markup plus comment, version-pinned, in a tool designed to keep both. Frame.io, Wipster(opens in new tab), Filestage(opens in new tab), ReviewStudio(opens in new tab), the modern DAM’s built-in review surface — any of these are built around the artifact rather than the message, which is the property that matters here. The Creative Ops DAM we build takes the same position: comment, markup, version, and approval stay one record next to the file. The team that defaults to PDF-by-email instead finds the redline lives in an email attachment, so the next campaign starts by asking three people to search their inboxes.
None of the three formats is “the right one,” because each encodes a different signal — where, why, who-signed-off — and a real review surface carries all three. Pick a format by what the feedback is actually saying, not by which tool the reviewer happens to open first.
The decision the reader walks away with is small: the next time a reviewer drops a hand-drawn redline into a PDF and emails it around, ask them to do it inside the review tool instead, with a comment attached to the markup, pinned to the version. Once that becomes the habit, the feedback is still attached to the file when the next round — or the next team — goes looking for it.
Frequently Asked Questions #
Isn’t an annotation just a drawn mark?
When do I use a comment vs an annotation?
Are markups the same as redlines?
Do annotations live with the file or in the DAM?
What’s wrong with email feedback?
How do Figma, Frame.io, and Acrobat handle feedback differently?
Can a small team get away with one format?
