Key Takeaways — brief reading, less than 30 seconds
- Three feedback formats encode different things. Comments encode discussion; markups encode location; annotations encode classification.
- Comments win for nuanced feedback. Markups win for precise spatial feedback. Annotations win for high-stakes audit-required review.
- Each format’s strength is also its failure: comments lose context, markups lose meaning, annotations create friction.
- The working hybrid is markup + comment, version-pinned. The markup says where; the comment says why and what.
- PDF-by-email is the default most teams settle for. It works once; it fails to scale because the audit dies the moment the designer makes the changes.
- The same artefact-vs-venue logic that makes Slack the wrong place for approval makes email the wrong place for feedback.
Glossary8 terms
- Comment: Text attached to an asset or a region of it, usually threaded and replyable with @-mentions. Optimised 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.
In a review meeting the three words get used as if they meant the same thing. Someone asks for your comments, drops a markup on the proof, and files an annotation, and the assumption is that they’re all just “feedback.” They aren’t. 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; 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. Text attached to a region of the asset, or to the asset as a whole. Threaded, replyable, often with @-mentions. Examples: Figma(opens in new tab) comments, Google Docs comments, GitHub PR review comments. Low friction; designed for discussion.
- Markups. Drawn directly on the asset — red lines, arrows, circles, freehand. Visual, low friction to give. Examples: Frame.io video markup, Adobe Acrobat(opens in new tab) redlining, image-annotation tools that let reviewers sketch directly on the image.
- Annotations. Structured pin-and-text, often with required fields: severity, type, status, owner, due date. Higher friction to produce; better audit trail. Examples: pharma MLR systems, accessibility audit tools, regulatory review platforms, structured QA tools.
The three formats look interchangeable because they all answer “the reviewer wants something different here.” They behave very differently because they encode different things. Comments encode discussion; markups encode location; annotations encode classification. Choosing the wrong format for the feedback you’re giving is a quiet way to make a revision round fail.
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. Comments thread; replies hedge; the team works through ambiguity together. The brand lead who’s not sure about the headline gets a working conversation; the designer gets context that a markup couldn’t carry.
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. Comments answer why; markups answer where; annotations answer who and 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. The original ambiguity persists into the audit trail. The thread is intact; the signal isn’t.
Markups lose meaning. Six months later, “what does this red arrow mean?” has no answer. The visual was clear in the room where it was drawn; the visual is opaque outside it. 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 either skip the system entirely (the work goes back to comments-on-Slack, the audit trail evaporates) or fill the fields with “n/a” and “TBD” until the audit becomes performative. The structure that earns the trust at audit time is the same structure that drives reviewers out of the system at routine-use time.
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.
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.” It works once. 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. Six months later, the redline-on-PDF is unreadable to anyone who wasn’t in the original room.
- PDF annotations break across tools. Adobe Acrobat to Adobe Acrobat works; Acrobat to Foxit to designer’s Preview app produces lost annotations, broken layers, missing comment threads.
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 artefact-vs-venue logic that makes Slack the wrong place for approval makes email the wrong place for feedback — the artefact is the asset, not the message; the system of record is the DAM or the review tool, not the inbox.
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 them solve the artefact-vs-venue problem if the team adopts them as the standard pattern. The team that adopts the hybrid ships campaigns with auditable feedback that the next team can use; the team that defaults to PDF-by-email ends up with a thousand annotated PDFs and no canonical history.
The three formats aren’t a menu where one of them is right. They’re three different encodings of three different signals — where, why, and 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. One round of that habit is the difference between feedback that survives the project and feedback that dies with the meeting.
Frequently Asked Questions #
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?
