One of my favorite things about Figma prototypes is how easy it is to comment directly on a section — click the spot you mean, leave the note, done. My prototypes moved past click-through mockups a while ago though. They're coded, running on real generated data, simulating an actual workflow instead of a fixed set of screens. That's a better review for stakeholders — they watch the thing actually run.
But I lost that Figma-style commenting the moment I left Figma. So I had to figure out how to build that same feedback loop for a live prototype: point at a section, leave a comment, and have it mean something even though the section isn't a fixed frame anymore.
What This Actually Unlocks
A stakeholder hits something confusing mid-workflow. They click the feedback button, point at the exact section, and write what they're thinking — right then, without switching tools, losing their place, or trying to describe a screen from memory later in a meeting. The tool stores a snapshot of exactly what they were looking at alongside the comment, so nothing about it is reconstructed afterward.
Multiply that by a handful of stakeholders clicking through the same workflow independently, and the log becomes something more than a pile of comments. Every entry already carries a section, a category, a viewport, and a build — which means the qualitative feedback is quietly structured data the moment it's written, not after someone spends an afternoon coding it by hand.
How It Works
Five moments happen behind every comment, in order, without the reviewer doing anything extra.
Every comment moves through all five, automatically, the moment someone points at something.
Point
One button, present on every page, on every step of the workflow. Click it, and the page changes behavior — as you move your cursor, whatever section it's over outlines itself and shows its own name. Click the one you mean, and that's the whole interaction. No describing where you are in words, no switching to another tool to leave the note.
The idea is the same one Figma trained everyone to expect from commenting on a frame — point at the thing, not a description of it. The difference is what's underneath the cursor: not a static image, but the actual workflow still running while you point at it.
Hovering outlines a section and shows its name. Everything else stays dim until you point somewhere else.
Resolve
Here's the part that has to happen invisibly for step one to feel simple: a click never lands on “a section.” It lands on one small piece buried inside it — a bar in a chart, a line of text, a single pixel of something bigger. Left alone, that's useless feedback. Nobody wants a comment that says “the user clicked a rectangle.”
So the tool doesn't trust the exact spot you clicked. It looks outward from it — past the chart bar, past the chart itself, past its container — until it finds something that actually has a name: a card, a panel, a named piece of the interface. That's the label that gets attached to the comment. It also knows when to stop, so it never mistakes the whole page for “the section” either.
The dot is the click — four elements deep inside a chart. The tool climbs outward until it finds something with a real name, and stops there.
Capture
This is the part that makes it worth more than a written comment. The instant someone points at a section, the tool doesn't just note which one — it remembers exactly what that section looked like at that moment. Not a description written from memory. The actual thing, preserved.
That matters because the prototype is alive. Numbers update, charts redraw, states change — the same section can look different five minutes later. Without a captured moment, “the chart looked wrong” becomes unanswerable the second the data moves on. With one, I'm never reconstructing what someone meant. I'm just looking at it.
The live chart keeps moving after this. The captured one never will — it stays exactly what the reviewer saw.
Store
Every comment, with its section and its captured moment, gets saved straight into the project itself — no separate feedback tool to log into, no spreadsheet living somewhere else that falls out of sync. It becomes part of the same place the work already lives.
That's a small decision with a real effect: the feedback never becomes its own chore to maintain. It just accumulates alongside the build, in order, as its own quiet timeline of what people noticed and when.
Reviewer submits
in the app
Saved to the project
no separate service
Every comment becomes a line in the project's own history — nothing external to check on separately.
Replay
Reviewing feedback later means opening a log where every entry still shows exactly what its author saw — same size, same layout, nothing reflowed into a shape nobody actually looked at. It doesn't matter if the live prototype has changed completely since; the entry hasn't.
And because what's stored is a captured moment rather than a live piece of the app, opening an old entry is always safe. It's a picture, not a door back into the running prototype.
Feedback log
“This chart reads like it's trending down but the table says otherwise”
renders exactly as captured — same size, same layout, still inert
From a Pile of Comments to a Prioritized Backlog
A single pointed comment with a snapshot attached is already more useful than a paragraph in a meeting recap. But the real payoff shows up once several stakeholders have gone through the same workflow and the log starts accumulating entries against the same sections.
Because every entry already carries a section and a category, you can group them without reading through the whole log by hand. Six people flagging the same section independently, without having seen each other's comments, is a much stronger signal than any one comment on its own — that's qualitative feedback turning into a quantitative “this needs fixing first,” automatically, just from how the entries were structured going in.
23 comments → grouped by section × category
Six people flagged the same section without reading each other's comments — that's a signal, not six separate tickets.
From there, turning a hotspot into a backlog item is mostly a copy: the section name and snapshot become the ticket's description and evidence, the report count becomes its priority signal, and the conversation that used to happen across three people's memories in a standup happens instead by reading the entry.
Feedback entry
“Can't tell if the swap request went through”
Shift swap modal · 390px · 4 reviewers
Backlog item
Add confirmation state to shift swap modal
Why I Think This Beats a Click-Through Review
A click-through prototype tells stakeholders what a screen looks like. This tells you what happens when real people run a real workflow against it, in the moment they notice something worth flagging — pointed at the exact section, with a snapshot of exactly what they saw, structured well enough to roll up into priorities without anyone doing that work by hand afterward.
That's a different kind of review. Not “does this screen look right,” but “does this workflow hold up when people actually use it” — with the feedback loop built to keep up with a prototype that's actually alive.
The Build Notes
After I got the tool working, I wrote up exactly how it's put together — the real architecture, the actual code, and every gotcha that came up along the way, including the ones that cost me a round of rework. I kept it as documentation in the project itself, mostly so I wouldn't have to relearn my own decisions six months later. It's more technical than anything above; it's here for anyone who wants the underlying detail.
Read the original build notesExpand ↓Collapse ↑
Loading…
Built for a scheduling prototype, written up because the idea outlasted the project.