1. 原型说明的定义与价值

1.1 用户场景 — 谁在什么时候需要原型说明

原型说明并非产品经理的自嗨产物,而是团队协作的关键节点。从用户场景切入,才能理解它的真实价值。

  • 产品经理(方案输出阶段):完成原型设计后,需要将交互逻辑、异常状态、数据规则同步给所有角色。此时,原型说明是唯一的“官方解读”。
  • 交互设计师(细节打磨阶段):需要理解每个页面的跳转关系、手势反馈、加载与空态设计。原型说明中的注释与流程图,直接决定设计稿的完整性。
  • 前端/后端开发(编码实现阶段):必须明确每个可点击区域的热区范围、输入字段的校验规则、接口返回数据的展示方式。没有说明的原型,开发只能“猜”。
  • 测试工程师(用例编写阶段):需覆盖正常流程、异常流程、边界条件。原型说明中的“预期行为”是测试用例的唯一依据。

1.2 业务问题 — 没有原型说明的代价

缺少规范的原型说明,团队会陷入“口头传递→理解偏差→返工重做”的恶性循环。以下对比清晰揭示痛点:

对比维度 无原型说明 有规范原型说明
需求传递方式 口头描述 + 零散截图 结构化文档 + 可视化标注
团队对齐周期 2–3 轮会议仍存歧义 1 次评审即可锁定理解
返工率(开发阶段) 30%–50% 5%–15%
异常状态遗漏率 60% 以上 低于 10%
沟通成本(人/天) 高(反复确认、补位解释) 低(一次对齐,按文档执行)
核心结论:原型说明不是“额外工作”,而是为整个研发流程降低不确定性的基础设施。

1.3 用户访谈 — 各方对原型说明的真实诉求

在课程前期的用户调研中,我们访谈了 12 位来自不同角色的从业者,以下是三个最具代表性的诉求:

  • 产品经理(某电商平台 PM):“我最怕评审会上大家说‘这里我理解是……’,每个版本光对齐理解就要花半天。如果原型说明能写到‘点击后触发什么、数据从哪里来、异常怎么展示’,评审会至少缩短 60%。”
  • 前端开发(某 SaaS 公司):“原型上不写点击后的反馈,我就得去问。问一次等半天,问多了人家烦。最夸张的一次,一个弹窗的文案改了 4 遍,因为原型上没标来源。”
  • 测试工程师(某金融科技公司):“没有异常状态说明的原型,我只能按正常流程写用例。上线前才发现‘网络超时’和‘Token 过期’的处理都没做,直接导致版本延期。”
访谈启示:三方的诉求都指向同一个方向——原型说明必须做到“可读、可查、可验证”,才能成为团队真正的协作基准。

1.4 需求拆解 — 原型说明如何结构化需求

一个完整的原型说明,本质上是对原始需求的“结构化拆解”。它把抽象的业务诉求,转化为设计、开发、测试可直接执行的信息单元。

  1. 页面结构层:包含页面布局、组件类型、层级关系。
  2. 交互流程层:包含页面跳转、手势操作、状态切换。
  3. 数据规则层:包含字段格式、校验逻辑、接口映射。
  4. 异常处理层:包含空态、加载态、错误态、超时处理。

每一层都可以独立评审、独立测试、独立验收。这种“分层拆解”的方式,让原本模糊的需求变成可量化的交付物。

1.5 方案表达 — 从模糊到精确的核心方法

原型说明的核心能力在于“表达”。同一个需求,模糊的表达和精确的表达,对团队的效率影响截然不同。

  • 注释标注:在原型画布上直接添加文字说明,解释“为什么这样设计”“数据来源是什么”“点击后去哪里”。
  • 流程连线:用箭头和节点绘制用户操作路径,明确“从哪来→到哪去→触发什么”。
  • 状态矩阵:用表格列出“正常状态”“空状态”“错误状态”“加载状态”的视觉与行为差异。
  • 数据字典:以清单形式标注每个字段的“字段名、类型、长度、必填、来源接口”。
常见误区:很多 PM 只在原型上画了界面,没有写任何说明,就认为“团队应该能看懂”。事实证明,没有精确表达的原型,本质上只是“带颜色的线框图”,不具备交付能力。

1.6 核心枢纽 — 原型说明的连接作用

下图直观呈现原型说明在团队协作中的“枢纽”位置:它接收产品需求,经过结构化拆解后,同时驱动设计、开发和业务目标的对齐。

原型说明 — 需求交付的核心枢纽 产品需求 业务目标 · 用户故事 原型说明 结构化 · 可执行 设计理解 视觉 · 交互 · 状态 开发实现 编码 · 接口 · 逻辑 业务目标 指标 · 增长 · 价值 原型说明是连接产品、设计、开发和业务目标的核心枢纽 减少沟通损耗 · 提升交付确定性

1.7 指标验证 — 原型说明的质量度量

原型说明写得好不好,不能凭感觉评价,需要用可量化的指标来验证。

  • 完整率:已标注交互逻辑的页面数 ÷ 总页面数 × 100%。目标值 ≥ 95%。
  • 理解一致率:评审会上,设计、开发、测试对同一页面说明的理解是否一致。目标值 ≥ 90%。
  • 开发返工率:因原型说明不清导致的代码返工任务数 ÷ 总任务数 × 100%。目标值 ≤ 10%。
  • 异常状态覆盖率:已标注的异常状态数 ÷ 所有可能出现的异常状态数 × 100%。目标值 ≥ 80%。
建议:在每个版本复盘会上,用上述指标回顾原型说明的质量,持续迭代团队的撰写规范。

1.8 验收标准 — 一份合格原型说明的底线

一份合格的原型说明,必须同时满足以下五项验收标准:

  1. 要素完整:每个页面至少包含“页面标题、交互说明、数据规则、异常状态”四项基础信息。
  2. 逻辑闭环:所有跳转关系、反馈机制、边界条件都有明确描述,不存在“未定义”的行为。
  3. 标注清晰:文字说明位置合理,不遮挡原型元素;箭头指向明确,无歧义。
  4. 版本一致:原型文件、说明文档、需求清单三者版本号一致,变更历史可追溯。
  5. 可测试性:测试人员能根据说明直接编写测试用例,无需额外向 PM 确认。

1.9 交付物模板 — 标准结构速览

为方便快速上手,我们给出原型说明的标准模板结构(以 JSON 格式示意,实际交付可为文档、表格或原型工具内的标注面板):

{
  "页面ID": "P-001",
  "页面名称": "登录页",
  "版本": "v1.2",
  "交互说明": [
    { "元素": "手机号输入框", "行为": "输入11位数字后自动校验格式", "异常": "非数字输入弹出提示" },
    { "元素": "获取验证码按钮", "行为": "点击后倒计时60s", "异常": "网络超时展示'获取失败'弹窗" },
    { "元素": "登录按钮", "行为": "校验通过后跳转首页", "异常": "校验失败展示红色错误提示" }
  ],
  "数据规则": [
    { "字段": "phone", "类型": "string", "长度": "11", "必填": true, "接口": "/api/sendCode" }
  ],
  "状态矩阵": {
    "正常态": "默认展示登录表单",
    "空态": "无",
    "加载态": "按钮置灰+loading图标",
    "错误态": "字段红色边框+错误文案",
    "超时态": "弹窗提示'连接超时,请重试'"
  }
}
注意:模板是起点,不是终点。实际项目中,请根据团队协作习惯和工具特性(如 Figma、Axure、Sketch 等)调整字段粒度。核心原则是“让阅读者不需要追问”。