How to write useful feedback on shared notes and drafts

Useful feedback helps the owner understand what needs to change and why. It can be direct without being dismissive, detailed without rewriting the whole project, and specific without dictating a solution that the reviewer is not qualified to choose.

The same principles work when reviewing instructions, a draft message, a plan or a creative deliverable. This guide is written for the person receiving a shared project link and PIN, including clients, teammates, collaborators and other recipients.

Begin with the review request

Read what the owner asked you to check. They may want a factual review, a direction choice or approval of a final version. Focus on that scope before adding broader suggestions.

If the request is unclear, ask what decision is needed. It is better to clarify than to spend time polishing details that are still provisional.

Check whether the owner identified placeholders or unresolved assumptions. A provisional event date should not be treated as an error if the review is only about the invitation structure.

Confirm the version you are reviewing

Open the named task and published version. In Draftnod, comments and decisions belong to the version being reviewed, which helps preserve context across revisions.

If you received an external file link, check whether it points to a live working document or a reference copy. Its contents can change independently from the Draftnod version. Ask for clarification when the note and file do not match.

The version history guide explains how to interpret change summaries and older comments.

Describe the issue before proposing the fix

Start with what you observed. “The instructions mention a building entrance but do not name it” is more helpful than “This is confusing”. Then explain what that could cause: a participant may arrive at the wrong door.

If you know the required correction, include it. If you do not, describe the outcome needed and let the owner determine the solution. A reviewer may understand the audience's needs without owning the design or implementation.

A precise comment might say:

In version 1, the arrival section does not identify the entrance. Please add the entrance name or a recognizable landmark so a first-time visitor can find the room.

The comment gives the owner an observable problem and a useful completion criterion.

Separate factual corrections from preferences

A wrong time or missing requirement is different from a personal preference about phrasing. Label the distinction. The owner can prioritize a factual correction more confidently when it is not mixed with optional style suggestions.

Explain the reason for a preference when it affects the audience. “Use a shorter opening because participants will read this on a phone just before arrival” is stronger than “Make it punchier”.

Avoid presenting personal taste as a universal rule. If several reviewers disagree, the owner needs to understand the reasons and ask the responsible decision maker to choose.

Identify blockers without making everything urgent

A blocker prevents the material from being accepted or used. An optional suggestion may improve it but does not necessarily require another review cycle.

Use a simple priority convention if the group agrees:

• Blocking: an incorrect fact or missing instruction that prevents use.
• Important: a change that materially improves understanding.
• Optional: a preference or enhancement that can wait.

Do not label every comment blocking. If the owner cannot identify the real obstacle, prioritization becomes another task.

The approval workflow guide describes how comments and saved decisions fit together.

Keep feedback respectful and actionable

Review the work rather than the person. “The summary does not state the next action” points to a fix. “You never explain things clearly” does not.

Quote a short phrase or name a section so the owner can find the issue. Keep comments focused: one comment can cover related details, but avoid mixing unrelated corrections into a long paragraph.

For guidance on clear headings and wording, see W3C's accessible writing tips. The same practices that improve a note also improve feedback about it.

Use the decision controls deliberately

When a published version is awaiting review, Draftnod's existing controls let you approve the version or request changes and save the decision. Use them when the owner asked for a decision, rather than assuming a positive comment closes the review.

Approval should reflect the version and scope you actually checked. If you only reviewed the dates, do not imply acceptance of unrelated content or external commitments.

If changes are required, include enough detail for the owner to understand what would make the next version acceptable. The asynchronous feedback guide provides a review pattern for people working on different schedules.

A feedback checklist before you save

Ask whether your comment identifies the version, the location, the problem and the desired result. Check that any factual correction is supported by the relevant source or actual project information.

Remove repeated comments that say the same thing in different ways. Consolidated feedback is easier to act on than a stream of overlapping suggestions.

If you cannot review by the agreed time, tell the owner rather than leaving the status ambiguous. The task can remain pending until a real decision is made.

Review the revision with the same scope

When the owner publishes a new version, read its change summary and check the requested corrections. If the revision introduces a new issue, explain it in context.

Read the PIN sharing guide if you need help entering the project. A useful review ends with a clear record of what you checked, which version you reviewed and what should happen next.