評審的目標是在寫代碼前發現所有的問題。不要吝惜把時間花在前期的溝通上，這能減少中後期的意外，不耽誤最終的發佈時間。我們可從這些思路出發來發現問題。
文筆
- 錯別字，特別是界面上的文案。例如，登陸->登錄
- 歧義
- 表達不清，模糊
- 沒有統一術語，多處地方用不同詞語來表示同一概念
- 是否雜亂無章，不便於閱讀和查找信息
邏輯
- 需求的目標都沒想清楚，爲了有新版本而做需求
- 流程的出入口：是否明確，是否過多（連用戶都會昏頭轉向）
- 條件與規則說明：是否有矛盾，是否仍有不確定的情況，是否疏漏了其它條件以及多個條件組合的情況
- 缺少異常狀態的考慮
- 缺少說明數據的來源、類型、精度、取值範圍、默認值、顯示格式、計算處理方式
- 沒考慮其它功能或需求的關聯影響
- 用戶體驗
實現
- 在平臺限制、人員能力等條件下無法實現
- 難度較大，耗時
- 遺留的坑會導致出嚴重bug的概率大，風險高
- 性能不佳，會造成用戶體驗差
- 是否有比產品經理想到的更好的方案
- 能否複用已有的邏輯或使用業界更通用的有開源實現的做法
- 後續的迭代考慮，是否在設計上預留可擴展性
- 不重要的部分（例如後臺系統）由開發自行決定界面和交互