How to give design feedback that actually gets actioned
Vague feedback bounces. Specific, anchored feedback ships. Seven rules for writing review notes a designer or engineer can act on without a single follow-up question — and how to make each one automatic.
Most feedback isn’t ignored because people are lazy. It’s ignored because it’s unactionable — too vague to start on, or missing the one detail that would make the fix obvious.
Good feedback has a simple property: the person receiving it knows exactly what to change, where, and why. Here are seven rules for writing it — and, for each, the shortcut that makes it automatic instead of a discipline.
1. Point at the thing, don’t describe it
“The header feels cramped” forces the reader to hunt for the header, guess which screen, and infer what “cramped” means. A pin on the actual element removes all three guesses at once — and it stays anchored to that element even after the layout changes.
2. Say what, not how (usually)
Lead with the problem you observed, not your proposed solution:
- Weak: “Make this button blue.”
- Strong: “This button doesn’t read as the primary action — it competes with the one next to it.”
The second version gives the designer room to solve it well. Save prescriptive fixes for when you genuinely know the constraint.
3. Anchor it to a screen and a state
Feedback without context is unreproducible. Always carry the URL or screen, the device or breakpoint, and the state (logged in/out, empty/full, error).
This is exactly the part you shouldn’t have to do by hand. A pin records the page, browser, screen size, viewport, colour scheme and the exact element for you — the full capture list is automatic on every plan.
“It’s broken” is a feeling. “It’s broken on mobile Safari when the cart is empty” is a ticket.
4. One comment, one issue
Bundling five problems into one paragraph guarantees three get missed. Split them so each can be tracked, assigned and resolved on its own. When every pin is already a separate issue with its own status and owner, this happens by default instead of by willpower.
5. Separate blockers from nits
Tag the difference. A typo and a broken checkout flow should never have the same weight, or your reviewer will either over-react to the typo or under-react to the checkout. Priorities — Low, Medium, High, Urgent — do this explicitly, and on Pro, AI triage even suggests one for you to confirm.
6. Make it resolvable
The best feedback has a clear “done” state. “Tighten the spacing to 8px” can be closed. “Make it feel more premium” can’t — so pair the vibe with something concrete. A status lifecycle (To do → In progress → In review → Done) only works when each item can actually reach Done.
7. Keep the thread where the work is
When feedback lives next to the design instead of in a separate doc, nobody loses the context and nobody re-explains it. Threaded replies and @mentions resolve in real time, so the conversation stays attached to the pin — that’s the whole reason Pogpin anchors comments to the object itself, whether it’s a web page, a PDF, an image or a video frame.
Feedback that arrives ready to act on
The through-line of all seven rules is the same: remove every guess between noticing and fixing. You can do that with discipline — a checklist every reviewer follows — or you can let the tool carry the context so a rushed comment from a client is still a complete, reproducible issue.
Action-ready feedback isn’t about being nicer or more detailed. It’s about closing the gap. Start free and see how much of rule 3 disappears when the context comes along for free.