含糊的意見會變成好幾種不同的任務
“把標題寫得更有力”對文案人員來說可能意味着把承諾說清楚，對設計師來說可能意味着加強視覺強調，對產品經理來說則可能意味着更換產品方案。每個人都可能給出合理的解釋，卻仍未解決最初的問題。
從缺少的資訊或不清楚的關系說起。例如：“標題說出了服務名稱，但開頭部分沒有解釋它面向哪些團隊。”這樣的觀察仍允許團隊選擇不止一種合理方案。
把問題與建議分開表達
“把按鈕往上移”是一項建議；“資格說明和申請操作之間隔着無關內容”才指出了問題所在的關系。移動按鈕可能有幫助，但移動說明或移除中斷也可能更好。
即使實現方案發生變化，報告或評論也應保留最初的問題。否則，後續審查者只能確認要求移動的像素是否移動了，卻無法判斷資訊傳達是否改善。
明確寫出相互沖突的目標
假設銷售團隊希望把規格表放在咨詢表單之後，而支持團隊希望客戶能直接訪問規格表。投票決定哪種版面配置看起來更簡潔，並不能化解分歧，因為兩個團隊追求的結果不同。
寫下其中的取舍，並明確由誰決策。一種做法是公開技術文檔，同時提供單獨的咨詢服務；也可以根據業務情況選擇其他方案。當理由清晰可見，而不是埋在冗長的評論串裡，審查才真正有用。
留下決策記錄，而不是評論檔案
對於影響較大的選擇，記錄哪些內容改變或保留、原因、負責人，以及什麼情況會促使團隊重新評估。“保留公開下載；如果檔案包含帳戶專屬資訊，再重新考慮”比一個沒有解釋的已解決評論更清楚。
尚未解決的事實問題需要調查，而不是憑空編造答案。安排負責人獲取缺失資訊，並把問題保留在它所影響的決策旁邊。這樣，審查回饋才能變成其他人也能接手推進的工作。