“Make this clearer” may be an accurate reaction to a draft, but it gives the writer very little to act on. They have to guess which sentence caused the problem, what the reader misunderstood, and how much of the surrounding section should change. A useful revision request identifies the problem without pretending there is only one acceptable sentence.
Think of each request as a small editing task with a location, a reason, and a completion check. This method works for articles, instructions, handover notes, and internal documents. The examples below use an invented guide about downloading a text file, so they do not describe defects in a particular published page.
Point to a stable location
Use a heading, paragraph opening, or quoted fragment that the writer can find. “The paragraph under Choose a format, beginning ‘Save your work’” is more reliable than “near the middle.” Page numbers can help for a fixed document, but they may change when the draft is edited.
If several people are reviewing, include the draft version or date. Otherwise a precise comment may still refer to a sentence that has already been replaced. Keep the request attached to the version you read, then mark it resolved or superseded when the writer responds.
Describe the reader problem
Explain what makes the passage difficult. In the fictional draft, “Save your work and clear the browser” skips the distinction between saving a note in the browser and downloading an independent file. A reader might believe the first action makes the second safe.
That is more useful than calling the paragraph “weak.” The writer can now see the missing distinction and decide how to explain it. Focus on the effect of the text rather than making claims about the writer's effort, motives, or ability.
Separate required fixes from preferences
A factual error, a missing prerequisite, and a stylistic preference should not receive the same label. Mark the first two as necessary when they prevent a correct result. Label preferences as suggestions, especially when the current wording is already accurate.
For example, “Explain that the downloaded file must be opened before clearing data” addresses a missing safety check. “Use a shorter opening sentence” is a style suggestion. The writer can prioritize correctly when the request makes that distinction explicit.
A before-and-after request
Vague feedback: Make the export section clearer.
Location: Choose a format, second paragraph.
Problem: Save could mean browser autosave or a separate download.
Required change: Name the download action and add an open-and-check step.
Suggested direction: Tell readers to inspect the final line in the exported file.
Completion check: A new reader can distinguish autosave from independent export.
Priority: Required before publication.
This request provides a direction without forcing a final sentence. If the writer proposes a better explanation that meets the completion check, the request has succeeded. The goal is an accurate document rather than ownership of a particular wording.
Keep one main issue per request
A comment that asks for a new example, different heading, shorter introduction, and corrected screenshot is difficult to close. Break it into separate requests when the items can be completed independently. Keep connected changes together when separating them would hide their relationship.
Avoid flooding a paragraph with several comments that repeat the same issue. One clear request with a representative example is often easier to act on. If the problem appears throughout the draft, identify the pattern and list the affected sections rather than rewriting every sentence in comments.
Invite questions about constraints
The writer may know a limitation you do not. Perhaps the interface does not offer the action described in your suggestion, or the source material cannot support the requested claim. Leave room for that response and update the request when the constraint is real.
Do not resolve uncertainty by asking for a confident-sounding sentence. A note such as “verify this step in the current interface” is better than treating an untested assumption as an editorial requirement. Accuracy is part of clarity.
Close the loop with evidence
When the revision arrives, compare it with the completion check. Does the passage now distinguish the two kinds of saving? Is the open-and-check step present in the right place? Review the actual change rather than marking a request complete because the writer says it was edited.
Record unresolved questions separately from completed revisions. If a broader redesign is outside the current task, put it in a later work item with its own scope. This keeps a necessary correction from becoming an endless expansion of the assignment.
Keep the feedback record usable
Draft requests in a note if that helps you organize them, then place the final comments in the document or system the writer uses. Avoid maintaining conflicting versions in several places. A short summary of required changes can accompany the detailed comments, but it should not introduce new requirements.
Before sending, read the requests from the writer's perspective. Each should identify where to work, why the change matters, and how to tell when the issue is resolved. That makes the review more practical and reduces the need for repeated clarification.
Use the BiNotePads online notepad to adapt this example. For a separate copy of important work, follow the browser-note backup guide.