| name | pm-beta-prototype-review |
| description | 原型评审技能。执行交互评审checklist，评估可用性与技术可行性，输出结构化反馈。适用于设计评审、开发评审、需求评审等场景。当用户需要评审原型设计、评估交互方案、判断技术实现可行性时使用此skill。 |
原型评审
系统化进行原型交互评审、可用性评估、技术可行性判断与反馈输出。
核心模块
1. 交互评审Checklist
评审前准备
评审材料清单：
[ ] 原型文件（支持评论功能）
[ ] 产品需求文档（PRD）
[ ] 用户旅程图/流程图
[ ] 竞品参考（相关功能的业界做法）
[ ] 技术约束说明（前端能力、后端限制）
评审参与角色：
- 产品经理（需求准确性）
- 交互设计师（体验流畅性）
- 视觉设计师（视觉呈现）
- 研发代表（技术可行性）
- 测试代表（异常场景覆盖）
交互五维度评审框架
| 维度 | 核心问题 | 评审重点 |
|---|
| 可用性 | 用户能否完成任务？ | 操作步骤、入口清晰度 |
| 效率 | 操作是否高效？ | 操作步骤数、默认项、快捷操作 |
| 可寻性 | 用户能找到想要的吗？ | 信息架构、导航、搜索 |
| 容错性 | 犯错后能恢复吗？ | 错误提示、撤销机制、确认机制 |
| 满意度 | 用起来舒服吗？ | 动效、反馈、一致性 |
交互评审Checklist
### 一、基础规范
[ ] 所有页面都有标题/页头
[ ] 底部导航不超过5个入口
[ ] 操作按钮在拇指热区范围内（屏幕下半部分）
[ ] 输入框有明确的标签和占位符提示
[ ] 必填项有星号标识（或其他明确方式）
[ ] 分页/加载有状态提示
### 二、导航与结构
[ ] 导航层级不超过3级
[ ] 返回操作符合用户预期（左滑/返回按钮）
[ ] 支持手势操作但不是唯一方式
[ ] 支持深度链接/直接跳转
[ ] 多入口场景下一致性（同一功能不同入口体验一致）
### 三、信息呈现
[ ] 关键信息在首屏可见
[ ] 信息优先级清晰（主/次/弱）
[ ] 内容密度适中（不过于拥挤/稀疏）
[ ] 图标/插图有明确语义
[ ] 文字大小可读（最小12px，16px+更佳）
### 四、用户操作
[ ] 操作入口可见且可点击（点击区域 ≥ 44×44pt）
[ ] 重要操作有视觉强调
[ ] 可逆操作无需确认，危险操作需要确认
[ ] 避免一次性大量输入
[ ] 支持快捷操作/默认选项
[ ] 操作有即时反馈（加载状态、成功/失败提示）
### 五、异常与边界
[ ] 空状态有引导提示
[ ] 加载失败有重试入口
[ ] 网络异常有友好提示
[ ] 必填项遗漏有明确提示
[ ] 输入异常有即时校验
[ ] 避免"幽灵按钮"（有入口但无功能）
### 六、流程完整性
[ ] 从头到尾流程能走通
[ ] 中途退出/返回数据保持
[ ] 完成操作有成功反馈
[ ] 关键操作完成后引导下一步
2. 可用性评估
可用性评估方法
| 方法 | 适用阶段 | 成本 | 深度 |
|---|
| 启发式评估 | 设计/开发 | 低 | 中 |
| 专家评审 | 设计/开发 | 中 | 中 |
| 用户测试 | 开发完成 | 高 | 高 |
| 问卷调查 | 上线后 | 低 | 中 |
启发式评估（10条尼尔森原则）
1. 系统状态可见
→ 随时让用户知道自己在哪、在做什么
2. 系统与真实世界匹配
→ 用用户语言，而非技术术语
3. 用户控制与自由
→ 提供"紧急出口"（返回、撤销、取消）
4. 一致性与标准化
→ 同一产品内相同场景保持一致
5. 错误预防
→ 比报错更好的是预防，必要时提供确认
6. 识别而非回忆
→ 可见选项 > 用户记忆负担
7. 灵活高效
→ 同时满足新手和老手的需求
8. 美观设计
→ 减少认知负担，信息清晰呈现
9. 帮助用户识别错误
→ 用人话描述问题，给出解决方案
10. 帮助文档
→ 复杂系统需要帮助文档，无需用户必须记住
可用性问题定级
| 等级 | 定义 | 处理方式 | 示例 |
|------|------|---------|------|
| P0 | 致命问题，核心流程完全不可用 | 必须修复才能上线 | 支付按钮无法点击 |
| P1 | 严重问题，任务无法正常完成 | 必须在该版本修复 | 填写表单无法提交 |
| P2 | 中等问题，完成任务需要额外努力 | 尽快修复 | 操作步骤冗余 |
| P3 | 轻微问题，不影响任务完成 | 下版本迭代优化 | 视觉对齐细微偏差 |
可用性问题记录模板：
【编号】P2-003
【问题描述】
[描述可见的问题]
【发现位置】
[页面/功能/场景]
【严重程度】
P2 - 用户能完成任务但需要额外操作
【问题原因】
[为什么会发生这个问题]
【建议方案】
[如何修复]
【参考案例】
[竞品/其他产品的优秀做法]
认知走查法
针对关键流程，模拟用户认知过程：
步骤1：确定关键任务路径
如：用户首次下单的完整路径
步骤2：记录用户每一步的认知状态
问自己：
- 用户知道要做什么吗？
- 用户能找到执行入口吗？
- 用户能理解系统的反馈吗？
- 用户知道如何前进/后退吗？
步骤3：记录发现的可用性问题
3. 技术可行性判断
技术可行性评估维度
| 维度 | 评估要点 | 风险等级 |
|---|
| 前端实现 | UI能力、兼容性、性能 | 中 |
| 后端实现 | 接口复杂度、数据处理能力 | 中 |
| 第三方集成 | 依赖方能力、接口稳定性 | 高 |
| 数据埋点 | 是否可追踪、数据准确性 | 低 |
| 安全合规 | 权限控制、数据加密、隐私合规 | 高 |
常见技术约束检查
### 移动端特殊限制
[ ] iOS/Android 兼容性（最低支持版本）
[ ] 机型适配（全面屏、刘海屏、折叠屏）
[ ] 网络环境（弱网、无网、切换网络）
[ ] 本地存储限制（权限申请、存储空间）
[ ] 推送能力（推送到达率、权限影响）
[ ] 分享能力（App间跳转、Universal Link）
### Web端特殊限制
[ ] 浏览器兼容性（Chrome/Safari/Firefox/IE）
[ ] 响应式布局（不同屏幕尺寸）
[ ] SEO限制（SSR vs CSR）
[ ] 缓存策略（强缓存/协商缓存）
[ ] 跨域限制（前后端分离场景）
### 性能要求
[ ] 首屏加载时间 ≤ 3秒
[ ] 操作响应时间 ≤ 1秒
[ ] 动画帧率 ≥ 60fps
[ ] 页面大小 ≤ 2MB
技术可行性评估表
## 技术可行性评估
### 功能：[功能名称]
### 评估日期：[日期]
### 研发负责人：[姓名]
| 评估项 | 可行性 | 难度 | 方案建议 | 工时估测 |
|--------|--------|------|---------|---------|
| UI实现 | ✓ | 中 | [方案] | 2人天 |
| 核心逻辑 | ✓ | 高 | [方案] | 5人天 |
| 后端接口 | △ | 高 | [需接口改造] | 8人天 |
| 第三方集成 | ✗ | - | [依赖方暂不支持] | - |
| 数据埋点 | ✓ | 低 | [现有事件可复用] | 0.5人天 |
【结论】
□ 可行，需[X]人天
□ 部分可行，需与[第三方/架构]确认
□ 需延期，原因：[说明]
□ 不可行，建议方案：[替代方案]
技术评审常见问题及应对
【问题1】技术方案改动大，工期不可控
应对：
- 拆解需求，寻找技术成本更低的替代方案
- 与研发协商优先级，分期实现
- 申请增加资源或调整交付时间
【问题2】涉及第三方依赖，风险不可控
应对：
- 明确第三方能力和限制
- 准备降级方案/兜底策略
- 设置技术验证节点
【问题3】性能要求与设计方案冲突
应对：
- 性能测试验证实际影响
- 优化设计方案，减少资源消耗
- 与前端/后端协同优化
【问题4】跨端一致性难以保证
应对：
- 制定跨端设计规范
- 优先保证核心体验一致，非核心允许差异
- 建立跨端Review机制
4. 反馈输出模板
评审反馈结构
## 原型评审反馈
### 基本信息
- 评审时间：[YYYY-MM-DD HH:MM]
- 评审类型：[设计评审/开发评审/需求评审]
- 评审范围：[页面/功能名称]
- 评审结论：[通过/有条件通过/需大改]
### 总体评价
[2-3句话总体评价原型的优缺点]
### 必须修改项（P0-P1）
| 编号 | 类型 | 位置 | 问题描述 | 严重程度 | 建议方案 |
|------|------|------|---------|---------|---------|
| 01 | 交互 | 首页/按钮 | 确认按钮位置容易被误触 | P1 | 将确认按钮移至右上角 |
| 02 | 流程 | 支付页 | 缺少支付方式选择 | P0 | 添加微信/支付宝选项 |
### 建议优化项（P2-P3）
| 编号 | 位置 | 优化建议 | 优先级 | 备注 |
|------|------|---------|--------|------|
| 01 | 列表页 | 加载更多改为分页选择 | P3 | 可作为体验优化项 |
| 02 | 个人中心 | 头像默认图可更精致 | P3 | 下版本优化 |
### Q&A 记录
Q：设计师对某交互细节的解释
A：产品经理/研发对疑问的解答
### 待确认事项
| 事项 | 负责人 | 确认时间 | 状态 |
|------|--------|---------|------|
| 第三方分享能力确认 | 张三 | 3日内 | 待确认 |
| 历史数据迁移方案 | 李四 | 5日内 | 待确认 |
### 后续安排
- 改稿时间：[日期]
- 复审时间：[日期]
- 预计上线：[版本号]
评审结论定义
| 结论 | 含义 | 下一步 |
|---|
| 通过 | 无P0-P1问题，可进入开发 | 直接进入开发阶段 |
| 有条件通过 | 有P2-P3问题，不影响核心功能 | 开发同时修复，发布前验收 |
| 需大改 | P0-P1问题较多，需重新设计 | 修复后重新评审 |
评审效率提升技巧
评审前：
- 提前发送评审材料，评审前至少1天
- 明确评审范围和目标，避免发散
- 要求评审者提前发现问题，会上只确认
评审中：
- 控制在1小时内，超时拆分为多个评审
- 记录所有问题，不当场讨论解决方案
- 按优先级排序讨论
评审后：
- 24小时内发出评审纪要
- 明确修改人和完成时间
- 跟踪问题修复状态
输出规范
- 评审发现的问题需在24小时内录入问题跟踪表
- P0问题必须在本版本修复，P1问题需上线前确认
- 评审纪要在评审结束后24小时内发出
- 复审通过后才能进入开发阶段
