Figma Comments vs Comments on a Live Page

Figma comments and on-page comments look like competing answers to the same question. They are answers to different stages of the same project. Getting the handoff point right removes a category of review confusion that most teams live with permanently.

The Problem

Two failure modes, opposite causes.

Reviewing a build in Figma. The page is coded. Feedback arrives on the design file. The file has since diverged from the build — real copy replaced the placeholder text, the data is longer than the mock, a component got reused. Now every comment needs translating, and some do not translate at all because they refer to something that no longer exists in the build.

Reviewing a design on a staging URL. Someone comments on the built page about a decision that belongs in the design file, so the fix happens in code and the file stays wrong. Six weeks later the next person builds from the file and reintroduces the problem.

Both come from the same missing decision: nobody said which artifact is the source of truth right now.

What Each One Is Good At

Figma comments

Strengths.

• They sit on the source of truth during design. The comment is next to the layers being discussed.
• Reviewers see structure — components, variants, spacing tokens — which is exactly what design-stage feedback is about.
• Designers are already there. No context switch.
• Comments can address alternatives that exist in the file and nowhere else.

Limits.

• A Figma prototype approximates browser behaviour rather than running it. Text reflow, real font rendering, scroll behaviour, and viewport edge cases are all browser output.
• The content is mock content. Real data is longer, shorter, missing, or weird, and that is where layouts break.
• Non-designers find the interface intimidating, so feedback from clients and stakeholders is thinner than it would be on a web page.
• Nothing in the file tells you whether the build matches it.

On-page comments

Strengths.

• The artifact is what will ship. Real fonts, real reflow, real data, real browser.
• Reviewers need nothing installed and no design-tool literacy — a link opens in any browser, which is why client and stakeholder participation is markedly higher.
• Anyone with the link can open and click through it without an account.
• Mobile review is trivial: open the link on a phone.
• Interactive bugs surface, because reviewers can click, type, and resize. Most of these are invisible in a design file by construction.

Limits.

• Nothing exists to comment on until something is built.
• Feedback that should change the design system arrives against a page rather than against a component.
• It does not replace the design file as documentation.

On Undraft, on-page comments are pinned to elements on the live page, and each upload is kept as a version with its own comments — so a revised build does not overwrite what was said about the previous one.

Where the Handoff Goes

The rule is one sentence: comment on whichever artifact is currently the source of truth.

In practice:

Stage	Source of truth	Comment where
Exploring directions	Figma	Figma
Refining a chosen direction	Figma	Figma
Build in progress	Code	The built page
Client sign-off on the build	Code	The built page
Post-launch iteration	Code	The built page

The transition point is when code becomes the thing that defines the product. After that, the design file is documentation — valuable, but no longer the thing being reviewed.

Two rules make the handoff stick:

Announce it. “Design is locked, review is on the staging link from here.” Without this, both channels stay open and you spend your time reconciling them.

Route system-level feedback back. If a comment on the build reveals a component problem rather than a page problem, take it to the design file explicitly. Otherwise the fix lives in one page’s CSS and the next build repeats the mistake.

Examples

Before

1. Design approved in Figma. Development starts.
2. The client is sent the Figma prototype for sign-off, because that is the link that exists.
3. They comment on it — including two notes about text that has since been rewritten in code.
4. The developer reconciles Figma comments against a build that has moved.
5. A layout bug at 375px is found by a user after launch, because the prototype never rendered in a browser.

After

1. Design approved in Figma. Comments there are resolved and closed.
2. Development starts. The team announces that review moves to the build.
3. The build is hosted and the link goes to the client.
4. The client opens it on desktop and phone and pins five comments — one of them the 375px overlap.
5. One comment turns out to be a component issue and is taken back to the design file explicitly.

The bug that shipped in the first version is caught pre-launch, by someone on a phone.

Summary

• Comment on whichever artifact is the source of truth — Figma during design, the build once code defines the product.
• Announce the handoff so both channels are never open at once.
• Avoid client sign-off in a design prototype — real fonts, real data, and real browser behaviour only exist in the build, and that is where the expensive surprises are.

Next: see how on-page review works — comment on a webpage — and how to share an HTML file so reviewers can open the build.