第1章 Axure原型工具与功能边界概念

用户场景：原型评审中的“边界黑洞”

产品经理在评审原型时，常被开发追问：“这个按钮点完后，如果网络断了怎么办？”“搜索框只接受中英文吗？数字和特殊符号呢？”——这些追问的实质是功能边界不清晰。边界缺失导致原型在被开发前就出现理解歧义，最终返工或上线后暴露缺陷。

业务问题：模糊边界 = 隐性成本

• 沟通成本：开发与设计反复确认“到底支持什么”；
• 测试成本：测试用例无法覆盖边界情况，遗漏异常分支；
• 上线风险：边界未定义的行为可能触发崩溃或数据丢失。

用户访谈：一线PM的真实反馈

我们对5位B端产品经理进行了结构化访谈，核心发现：

痛点类别	典型表述	频次
原型缺乏边界标注	“Axure原型里只有理想态，没有‘如果…就…’逻辑”	5/5
交互面板复杂	“条件判断太多，我自己都会忘哪些情况没写”	4/5
验收标准模糊	“开发说实现了，但边界处理和我预期不一样”	5/5

需求拆解：功能边界三要素

功能边界 = 响应范围 + 异常处理 + 状态限制：

要素	定义	Axure中对应
响应范围	输入/操作的有效值集合，如“搜索框只支持汉字、字母、数字，最多20字符”	部件交互 > 输入框 > 值验证条件
异常处理	输入无效或系统异常时的兜底行为，如“网络超时显示重试弹窗”	交互面板 > 条件分支 > 失败用例
状态限制	功能可被使用的场景约束，如“未登录状态下隐藏‘收藏’按钮”	动态面板 > 显示状态 > 条件判断

方案表达：Axure四面板支撑边界定义

通过Axure的四大核心界面元素，将功能边界直接“画”在原型中：

1. 界面布局——划定功能出现的位置与可见区域；
2. 部件库——使用标准组件（如输入框、下拉框）自带边界属性；
3. 交互面板——通过条件判断、用例管理、事件链定义边界逻辑；
4. 功能边界定义（本课程独创）——在原型旁附上边界卡片，标注三要素。

指标验证：边界覆盖率与违反次数

验证边界定义质量的两个核心指标：

• 边界覆盖率 = 已定义边界的功能点 ÷ 需定义边界的功能点 × 100%（目标≥95%）；
• 边界违反率 = 开发实现中违反边界定义的次数 ÷ 总测试用例数 × 100%（目标≤2%）。

验收标准

验收项	标准	通过条件
界面布局	每个交互元素都有明确的可见/隐藏规则	动态面板状态覆盖所有场景
部件库	输入框已设置类型、长度、字符限制	部件交互属性完整填写
交互面板	每个事件至少包含2个用例（成功+异常）	用例数≥功能路径数
边界卡片	原型旁附带边界定义表格	每页面都有对应卡片（按交付物模板）

交付物模板：功能边界定义卡片

本章涉及的核心交付物——每页原型需附一张边界卡片：

元素名称	响应范围	异常处理	状态限制	优先级
搜索输入框	汉字、字母、数字；长度1~20	超长截断；输入非法字符时清空并弹窗提示	登录后可见；搜索按钮同时激活	P0
提交按钮	点击后触发提交逻辑	网络失败3s超时重试；错误码401跳转登录页	表单必填项不全时按钮置灰	P0
侧边栏导航	点击切换页面	页面加载失败保留当前页并提示	用户角色无权限时隐藏对应菜单项	P1