設計評審 Checklist 提示詞（交互稿 / 視覺稿評審：一致性、狀態覆蓋、邊界情況、無障礙、開發可實現性）
設計稿交付開發前的評審會、或者設計師自查時用：根據需求和設計稿描述，按目標達成、交互邏輯、狀態覆蓋、一致性、文案、無障礙、開發可實現性等維度生成檢查清單並逐項評估，輸出問題列表和評審結論，減少開發階段的返工。
通用大模型 對話模型通用
你是一名資深設計負責人，主持過很多次設計評審。你的經驗：大部分返工不是因為「設計不好看」，而是因為「漏掉了狀態和邊界情況」，以及「需求理解不一致」。 需求背景與目標（來自 PRD 的要點）：[需求要點] 設計稿描述（頁面清單、每頁的元素、交互、跳轉）：[設計稿描述] 平台與設計規範（是否有設計系統）：[平台與規範] 參與評審的角色：[評審角色] 已知的限制（技術、時間、數據）：[已知限制] 請輸出： 1. 評審清單（按維度，每項都寫成可以回答「是 / 否 / 不確定」的問題）： - 目標：設計是否解決了需求中的核心問題，用戶能否完成主要任務； - 流程：主流程與分支流程是否完整，返回與退出路徑； - 狀態：加載中、空狀態、錯誤、無網絡、無權限、內容過長 / 過短、首次使用； - 邊界：數據極值（0、1、很多）、長文本、多語言、不同螢幕尺寸； - 一致性：與設計系統組件、現有頁面的交互和視覺是否一致； - 文案：按鈕用動詞、錯誤提示可操作、術語統一； - 無障礙：對比度、點擊區域大小、讀屏標籤、不只用顏色傳達資訊； - 開發可實現性：動效、數據來源、接口依賴、性能。 2. 逐項評估：根據我提供的設計描述回答每一項，標出「問題」或「需要補充」，並給出建議。 3. 問題列表：編號 | 頁面 | 問題 | 嚴重程度（阻塞 / 重要 / 建議）| 負責人。 4. 評審結論：通過 / 修改後通過 / 需要再評審，以及下一步。 5. 評審會議程（45 分鐘）：每個環節的時間和討論重點。 約束：基於提供的資訊判斷，看不到的部分標「需在設計稿中補充」；問題針對設計而不是設計師個人。
高亮處換成你自己的內容：[需求要點]、[設計稿描述]、[平台與規範]、[評審角色]、[已知限制]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[設計稿描述] 不能直接看圖的話，就按頁面列出關鍵元素和交互，例如「訂單列表頁：頂部篩選（全部 / 待付款 / 待發貨），列表項顯示商品圖、名稱、金額、狀態，左滑可刪除」。[已知限制] 寫清楚技術或數據的約束，評審時能避免設計出做不了的東西。
常見坑：
- 評審只看主流程的「完美狀態」，沒有人問「沒有數據的時候長什麼樣」；
- 評審意見變成個人審美之爭，而沒有回到需求目標；
- 評審結論模糊，會後不知道是否可以進入開發。
迭代追問：「把問題列表整理成可以導入任務管理工具的格式」「為這個功能補全所有狀態的設計說明」「把這份清單整理成團隊通用的設計自查模板」。
示例輸出
示例，僅供參考（虛構：電商 App 訂單列表頁改版）
| 編號 | 頁面 | 問題 | 嚴重程度 |
|---|---|---|---|
| 1 | 訂單列表 | 沒有空狀態設計（新用戶沒有訂單時） | 重要 |
| 2 | 訂單列表 | 左滑刪除沒有確認步驟，誤操作無法恢復 | 阻塞 |
| 3 | 訂單詳情 | 商品名稱過長時的截斷方式未定義 | 建議 |
| 4 | 篩選欄 | 選中狀態僅靠顏色區分，色弱用戶難以識別 | 重要 |
評審結論：修改後通過——問題 2 需在開發前確認方案。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～