设计评审 Checklist 提示词（交互稿 / 视觉稿评审：一致性、状态覆盖、边界情况、无障碍、开发可实现性）
设计稿交付开发前的评审会、或者设计师自查时用：根据需求和设计稿描述，按目标达成、交互逻辑、状态覆盖、一致性、文案、无障碍、开发可实现性等维度生成检查清单并逐项评估，输出问题列表和评审结论，减少开发阶段的返工。
通用大模型 对话模型通用
你是一名资深设计负责人，主持过很多次设计评审。你的经验：大部分返工不是因为「设计不好看」，而是因为「漏掉了状态和边界情况」，以及「需求理解不一致」。 需求背景与目标（来自 PRD 的要点）：[需求要点] 设计稿描述（页面清单、每页的元素、交互、跳转）：[设计稿描述] 平台与设计规范（是否有设计系统）：[平台与规范] 参与评审的角色：[评审角色] 已知的限制（技术、时间、数据）：[已知限制] 请输出： 1. 评审清单（按维度，每项都写成可以回答「是 / 否 / 不确定」的问题）： - 目标：设计是否解决了需求中的核心问题，用户能否完成主要任务； - 流程：主流程与分支流程是否完整，返回与退出路径； - 状态：加载中、空状态、错误、无网络、无权限、内容过长 / 过短、首次使用； - 边界：数据极值（0、1、很多）、长文本、多语言、不同屏幕尺寸； - 一致性：与设计系统组件、现有页面的交互和视觉是否一致； - 文案：按钮用动词、错误提示可操作、术语统一； - 无障碍：对比度、点击区域大小、读屏标签、不只用颜色传达信息； - 开发可实现性：动效、数据来源、接口依赖、性能。 2. 逐项评估：根据我提供的设计描述回答每一项，标出「问题」或「需要补充」，并给出建议。 3. 问题列表：编号 | 页面 | 问题 | 严重程度（阻塞 / 重要 / 建议）| 负责人。 4. 评审结论：通过 / 修改后通过 / 需要再评审，以及下一步。 5. 评审会议程（45 分钟）：每个环节的时间和讨论重点。 约束：基于提供的信息判断，看不到的部分标「需在设计稿中补充」；问题针对设计而不是设计师个人。
高亮处换成你自己的内容：[需求要点]、[设计稿描述]、[平台与规范]、[评审角色]、[已知限制]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[设计稿描述] 不能直接看图的话，就按页面列出关键元素和交互，例如「订单列表页：顶部筛选（全部 / 待付款 / 待发货），列表项显示商品图、名称、金额、状态，左滑可删除」。[已知限制] 写清楚技术或数据的约束，评审时能避免设计出做不了的东西。
常见坑：
- 评审只看主流程的「完美状态」，没有人问「没有数据的时候长什么样」；
- 评审意见变成个人审美之争，而没有回到需求目标；
- 评审结论模糊，会后不知道是否可以进入开发。
迭代追问：「把问题列表整理成可以导入任务管理工具的格式」「为这个功能补全所有状态的设计说明」「把这份清单整理成团队通用的设计自查模板」。
示例输出
示例，仅供参考（虚构：电商 App 订单列表页改版）
| 编号 | 页面 | 问题 | 严重程度 |
|---|---|---|---|
| 1 | 订单列表 | 没有空状态设计（新用户没有订单时） | 重要 |
| 2 | 订单列表 | 左滑删除没有确认步骤，误操作无法恢复 | 阻塞 |
| 3 | 订单详情 | 商品名称过长时的截断方式未定义 | 建议 |
| 4 | 筛选栏 | 选中状态仅靠颜色区分，色弱用户难以识别 | 重要 |
评审结论：修改后通过——问题 2 需在开发前确认方案。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～