Agree what this round of review needs to settle
Before commenting, check what you’re reviewing. A rough storyline needs a different conversation from a designed deck that is nearly ready to send. Ask the presenter or designer which decisions are open and which have already been agreed.
For an early draft, focus on the audience, the argument and the sequence. Once those are settled, review how the slides explain the content. Before delivery, check facts, labels, formatting and the exported file. These are useful passes through the work, rather than a rule that a factual problem must wait until the end.
Nielsen Norman Group’s guidance on design critiques emphasizes agreed objectives and a clear scope for the conversation. It addresses UX design, but the principle applies to a presentation review: people need to know what the work is supposed to achieve before they can assess it.
A review request can be brief: “This version is for operations directors considering an implementation project. Please check whether the proposed process and the work required from their team are clear. We’re reviewing the content before refining the layout.”
Source: Nielsen Norman Group — Design Critiques: Encourage a Positive Culture to Improve Products
Show the gap between a vague comment and a usable one
Consider a fictional software proposal with a slide titled “Implementation approach”. It lists five stages: discovery, configuration, migration, training and go-live. The sequence is clear, but it tells the buyer very little about their own involvement. This is an illustrative example, not a Pitchwave or client project.
A reviewer writes, “Needs more detail.” The designer could respond by adding dates, technical specifications, extra activities or longer descriptions. None of those necessarily answers the buyer’s question.
A more useful comment would be: “On the implementation slide, I can follow our delivery stages, but I can’t tell when the customer’s team needs to contribute. The operations director needs to assess that commitment. Could we show their input beside each stage?”
That comment identifies the page, describes the missing information and explains why it matters. It also leaves room to discuss the best way to show it. In this example, the revision could be a simple table:
The first version named the stages. The revised version lets the buyer see where their team is involved. The activities are fictional examples; replace them with the actual project scope.
| Stage | Provider activity | Customer input |
|---|---|---|
| Discovery | Map the current workflow | Identify the process owner |
| Configuration | Set up the workspace | Review the proposed setup |
| Migration | Import an approved data sample | Check the field mapping |
| Training | Run a workflow walkthrough | Nominate the users who need to attend |
| Go-live | Support the release | Confirm readiness to proceed |
Explain what the reader is struggling to understand
You don’t need design vocabulary to give good feedback. Describe what you can’t find, compare or follow. If a slide feels crowded, identify which information is competing for attention and what you need to notice first.
For example, “Make this more visual” could become: “I’m trying to compare the two delivery options, but I have to switch between paragraphs to find the differences. Could the shared criteria sit together so we can compare them?” That gives the designer a problem to solve. A table might help, but another layout could work too.
“Make it punchier” could become: “The opening names our services, but I don’t yet understand which customer problem this proposal addresses. Can we make that problem clear before introducing the offer?”
Positive feedback deserves the same precision. Instead of “This page looks good,” try: “Keep the side-by-side comparison. It lets me see which responsibilities change between the options.” That helps the next revision preserve something useful.
If the concern is about appearance, say what you notice. “The labels are hard to read in the PDF” gives a clearer starting point than “The design needs work.” The designer can investigate size, contrast and spacing without having to guess what prompted the comment.
Make factual corrections, questions and preferences distinguishable
A factual correction should identify the information that needs changing and the source for the replacement. For example: “This slide uses the previous reporting period. Please use the figures in the approved workbook and update the period label to match.” If you haven’t checked the replacement, ask the person responsible to confirm it.
A question should remain a question until someone resolves it. “Does migration include archived records?” is different from an instruction to add archive migration to the proposal. Assign it to the person who knows the scope before the designer turns it into a commitment.
A preference can be discussed as a preference. “I’d prefer a quieter cover” is a fair starting point. Explain the context if there is one: perhaps the deck will be printed in black and white, or an established brand guideline applies. Don’t present a personal choice as if it were a confirmed audience need.
This distinction helps a designer or presentation lead decide which comments can be implemented, which need an answer and which need a conversation. A comment should not gain factual authority merely because it appears in a review thread.
Resolve conflicting comments before passing them on
One reviewer wants more detail. Another wants a shorter deck. Sending both instructions to the designer leaves the decision unresolved. Ask which information the audience needs for this particular conversation, and what each reviewer thinks is missing.
In the implementation example, the sales lead might want a simple sequence while the operations lead wants to see customer responsibilities. The revised table can address both concerns without adding paragraphs about every delivery activity. That is a reasoned choice for this example, not a promise that a table solves every disagreement.
Where the comments point to genuinely different audiences or uses, choose which use this version will serve. Record that decision so the next review doesn’t reopen it without a reason. If a disagreement changes the proposal, involve the person responsible for that business decision.
Keep one agreed set of instructions for the next draft. Retain the original comments, but distinguish the decisions from the discussion that led to them. “Add customer responsibilities beside each stage; keep technical setup detail out of this overview” is something a designer can act on.
Tell reviewers what changed and what still needs an answer
After the revision, send a short note that connects the changes to the comments. Nielsen Norman Group’s guidance on critique follow-up recommends making that connection visible and explaining decisions about feedback that wasn’t adopted. Its examples concern product design; a presentation team can apply the same principle to a draft handover.
For the fictional implementation slide, the note could say: “We added a customer-input column to answer the question about internal involvement. We kept the slide at stage level. Archive migration remains an open scope question for the delivery lead; it has not been added to the proposal.”
That note lets a reviewer check the change and see what remains unresolved. It also prevents the next reader from assuming that every question in the comments has been answered. Keep the decision note with the relevant version of the deck.
Source: Nielsen Norman Group — Closing the Loop: What to Do After a Design Critique Ends
Check the revised file before approving it
Review the actual file the audience will receive. A useful change in the editing application can still produce a cropped table, a broken link or unreadable labels in the PDF. Check that new wording agrees with the underlying scope and that resolved comments have been implemented correctly.
When working with a presentation designer, send the current deck, one consolidated feedback set and any approved replacement material. Name the person who can resolve content questions and the person who gives final approval. You can give direct feedback without prescribing every layout decision.
- LocationCan the designer identify the slide or element you mean?
- PurposeHave you explained what the audience needs to understand?
- BasisIs this a checked correction, an open question or a preference?
- DecisionHave conflicting instructions been resolved or assigned to someone?
- CompletionDoes the revised export reflect the agreed changes, with open questions still visible to the team?