Use case · designers

Design review tool for live websites.

Review the page your users actually see — real content lengths, real fonts, real breakpoints. Every note carries the element in its rendered state, so “the spacing is off” arrives with the spacing attached.

The design was fine.
The page is what shipped.

reviewing a screenshot that was already out of date
“the spacing looks off” — on which element, at which width
comments in the design file that never reach the code
a layout that only holds together on placeholder content

Review the page itself.

Real content, real fonts,
real width.

1 · Open the running site

Not an export and not a copy of the design — production, staging, or a preview build. Whatever your users load, with the content lengths they actually get.

2 · Pin the element as it renders

The computed styles travel with the note: the colour that's actually applied, the font-size that's actually used, the padding that's actually there — not the value the design intended.

3 · Mark it a redesign, not a bug

Handoff has a severity for visual work, separate from breakage. Your notes stop being triaged as production incidents, and nobody has to decide whether “too tight” is a P2.

4 · The agent changes the code and answers

It finds the element by selector, makes the change and replies on the pin with what it did. You accept it or reopen it on the same page you left the note.

The note arrives with
the state attached.

A design note is only actionable if it says which element, in which state, at which width. Handoff captures all three, so the agent doesn't have to guess which card was too tight.

Claude Code · via MCP: “Card padding 12px → 20px and gap 8px → 16px in PlanCard.tsx, per the pin. Commit d8c114.”

A visual note, filed as visual work.

The last pin on this board is a Redesign — an empty state that says “no data”. It sits in its own severity, apart from the two bugs above it, and carries the element's computed styles so the rework starts from the real values.

Same board, same link. Severity is what separates rework from breakage.

What is a design review tool?

A design review tool is where someone checks an interface against what it was supposed to be and records what needs to change. The useful ones attach the change to the thing being changed, so the note survives the trip to whoever implements it.

Most of this work happens in design files, and for good reason — that's where the intent lives. But the artefact people actually use is the built page, and it differs from the design in ways only the page can show: content that's longer than the mock, a font that fell back, a breakpoint nobody drew, a state that only exists after data loads.

Reviewing on the live page closes that gap. Handoff pins the note to the element in the state it rendered, captures its computed styles and a screenshot, and hands it to the agent that will edit the code — with a severity that says “this is visual work”, not “production is broken”.

Questions

Do I need access to the code?

No. Handoff is a browser extension, so it works on any page you can open — including a client's site you have no repository for.

How is this different from commenting in a design file?

A design file holds the intent; this holds what shipped. The note is attached to a real element with its real styles, and it lands where the code gets changed.

Can I review a specific breakpoint?

Yes. Resize the window and pin there — the viewport is recorded with the note, so the agent knows which width you meant.

Will my notes be treated as bugs?

Not unless you mark them that way. Visual work has its own severity, so it can be filtered apart from breakage.

Does the developer need Handoff too?

Only if they want to leave pins. Reading works through a shared link, and an agent reads over MCP.

Review what shipped, not what was drawn.