How to Leave Feedback on a Design Project
TL;DR
In this guide
- Use the current review link. Keep comments attached to the design or staging page.
- Write one actionable item. Include the location, concern and intended result.
- Check the revision. Confirm the outcome before closing the comment.
Leaving feedback on a design project is easier when each comment stays with the work being reviewed. Figma is used for design review; SureFeedback can attach notes to a staging website during development. This guide explains the review workflow and the information to include.
The guide at a glance
Choose the right review context
01
Design in Figma
Comment on the current frame and the exact element you mean.
02
Website on staging
Report the page, device and steps needed to reproduce a build issue.
03
Check the revision
Review the updated version and confirm whether the concern is resolved.
Write a comment the team can act on
Identify one issue per comment. For copy, supply the exact replacement wording. For a design concern, explain the intended communication or visitor task. For a technical issue, describe what you did, what happened and what you expected.
A useful report is: On the Services page on a phone, I open the second accordion and the enquiry button covers the final paragraph. The text should remain readable above the button. Screenshot attached. This gives the team a specific condition to check.
Use the project link and current version
Open the design file or staging URL shared for the review. Check that it is the current version before adding comments. Figma comments belong beside the relevant frame or component; website comments belong on the page being tested.
Tool access and controls depend on the permissions provided for your project. If you cannot view or comment, send the link and explain the access problem to the project contact. Avoid creating a second disconnected review document unless the team agrees it is needed.
Keep the review record clear
Gather comments from the people who need to approve the work. Resolve contradictory instructions internally, then send one direction. A content correction, a design preference and a new feature request have different implications; label them clearly.
After a change is made, return to the updated page or frame. Check the original concern and any related behaviour. A comment marked complete is most useful when the result has actually been reviewed.
A compact feedback format to copy
- Where: current page or Figma frame, and the affected element.
- Concern: the information or behaviour that needs attention.
- Expected result: what the visitor should understand or be able to do.
- Evidence: screenshot, exact replacement text or reproduction steps.
- Priority: prevents approval, important correction or suggestion.
For the reasoning behind useful design feedback, see how to give useful feedback on website designs. That article focuses on judging the work against its brief; this page focuses on keeping the review in the right tool and version.
Put it into practice
Before sending the review
- Use the current project review link
- Name the affected page, frame or element
- Include replacement wording for text corrections
- Describe device and steps for a website issue
- Consolidate comments from the approving stakeholders
- Check the revised work before closing the item
Keep in mind
Keep the evidence with the issue
A screenshot helps locate a problem, but the steps and expected result explain how to reproduce and resolve it. Include both when reporting website behaviour.
Common mistakes to avoid
- Writing “make it better” without identifying the concern
- Combining several unrelated requests in one comment
- Commenting on a superseded design or staging version
- Closing a reported issue before checking the revised result
