一个优秀原型图应该体现什么：从“画框架”到“对齐认知”的完整指南

一、引言：原型图到底在解决什么问题？

在很多团队里，“原型图”常常被误解成：

• 设计师的“草图”
• 产品经理的“占位图”
• 开发用来数页面数量的“施工清单”

结果是：

• UI 觉得原型太粗糙，重画一次；
• 开发看不懂交互和状态，干脆自己脑补；
• 测试不知道验什么，需求边做边改；

从本质上看，一个优秀的原型图，不只是“画了页面”，而是要解决这几个核心问题：

1. 各方能否对业务流程和用例达成统一认知？
2. 是否清晰表达了信息结构、交互逻辑、状态变化？
3. 是否为后续 UI 设计、研发实现、测试验收提供清晰边界和依据？

这篇文章围绕“一个优秀原型图要体现的内容”展开，具体从：

• 原型图要解决的问题和使用场景
• 原型图应体现的关键内容结构
• 如何在工具里落地（以 Axure/Figma 为例，含组件与交互示例）
• 优缺点与实战建议

帮助你从“能画原型”到“用原型驱动协作和交付”。

---

二、问题与背景：为什么原型图常常“画了等于没画”？

2.1 常见的原型图反模式

你可能见过这样的原型：

• 只有简单框线 + 文本：“这里是列表”“这里是按钮”
• 完全没有说明：点击后发生什么？权限差异？异常情况？
• 没有流程视角：每张都是孤立页面，看不出用户路径
• 缺少状态：只有“成功态”，没有“空态、加载态、失败态”

这导致几个直接问题：

1. 角色理解不一致

   • 产品：我以为你们理解“这样点一下就自动保存了”。
   • 开发：原型上没画自动保存，我们就按按钮触发保存做了啊。

2. 遗漏边界与异常场景

   • 例如：

     • 没考虑权限不同用户看到的内容差异；
     • 没说明分页策略、数据量边界、输入校验规则。

3. 难以估期与控制范围

   • 开发不知道有哪些交互细节，只能按最复杂情况抓总；
   • 迭代开发中不断冒出“我以为”导致延期和返工。

所以，一个优秀的原型图，关键不是“好不好看”，而是能不能完整表达产品意图与交互逻辑。

---

三、一个优秀原型图应体现的核心内容结构

下面从“内容层面”列出，一个合格甚至优秀的原型图，至少要清晰呈现的几个方面。

3.1 用户与场景：为“谁，在什么情境下使用”

在原型首页或文档开头，应简要注明：

• 该原型服务的目标用户角色（如运营、管理员、普通用户等）
• 主要使用场景（如：创建订单、审批报销、数据看板浏览）
• 简化的业务流程图或时序图（推荐）

示例说明（文本即可）：

模块：报销审批

目标用户角色：
- 员工（提交报销）
- 直属主管（审批）
- 财务（复核与打款）

主流程：
1. 员工提交报销单（录入费用明细、上传票据）
2. 直属主管审批（同意/驳回）
3. 金额 > 5000 时，增加财务复核节点
4. 财务复核通过后，系统标记为“待打款”
5. 打款完成后，状态更新为“已报销”

这一部分可以写在第一页的说明区，或者用注释组件固定在原型上方。

3.2 信息架构（IA）：整体导航与页面关系

优秀原型需要体现：

• 信息层级：模块 → 页面 → 组件
• 导航结构：顶部导航/侧边导航/底部 Tab
• 关键页面之间的跳转关系：列表 → 详情 → 编辑 → 弹窗

推荐做法：

1. 先画一个**“页面地图 / Sitemap”**：

   • 列出模块与页面的树状结构。

2. 对于复杂系统，附一张简单的导航示意图。

示例（伪结构）：

- 费用报销
  - 报销单列表
    - 报销单详情（侧滑 / 独立页面）
    - 新建报销单 / 编辑报销单（弹窗 / 页面）
  - 报销设置（仅管理员可见）
    - 费用类型配置
    - 审批流程配置

在 Axure / Figma 中，可以用独立一页画出：

• 左侧：模块树
• 右侧：对勾 / 标签标识哪些页面本次迭代涉及

3.3 页面布局与信息优先级

每一张页面原型图应至少清楚表达：

1. 主要区域划分（比如：头部导航 / 筛选区 / 内容区 / 操作区）
2. 关键信息的优先级（什么是主信息、什么是辅助信息）
3. 响应式考虑（如有）：在不同分辨率下哪些区域优先显示/折叠

示例说明（文字 + 布局示意即可）：

报销单列表页布局说明：

- 顶部区域：全局导航（统一规范）
- 顶部次级区域：筛选条件区（日期范围、状态、费用类型、关键字）
- 中间主要区域：报销单列表（支持排序、分页）
- 右侧可选区域：选中某条后，在右侧展示简要详情（优化审批效率）
- 底部：无

布局示意（原型中常用灰盒区分）：

• 深灰：高优先级内容，如主列表、关键操作按钮
• 浅灰：次要内容

3.4 交互行为与状态变化

这是决定原型“是不是给开发看的”的核心部分。

需要体现的交互和状态：

1. 点击/悬停/长按等触发行为：

   • 点击按钮跳转到哪张原型？
   • 是否有悬浮提示（Tooltip）？
   • 行为是“覆盖当前页面”还是“弹出新窗口 / 抽屉”？

2. 组件状态：

   • 按钮：可点击 / 禁用 / 加载中
   • 表单：正常态 / 校验失败态 / 只读态
   • 列表：有数据 / 无数据（空态） / 加载中 / 加载失败

3. 业务状态：

   • 报销单状态：草稿 / 审批中 / 已驳回 / 已报销 / 已撤回
   • 审批操作对状态的影响（建议配简单状态流转图）

在原型工具中的落地方式示例

以 Axure 为例，可以通过“交互”面板定义点击事件：

• “提交报销单”按钮：

  • 条件 1：必填项非空 → 触发“提交成功”逻辑，跳转到“列表页”并显示成功提示。
  • 条件 2：有缺失必填项 → 不跳转，在当前页高亮错误字段，并显示错误提示。

伪交互逻辑描述：

交互：点击【提交】按钮
条件判断：
- 如果「报销金额 > 0」且「事由不为空」且「至少一条费用明细」
  - 执行：
    1. 显示 Loading 状态（按钮变灰，文案变为“提交中...”）
    2. 1 秒后（模拟服务端响应）：
       - 跳转到【报销单列表页】
       - 在页面顶部显示“提交成功”的提示条（3 秒自动消失）
- 否则：
  - 在缺失必填项的字段下方显示红色错误提示

在 Figma 中，可以利用 Prototype 功能连线，并在旁边加文字注释说明逻辑细节。

3.5 数据结构与字段说明

对“列表、详情、表单”等涉及数据的页面，原型图中应体现：

• 字段名（展示文本）
• 字段含义（可在“备注栏”中说明）
• 字段类型与校验规则（数字、枚举、日期等）
• 是否必填 / 只读 / 条件显示

示例（放在页面下方说明区）：

字段说明 - 新建报销单

- 报销事由（必填，文本，长度 1~200 字）
- 报销金额（必填，数字，>0，保留两位小数）
- 报销类型（必填，枚举：交通 / 餐饮 / 住宿 / 其他）
- 票据照片（非必填，目前支持 jpg/png，最多 9 张）
- 发生日期（必填，不能晚于当前日期）

如果团队有统一的“字段字典 / 接口文档”，可以在原型标注对应字段名（如 reason, amount），方便开发对接。

3.6 权限与差异化视图

优秀原型不只画“理想用户视图”，还要体现：

• 不同角色看到的功能差异（按钮显示/隐藏）
• 不同租户 / 客户级别的功能开关
• 权限不足时的提示与行为（直接隐藏还是灰显？点击后提示无权限？）

原型表现方式示例：

• 同一页面做多个视图版本：

  • “管理员视图”
  • “普通员工视图”

• 或在元素旁标注标签：

  • [仅管理员可见]
  • [角色：财务]

示例说明：

按钮【导出报销单】：

- 仅角色：管理员/财务 可见。
- 普通员工不显示该按钮（而不是灰显）。
- 若通过直达链接访问导出接口，后端拦截并返回 403，并在前端提示“当前账号无导出权限”。

3.7 异常与边界情况（往往最容易遗漏）

至少考虑这几类情况的原型表现：

1. 空态：没有任何数据时怎么展示？是否有引导创建/配置的 CTA（Call to Action）？

2. 加载过程：

   • 初次加载时是否显示骨架屏/Loading 动画？
   • 分页/下拉加载更多时的视觉反馈？

3. 失败态：

   • 网络异常/服务器错误时展示什么？
   • 是否支持重试？重试按钮放在哪里？

4. 边界数据量：

   • 文本过长时如何展示（截断/换行/Tooltip）？
   • 超出最大上传数量/大小时的提示？

原型中可通过一组“状态页面”来展现，例如：

• 报销单列表页（有数据）
• 报销单列表页（空态）
• 报销单列表页（加载失败）

每种状态附上简短文案设计，例如：

空态文案：
- 标题：还没有报销记录
- 描述：点击右上角“新建报销单”，开始提交你的第一条报销。

错误态文案：
- 标题：列表加载失败
- 描述：请检查网络连接，或稍后再试。
- 行为：提供一个【重试】按钮。

3.8 版本与范围：本次迭代做什么，不做什么

优秀的原型要帮助团队控制 scope，避免范围膨胀。建议在原型首页或每个模块首页注明：

• 本次迭代的功能范围（MVP 范围）
• 明确标记“未来版本考虑”的功能（用灰色/标签标出）
• 版本号与更新时间

示例：

迭代：V1.0 报销模块 MVP

本版本包含：
- 员工提交报销单（单人审批流）
- 管理员审核通过/驳回
- 报销单列表和详情查看

不包含（V1.1+ 再做）：
- 多级审批流配置
- 报销统计报表
- 导出 Excel

在原型中，可以对未来功能淡化处理，并加注 [下版本] 标记，避免开发误做。

---

四、如何在工具中具体实现：以 Axure/Figma 为例

4.1 模块化与组件化：避免“每页从零画起”

无论用什么工具，都建议：

1. 建立组件库（Design System / Widget Library） ：

   • 常用按钮样式（主按钮、次按钮、危险按钮）
   • 输入框、下拉、多选、日期选择器
   • 通知条/Modal/Drawer 等

2. 组件属性中加入注释/命名规范：

   • 例如按钮命名 btn-primary-submitReport，方便后续沟通。

4.2 交互示例（伪代码/逻辑设计）

虽然原型工具里的“交互配置”是可视化的，这里用接近代码的伪逻辑帮助你思考要表达的内容。

示例：列表勾选 + 批量操作

行为设计：

交互：勾选列表行

1. 当至少勾选 1 行时：
   - 批量操作工具条显示（从隐藏变为可见）
   - “批量删除”按钮激活（可点击）

2. 当 0 行被勾选时：
   - 批量操作工具条隐藏

在原型中体现的方法：

• 画出两种状态的头部区域：

  • 正常状态（无批量工具条）
  • 批量操作状态（带工具条）

• 用注释标明“此状态在勾选记录后出现”

示例：表单校验

逻辑：

校验时机：
- 失焦（Blur）时做单字段校验
- 点击提交时做整体验证

错误表现：
- 在字段下方显示红字错误信息
- 错误字段边框变红
- 错误信息集中显示在顶部提示条中，如有多个错误只列出前 3 条

在原型中：

• 展示一张“正常态表单”
• 展示一张“校验错误态表单”，标明错误提示样式和位置

---

五、优秀原型图方式的优缺点与实战建议

5.1 这样做原型的优点

1. 减少歧义，降低沟通成本

   • 开发、测试、UI 可以基于同一份“完整表达”的成果物协作。

2. 更准确的估时与范围控制

   • 原型中的状态、异常、权限等内容清晰后，开发可更准确估算工作量。

3. 便于复盘与演进

   • 有完整上下文和逻辑说明的原型图，可以在后续版本迭代时直接复用和调整。

5.2 可能带来的负担与风险

1. 前期投入增加

   • 产品/设计在原型阶段要投入更多时间思考与表达，短期看似“变慢”。

2. 过度细化的风险

   • 如果业务还非常不确定，过度细化原型细节容易造成浪费。

3. 工具依赖

   • 团队需要共同掌握并习惯使用同一套工具与规范。

5.3 实战中的具体建议

1. 根据阶段决定原型精细度

   • 需求还在探索期：

     • 用低保真原型（线框、流程为主），重点对齐用户路径和核心功能。

   • 需求已确认要开发：

     • 提升保真度，补全状态、交互、异常与字段说明。

2. 建立团队统一的原型规范

   • 明确每一页原型的“必备元素”：

     • 场景说明 / 权限说明 / 状态说明 / 边界情况

   • 可以做一份“原型检查清单”，评审前先自查。

3. 原型评审要看“逻辑”，不只是“外观”

   • 不要只讨论按钮颜色和布局，要刻意检查：

     • 关键业务流是否完整？
     • 异常与空态是否覆盖？
     • 权限与角色视图是否说明清楚？

4. 让原型成为需求文档的核心载体

   • 很多团队的实践是：

     • 传统长篇 PRD 简化为“原型 + 轻量说明 + 域模型”。
     • 以原型为中心，补充接口与数据字典链接。

---

六、结论：优秀原型图的本质是“对齐与约束”

总结一下：

• 一个优秀的原型图，不只是画页面，更要完整体现：

  1. 用户与场景（为谁、在什么情境下用）
  2. 信息架构与导航（整体结构）
  3. 页面布局与信息优先级
  4. 交互行为与状态变化（含空态、错误态等）
  5. 数据结构与字段说明（含校验规则）
  6. 权限差异和视图差异
  7. 版本范围与迭代计划

• 其价值在于：

  • 帮团队对齐业务理解；
  • 明确需求边界与异常情况；
  • 为设计、开发、测试提供统一的执行依据。

未来，在更多团队转向敏捷、持续交付的背景下，原型图会越来越成为“轻量但高价值的需求载体” ：
只要原型本身表达足够完整、足够清晰，很多冗长文档可以简化甚至省略。