原型结构拆解：原型页面、交互状态、异常流、注释标注

章节主旨 — 原型不是“画完就结束”的产物，而是一个包含页面结构、状态切换、边界防御与逻辑注解的四维系统。本章教你像拆解PRD一样拆解原型，确保每一处需求都被原型准确承载。

适用场景

• PRD初稿完成后的原型映射期 — 需要将PRD中的功能条目逐一落地到原型页面，并验证覆盖完整性。
• 原型评审前的自检与互检 — 在正式评审前，按四维框架系统化检查原型是否存在遗漏或歧义。
• 多产品经理协作同一产品线 — 需要统一原型的拆解颗粒度、状态定义标准和注释规范，降低沟通成本。
• 从0到1构建新功能模块 — 避免仅关注主流程而忽视空态、异常态和边界逻辑，导致后期返工。

前置条件

编号	前置条件	验收标准
P01	PRD文档已定稿并通过功能初审	所有需求条目状态为“已确认”
P02	原型设计工具已就绪（Axure / Figma / Sketch）	工具可正常使用，组件库已加载
P03	产品经理与交互设计师已对齐协作节奏	双方确认拆解分工与交付时间
P04	需求清单（需求ID + 功能点）已完成结构化梳理	清单已导出为可对照的电子表格

操作步骤

原型结构拆解按“骨架 → 血肉 → 韧性 → 灵魂”四个层次依次展开，每一层都对应一组具体操作。

步骤一：拆解原型页面结构（骨架）

操作项	详细内容	工具 / 方法
1.1 页面清单对齐	将PRD中的每个功能模块映射为一个或多个原型页面，建立“需求ID ⇄ 页面名称”对照表	Excel / Notion 对照矩阵
1.2 页面层级定义	区分一级页面（顶部导航）、二级页面（侧栏/跳转）、弹窗/浮层，并用编号前缀标记层级	页面结构树图
1.3 布局规范标注	在原型中标注页面布局区域：Header / 内容区 / 侧栏 / Footer / 浮层容器	原型工具 + 布局框线图层

步骤二：定义交互状态（血肉）

操作项	详细内容	工具 / 方法
2.1 状态清单梳理	为每个页面列出至少4种核心状态：loading、empty、normal、error	状态映射表（见下方示例）
2.2 状态切换逻辑	在原型中标注状态之间的触发条件（如：网络恢复后从 error → loading → normal）	状态机流程图 / 条件标注
2.3 状态UI占位	为每个状态绘制对应的UI占位图或引用组件，避免遗漏	组件库 + 状态模板

{
  "page": "订单列表",
  "states": [
    { "name": "loading",    "desc": "加载中",       "ui": "骨架屏卡片" },
    { "name": "empty",      "desc": "暂无订单",     "ui": "空状态插画 + 去逛逛按钮" },
    { "name": "normal",     "desc": "订单列表展示", "ui": "列表卡片 + 分页" },
    { "name": "error",      "desc": "加载失败",     "ui": "错误提示 + 重试按钮" }
  ]
}

步骤三：梳理异常流（韧性）

操作项	详细内容	工具 / 方法
3.1 异常类型识别	按网络异常、数据异常、权限异常、操作异常四类逐一扫描PRD中的关键路径	异常流检查表
3.2 异常UI与文案	为每种异常绘制对应的原型页面或浮层，标注错误文案与操作引导	异常页面模板
3.3 异常恢复路径	在原型中标注用户从异常状态恢复到正常流程的完整路径	流程图 + 条件箭头

步骤四：添加注释标注（灵魂）

操作项	详细内容	工具 / 方法
4.1 逻辑注释	对原型中无法直观体现的业务逻辑、规则判断、数据来源用文字标注	原型工具注释图层 / 便签
4.2 交互说明	标注动效时长、手势操作、键盘快捷键、语音交互等非视觉交互细节	注释面板 + 动效描述
4.3 需求溯源编号	在每条注释末尾添加对应的PRD需求ID，方便评审时快速追溯	格式：【REQ-101】

输入输出物

类型	物名称	格式 / 载体	责任人
📥 输入	PRD文档（已定稿）	PDF / 在线文档	产品经理
📥 输入	需求清单结构化表格	Excel / CSV	产品经理
📤 输出	四维拆解后的原型文件	原型工具源文件	交互设计师 / 产品经理
📤 输出	交互状态映射表	JSON / 表格	产品经理
📤 输出	异常流登记表	Excel / 在线表格	产品经理
📤 输出	注释标注清单（含需求ID）	原型注释 + 附件表格	产品经理

责任边界

• 产品经理：负责四维拆解的完整性与准确性，确保每个PRD需求点被至少一个原型元素（页面/状态/异常/注释）覆盖；输出状态映射表与异常流清单。
• 交互设计师：负责页面布局、UI状态设计、异常视觉呈现，并按照产品经理提供的映射表完成原型绘制；对原型可落地性提出建议。
• 前端开发（预评审阶段）：在原型评审前对异常流和状态定义给出技术可行性反馈，避免后期开发阶段发现实现成本过高。
• 测试人员（可选参与）：提前介入异常流登记表的评审，补充边界用例，提升测试用例的完备性。

记录材料

材料名称	记录内容	建议格式
原型结构检查表	页面清单、层级关系、布局区域标注情况	Google Sheets / Excel
交互状态映射表	每个页面的状态列表、触发条件、UI占位链接	JSON / YAML / 表格
异常流登记表	异常类型、触发路径、UI编号、恢复流程	Excel / 在线表格
注释标注清单	注释位置、注释内容、对应需求ID、状态标记	原型导出注释 + CSV

异常处理

异常场景	可能原因	处理措施
PRD需求与原型页面对应不清晰	需求颗粒度过细或过粗，难以单页映射	在PRD中增加“页面归属”字段，一个需求可对应多个页面时使用「主页面+辅助页面」标记
交互状态定义遗漏	仅凭经验列举状态，缺少系统化检查工具	使用状态映射表模板，按“loading / empty / normal / error”四象限强制检查每个页面
异常流覆盖不全	只考虑了网络异常，忽略了权限/数据/操作异常	使用“异常四类检查法”逐条扫描PRD中的每个用户操作路径
注释标注与原型不同步	修改原型后忘记更新注释	将注释视为原型的一部分，纳入原型版本管理；每次原型更新后强制执行“注释刷新”步骤
多协作者注释风格不统一	缺少注释规范文档	制定团队注释标准：包括颜色规则、标签前缀、需求ID格式、责任人标记

验收标准

维度	验收项	通过标准	检查人
📄 原型页面	页面覆盖完整性	PRD中所有功能点均已映射到至少一个原型页面，对照表无遗漏	产品经理
🔄 交互状态	状态定义完备性	每个核心页面均已定义 loading / empty / normal / error 四种状态，且有UI占位	产品经理 + 交互设计师
⚠️ 异常流	异常路径覆盖率	四类异常（网络/数据/权限/操作）均已扫描，关键路径的异常UI与恢复路径已绘制	产品经理 + 前端开发
📝 注释标注	注释清晰度与可追溯性	每条注释包含业务逻辑说明、交互细节描述、对应需求ID，无歧义且已冻结	产品经理