pm-beta-prototype-review

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小时内发出
• 复审通过后才能进入开发阶段