第6章 交互原型设计 — Axure 实战
原型是产品经理的语言。评审会上，你说半天不如给一个可交互的原型。开发看了原型就知道要做什么，设计看了原型就知道风格方向。
我是怕浪猫，这一章不讲交互设计理论（理论你在其他地方看过无数遍了），只讲怎么用Axure画出一个"开发看了就知道怎么做"的原型。
6.1 Axure 工具基础
6.1.1 Axure 界面认知与基本操作
Axure的界面分五个区域：
页面面板（左侧）：管理页面结构。像文件夹一样，可以建子页面、拖拽排序、批量删除。
元件面板（左侧下方）：Axure内置的元件库。包括基础元件（矩形、文本、图片）、表单元件（输入框、按钮、下拉框）、菜单表格等。熟悉元件库是画原型的基础。
画布面板（中间）：原型的主编辑区。拖拽元件到画布上，排列组合。
样式面板（右侧）：调整元件的样式。位置、尺寸、填充色、边框、阴影、圆角。常用快捷键：Ctrl+D复制元件，Ctrl+G编组，Ctrl+Shift+G解组。
交互面板（右侧下方）：添加交互行为。点击、鼠标悬停、键盘事件等。交互是Axure区别于Sketch/Figma的核心能力。
五个核心快捷键
| 快捷键 | 作用 |
|---|---|
| Ctrl+D | 复制元件 |
| Ctrl+G | 将选中的元件编组 |
| Ctrl+Shift+G | 解组 |
| F5 | 预览原型 |
| Ctrl+S | 保存 |
6.1.2 元件库与页面管理
内置元件的使用
Axure的内置元件非常丰富，熟练使用这些元件能大幅提升效率：
基础元件：矩形（最常用）、文本标签、图片、热区 表单元件：文本框、文本域、下拉框、单选框、复选框、按钮 高级元件：动态面板、中继器、母菜单、树
动态面板（Dynamic Panel）
动态面板是Axure中最强大的元件。简单理解：动态面板就是"带状态的元件"。
举例：一个Tab切换器，包含"推荐"和"热门"两个Tab。每个Tab对应不同的内容。通过动态面板，可以实现点击Tab时切换显示不同的内容。
操作方法：选中Tab按钮，在交互面板中添加"点击时设置面板状态"的动作。
中继器（Repeater）
中继器是"可复制的元件组"。适合做列表页、卡片流等重复性内容。
操作方法：先设计一个"列表项"模板，然后给中继器设置数据源（手动输入或导入Excel），中继器会自动复制模板并填充数据。
6.1.3 交互事件与动作设置
Axure的交互通过"事件+动作"来实现。
常用事件类型
| 事件 | 触发条件 |
|---|---|
| OnClick | 单击 |
| OnMouseEnter | 鼠标悬停 |
| OnMouseOut | 鼠标离开 |
| OnFocus | 获得焦点（输入框） |
| OnLostFocus | 失去焦点 |
| OnKeyUp | 键盘按键释放 |
| OnLoad | 页面加载时 |
常用动作类型
| 动作 | 说明 |
|---|---|
| Set Text | 设置文本内容 |
| Set Image | 切换图片 |
| Show | 显示元件 |
| Hide | 隐藏元件 |
| Toggle | 切换显示/隐藏 |
| Move | 移动元件位置 |
| Set Panel State | 切换动态面板状态 |
| Open Link | 打开链接/页面 |
一个完整的交互示例：Tab切换器
Step 1：画Tab栏。两个按钮"推荐"和"热门"。
Step 2：画两个动态面板，每个Tab对应一个面板状态。
- "推荐"面板状态：显示推荐内容
- "热门"面板状态：显示热门内容
Step 3：给"推荐"按钮添加OnClick事件，动作是"设置面板状态为推荐"。
Step 4：给"热门"按钮添加OnClick事件，动作是"设置面板状态为热门"。
Step 5：预览（F5），点击Tab即可切换。
条件逻辑：if-else判断
实际产品的交互很少是"点击就完事"那么简单。更多时候，交互是有条件的——满足条件走A路径，不满足走B路径。Axure支持在交互动作上添加条件判断，这就是条件逻辑。
举个实战例子：登录按钮的交互。
- 如果用户名和密码都填写了 → 按钮可点击，跳转到首页
- 如果用户名或密码为空 → 按钮禁用，点击无响应
- 如果密码错误 → 弹出错误提示
在Axure中实现：
- 选中登录按钮，添加OnClick事件
- 添加条件：如果"用户名输入框文字不为空"且"密码输入框文字不为空" → 动作：Open Link跳转首页
- 添加Else If：如果"密码输入框文字"等于"123456" → 动作：Show错误提示"密码过于简单"
- 添加Else → 动作：Show错误提示"请填写完整信息"
条件编辑器支持的逻辑运算符：等于、不等于、包含、不包含、大于、小于、为空、不为空。多个条件之间可以设置"且"（全部满足）或"或"（满足任一）关系。
条件逻辑的典型应用场景
| 场景 | 条件判断 | 满足时行为 | 不满足时行为 |
|---|---|---|---|
| 表单提交 | 所有必填项已填 | 提交成功 | 高亮未填项 |
| 权限控制 | 用户角色=管理员 | 显示管理入口 | 隐藏管理入口 |
| 库存判断 | 库存>0 | 可加入购物车 | 显示"已售罄" |
| 金额判断 | 订单金额>=99 | 免运费 | 显示运费 |
| 版本判断 | 用户版本=VIP | 解锁高级功能 | 弹出升级提示 |
变量使用：全局变量与局部变量
条件逻辑离不开变量。Axure中的变量分两种：全局变量和局部变量。
全局变量：在整个原型中任何页面、任何元件都可以读取和修改。适合存储跨页面的状态信息。比如用户登录状态、购物车商品数量、当前选择的城市。
局部变量：只在当前交互动作的作用域内有效。适合临时计算或临时存储。比如获取某个输入框的当前文字、计算两个数值的差值。
全局变量的设置方法：顶部菜单 → 项目 → 全局变量 → 添加变量。建议命名规范：用大写+下划线，如USER_ROLE、CART_COUNT、IS_LOGGED_IN。
局部变量的设置方法：在添加交互动作时，点击"fx"按钮 → 添加局部变量 → 选择变量来源（元件文字、变量值等）。
实战案例：购物车数量同步
需求：商品详情页点击"加入购物车"，底部Tab栏的购物车图标上显示红点数字。
实现步骤：
- 创建全局变量CART_COUNT，初始值设为0
- 商品详情页的"加入购物车"按钮，OnClick事件添加动作：设置变量CART_COUNT = CART_COUNT + 1
- 底部Tab栏购物车图标旁的文本标签，在页面OnLoad事件中设置文字 = [[CART_COUNT]]
- 每次页面加载时，文本标签会自动读取CART_COUNT的值并显示
变量使用注意事项
| 事项 | 说明 |
|---|---|
| 命名规范 | 全局变量大写+下划线，局部变量小写+下划线 |
| 初始值 | 全局变量必须设置初始值，否则原型预览时会报错 |
| 数量控制 | 全局变量不要超过20个，多了难以维护 |
| 数值运算 | Axure变量本质是字符串，做加减运算时用[[变量名*1]]强制转数字 |
| 跨页面传递 | 全局变量天然跨页面，局部变量只能在当前交互中使用 |
6.2 交互原型绘制
6.2.1 交互设计原理与原则
交互设计不是"炫技"，而是"降低认知成本"。
交互设计五原则
原则一：一致性。相似的操作应该有相似的结果。同样的交互在不同地方表现一致，用户才能建立稳定的认知。
原则二：反馈及时性。用户的每一个操作都应该有即时的反馈。点击按钮后显示loading状态，操作完成后显示成功提示。
原则三：容错设计。允许用户犯错，并且提供撤销/恢复的途径。删除操作有确认提示，错误输入有明确提示。
原则四：效率优先。不要让用户做重复操作。如果能记住用户的偏好，就不要让用户每次都重新设置。
原则五：渐进式披露。不要一次性展示所有功能。先展示核心功能，高级功能在需要时再出现。
6.2.2 页面布局与信息层级
页面布局的核心是"信息层级"——让用户知道"先看什么、后看什么"。
三种经典布局模式
| 布局模式 | 特征 | 适用场景 | 示例 |
|---|---|---|---|
| F型布局 | 顶部和左侧信息优先级高 | 资讯类产品 | 今日头条 |
| Z型布局 | 左上→右上→左下→右下 | 营销落地页 | 淘宝banner |
| 卡片式布局 | 内容块独立，灵活组合 | 社交/内容流 | 微博、抖音 |
信息层级处理
层级一：大标题+副标题。告诉用户"这是什么东西"。
层级二：核心内容。用户打开页面第一眼要看到的信息。
层级三：辅助信息。用户在需要时才会查找的信息。
层级四：操作入口。用户要执行的动作。
原型中的视觉层级处理：字号大小、颜色深浅、留白间距都能区分层级。在Axure中，通过调整字体大小（标题24px、正文16px、辅助12px）和间距来建立清晰的层级。
6.2.3 交互状态设计（默认/悬停/激活/禁用）
好的交互设计要让用户感知到"系统的响应"。状态设计是实现这一点的关键。
按钮的四状态
| 状态 | 视觉表现 | 交互行为 |
|---|---|---|
| 默认 | 正常颜色 | 无特殊行为 |
| 悬停 | 颜色加深/轻微上移 | 鼠标悬停时触发 |
| 按下 | 颜色进一步加深/轻微下沉 | 鼠标按下时触发 |
| 禁用 | 灰色，无法点击 | 灰色状态，无法交互 |
输入框的三状态
| 状态 | 视觉表现 |
|---|---|
| 默认 | 灰色边框 |
| 聚焦 | 蓝色边框，光标闪烁 |
| 错误 | 红色边框，错误提示文字 |
| 禁用 | 灰色背景，无法输入 |
列表项的交互
| 状态 | 视觉表现 |
|---|---|
| 默认 | 正常显示 |
| 悬停 | 背景色变化，暗示可点击 |
| 按下 | 背景色变化（比悬停更深） |
| 选中 | 左侧出现选中指示器，如蓝色竖条 |
表单验证状态设计
表单是用户输入信息的核心载体，验证状态设计做得好不好直接决定用户能不能顺利填完。怕浪猫见过太多原型只画了"输入框+按钮"就完事，开发一看一脸懵：输了不对怎么办？哪儿不对？怎么提示？
表单验证分两种时机：实时验证和提交验证。
实时验证：用户在输入过程中即时反馈。适合格式类校验——手机号位数、邮箱格式、密码强度。用户输完一个字段就能知道对不对，不用等到点提交。
提交验证：用户点击提交按钮后统一校验。适合业务逻辑类校验——用户名是否已注册、优惠券是否过期。这类校验需要请求后端，无法实时完成。
表单验证状态一览
| 状态 | 触发时机 | 视觉表现 | 交互行为 |
|---|---|---|---|
| 未填写 | 页面初始加载 | 灰色占位符文字 | 无 |
| 正在输入 | 获得焦点并输入 | 蓝色边框，输入内容实时显示 | 可选：实时校验提示 |
| 输入正确 | 失去焦点时校验通过 | 绿色边框+对勾图标 | 无 |
| 输入错误 | 失去焦点时校验不通过 | 红色边框+错误提示文字 | 错误提示在输入框下方，文字要具体 |
| 禁用 | 特定条件未满足 | 灰色背景，不可编辑 | 鼠标悬停可提示禁用原因 |
错误提示样式规范
错误提示不能只说"输入有误"，要告诉用户具体哪里错了、怎么改。这是产品经理的责任，不要丢给开发去猜。
| 错误类型 | 错误提示文案（反面教材） | 错误提示文案（正确写法） |
|---|---|---|
| 必填为空 | 请填写信息 | 请输入手机号 |
| 格式错误 | 格式不正确 | 手机号应为11位数字 |
| 长度不足 | 长度太短 | 密码至少8位，还需输入N位 |
| 重复提交 | 操作失败 | 该手机号已注册，可直接登录 |
| 超出限制 | 输入超限 | 最多输入200字，已超出N字 |
在Axure中的实现方式：每个输入框下方预留一个文本标签（默认隐藏），校验不通过时Show该标签并设置错误文字。
加载状态设计
用户点击操作后到结果出来之前，这段时间就是加载状态。处理不好加载状态，用户就会以为系统卡死了，疯狂点击按钮，重复提交请求。
加载状态有三种主流方案：骨架屏、loading动画、进度条。选哪个取决于场景。
三种加载状态对比
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 骨架屏 | 页面首次加载、内容区域加载 | 用户能预判内容结构，感知等待时间短 | 需要设计骨架图，开发成本稍高 |
| Loading动画 | 操作反馈（提交、保存、删除） | 实现简单，通用性强 | 不知道要等多久，长时间等待焦虑 |
| 进度条 | 文件上传、批量处理、安装过程 | 用户知道进度，焦虑感最低 | 必须能获取真实进度，假进度反而更差 |
骨架屏设计要点
骨架屏的本质是"占位"。用灰色色块代替真实内容，让用户提前感知页面结构。
设计规范：
- 色块颜色用#F2F2F2或#E5E5E5，和背景形成轻微对比
- 圆角、间距和真实内容保持一致
- 文字行用圆角矩形代替，图片区域用方形色块
- 可以加一个从左到右的微光扫过动画（shimmer效果），暗示正在加载
在Axure中实现：画一个和真实页面结构完全一致的灰色版本，放在动态面板的"加载中"状态。页面OnLoad时先显示骨架屏状态，用Set Interval或Wait动作模拟2秒后切换到真实内容状态。
Loading动画设计要点
Loading动画用在哪里：按钮点击后、数据提交时、异步请求等待时。
设计规范：
- 按钮内的Loading：按钮文字变为"提交中..."，左侧加旋转图标，按钮置灰不可再次点击
- 页面级Loading：在内容区域居中显示旋转图标+"加载中"文字
- 时间预估：如果请求通常<1秒，只显示按钮内Loading即可；如果>1秒，需要页面级Loading
- 防重复提交：Loading期间按钮必须禁用，这是基本常识
进度条设计要点
进度条适合可量化的进度场景。关键原则：进度必须是真实的。
设计规范：
- 显示百分比数字："已上传 67%"
- 显示具体数据："已上传 34MB / 50MB"
- 预估剩余时间："预计还需 2分钟"
- 失败时可重试：进度条变红，显示"上传失败"+重试按钮
绝对不要做"假进度条"——那种到99%就停住然后突然跳完成的，用户一看就知道是假的，信任感直接崩塌。
6.2.4 从低保真到高保真原型
低保真vs高保真
| 类型 | 特征 | 适用场景 | 工具 |
|---|---|---|---|
| 低保真 | 线条和方框，无细节 | 快速验证想法 | 纸和笔、白板 |
| 中保真 | 有色块和基本交互 | 评审和讨论 | Axure基础功能 |
| 高保真 | 接近真实设计稿 | 开发参考、用户测试 | Axure+图片+Figma |
高保真原型制作流程
第一步：标注设计稿。把UI设计稿导入Axure，放在每个页面的背景层（设为隐藏），然后在背景层上覆盖元件。
第二步：精确还原设计稿的视觉。字号、颜色、间距、圆角——每一个细节都要对齐设计稿。
第三步：添加全部交互。包括加载状态、空状态、错误状态、边界处理。
第四步：添加页面跳转。从首页到详情页，从列表到筛选结果——完整的用户路径都要通。
第五步：自检和测试。在Axure中模拟用户操作，检查每一个交互是否流畅。
原型不是"画完就完了"，而是"开发看了就知道怎么做"。一个好的原型，能让开发减少80%的疑问。
原型评审checklist
评审原型不是"看看有没有漏画元件"，而是要从用户视角走一遍完整流程。怕浪猫每次评审前都会过一遍这个清单，能筛出80%的低级问题。
功能完整性
| 检查项 | 检查标准 | 常见问题 |
|---|---|---|
| 主流程是否完整 | 从入口到结束的全部页面是否都有 | 只画了一半流程，后面页面缺失 |
| 分支流程是否覆盖 | 每个选择点的不同结果是否有对应页面 | 只画了成功路径，失败路径没画 |
| 操作闭环是否形成 | 每一步操作后用户下一步去哪 | 操作完成后没有反馈，用户不知道成功了没 |
| 核心功能是否可交互 | 关键按钮、表单、筛选是否都能点击 | 只做静态展示，没有真实交互 |
交互一致性
| 检查项 | 检查标准 | 常见问题 |
|---|---|---|
| 相同元件状态是否一致 | 所有按钮的悬停、按下状态统一 | 不同页面的按钮颜色、圆角不一致 |
| 交互反馈是否统一 | 同样的操作在不同地方反馈相同 | 有的地方成功弹窗，有的地方成功toast |
| 返回逻辑是否一致 | 每个页面从哪来回哪去 | 点返回时有时候回首页，有时候回上一页 |
| 手势/快捷键是否一致 | 同类型操作用同样的手势或快捷键 | 列表页左滑删除，详情页右滑删除 |
边界情况
| 检查项 | 检查标准 | 常见问题 |
|---|---|---|
| 超长内容如何处理 | 文字超长、列表超长、图片超长 | 没做截断、换行或滚动 |
| 数量边界 | 数量为0、为1、达到上限 | 没有上限提示，数量爆了页面布局错乱 |
| 时间边界 | 活动开始/结束、倒计时 | 活动结束后页面没变化 |
| 权限边界 | 游客、普通用户、VIP | 不同角色看到的内容没有区分 |
空状态处理
| 场景 | 空状态表现 | 错误做法 |
|---|---|---|
| 列表无数据 | 显示空状态插画+引导文字+操作按钮 | 直接白屏，用户不知道是没数据还是加载失败 |
| 搜索结果为空 | 提示"暂无结果"+推荐搜索词 | 显示"0条结果"就完事 |
| 网络异常 | 显示错误提示+重试按钮 | 页面空白，用户反复刷新 |
| 无权限 | 说明原因+引导升级/登录 | 直接显示403错误 |
错误处理
| 检查项 | 检查标准 | 常见问题 |
|---|---|---|
| 操作失败是否有提示 | 提交、保存、删除失败都要提示 | 失败时页面没反应 |
| 错误提示是否明确 | 告诉用户为什么失败、怎么解决 | 只显示"系统错误" |
| 是否允许重试 | 失败后提供重试入口 | 失败后只能退出重来 |
| 是否保留用户输入 | 提交失败后已填内容不要清空 | 失败后表单被清空，用户重新填一遍 |
原型与设计稿的交接规范
原型和最终视觉设计稿是两个东西，但开发接的时候容易混淆。怕浪猫建议做一个清晰的交接规范，让开发一眼知道哪个是原型、哪个是设计稿、哪个是交互说明。
交接文档必备要素：
- 页面清单：列出每个页面名称、对应原型页面链接、对应设计稿链接
- 交互说明：每个页面右侧留白写交互说明，用文字描述无法从视觉上直接看出的逻辑
- 状态清单：列出该页面所有可能的状态（默认、空、加载、错误、无权限等），分别标注对应设计稿
- 动效说明：哪些动画需要开发实现，给出持续时间、缓动函数、触发条件
- 变量和全局状态说明：哪些数据是全局的，在不同页面之间如何传递
建议用Axure的页面注释功能，直接在页面树右侧写交互说明。不要用微信群发语音，语音里的信息开发根本找不到。
交接检查清单
| 检查项 | 是否完成 | 说明 |
|---|---|---|
| 原型已覆盖全部页面 | 是/否 | 主流程和分支流程都包含 |
| 每个页面已标注交互说明 | 是/否 | 点击、滑动、跳转、状态变化都写清楚 |
| 设计稿和原型已对齐 | 是/否 | 颜色、字号、间距一致 |
| 全部状态已画完 | 是/否 | 默认、空、加载、错误、边界状态 |
| 动效和过渡已说明 | 是/否 | 持续时间、触发条件、目标状态 |
| 变量和全局状态已说明 | 是/否 | 登录态、购物车、筛选条件等 |
| 已和开发对评审通过 | 是/否 | 开发确认没有歧义 |
6.2.5 移动端原型设计要点
移动端原型的交互和PC端完全是两个逻辑。PC端靠鼠标点击，移动端靠手指触摸。你画移动端原型时如果还只考虑点击，那开发拿到手还得补一堆手势和状态。
手势交互设计
移动端有四种常用手势：滑动、长按、拖拽、捏合缩放。每种手势对应不同的场景，不要瞎用。
常用手势及应用场景
| 手势 | 典型场景 | 交互反馈 | 注意事项 |
|---|---|---|---|
| 滑动 | 切换Tab、轮播图、列表刷新、删除列表项 | 跟随手指移动，松手回弹或切换 | 要有明确的滑动边界和惯性效果 |
| 长按 | 弹出操作菜单、进入编辑模式、收藏 | 按压后震动反馈或背景变暗 | 长按时间通常500ms-800ms，太短误触，太长用户等不及 |
| 拖拽 | 调整排序、移动图标、拖拽文件 | 被拖拽元素半透明，目标位置高亮 | 要有明确的放置区域，放下后给出成功反馈 |
| 捏合缩放 | 图片查看、地图缩放、网页缩放 | 双指距离变化同步缩放 | 缩放中心和边界要处理好，不要无限放大 |
滑动交互的设计细节
滑动是最常用的手势，但很多人的原型只画一个"可左右滑动"的箭头，开发看了完全不知道怎么实现。完整的设计应该包含：
- 滑动方向：水平还是垂直
- 触发区域：整屏可滑还是只有某个区域可滑
- 滑动边界：滑到边缘是否回弹，是否显示"没有更多"
- 切换效果：是否有过渡动画，动画持续多久
- 指示器：当前在第几页，有几个可滑页面
在Axure中实现滑动：用动态面板包裹可滑动内容，设置"拖动时"交互，用Move动作让内容跟随鼠标移动。松手时根据位置判断切换到上一页/下一页/回弹。
长按交互的设计细节
长按操作隐蔽，用户不一定知道。需要给视觉暗示：比如列表项右侧有三个点图标，或者文字提示"长按更多操作"。
在Axure中实现长按：给元件添加OnMouseDown事件，设置Wait 700ms，然后触发动作。如果OnMouseOut在700ms内发生，则取消动作。可以用条件判断实现这个逻辑。
拖拽交互的设计细节
拖拽适合排序、整理等场景。设计时要明确：
- 可拖拽元素：哪些元素可以拖，哪些不能拖
- 拖拽时的视觉变化：透明度变化、阴影、缩放
- 放置目标：哪些地方可以放置，放不进去怎么办
- 排序规则：拖放到两个元素之间时，插入到谁前面
在Axure中实现拖拽：用Move动作配合"拖动时"事件，让元件跟随鼠标位置。松手时判断位置是否在某个目标区域内，是则移动到新位置，否则回到原位。
捏合缩放的设计细节
捏合缩放主要在图片浏览、地图、PDF阅读场景。Axure本身对双指手势的支持有限，但原型中可以通过文字说明+手势标注来表达。
标注内容：
- 最小缩放比例和最大缩放比例
- 缩放中心：以手指中心为缩放中心还是屏幕中心
- 缩放后的操作：双击还原、双指缩放、单击隐藏UI
移动端特殊状态
移动端比PC端多了一堆特殊状态，这些状态如果没考虑到，用户在外面用起来会很崩溃。
弱网状态
用户在地铁、电梯、地下停车场里会频繁遇到弱网。弱网状态设计要点：
- 不要长时间白屏：1秒内还没数据就显示骨架屏或加载提示
- 请求超时：超过3-5秒没有响应要给出"网络较慢"提示
- 降级方案：图片加载失败时显示占位图，视频加载失败时提示"重试"
- 重试机制：提供"点击重试"按钮，不要让用户只能退出App
弱网状态文案建议：
| 状态 | 文案建议 | 反面教材 |
|---|---|---|
| 加载慢 | 网络好像有点慢，正在努力加载中 | 加载中... |
| 请求超时 | 网络连接超时，请检查后重试 | 请求失败 |
| 图片加载失败 | 图片加载失败，点击重新加载 | 空白图片 |
| 数据加载失败 | 内容加载失败，下拉刷新试试 | 暂无数据 |
离线状态
离线比弱网更严重。用户可能完全没网。离线状态设计要点：
- 区分"从未加载过"和"加载过但现在没网"：前者显示引导页，后者显示已缓存内容+离线提示
- 可离线功能：阅读、笔记、播放已下载内容等，要明确告诉用户哪些可以离线用
- 自动重连：网络恢复后自动刷新，不需要用户手动操作
- 离线操作队列：用户在离线时提交的操作，恢复网络后自动同步
在Axure中设计离线状态：可以做一个"网络状态"全局变量，值为online/offline。页面OnLoad时根据变量值显示不同状态。切网时通过条件逻辑切换变量和页面状态。
推送通知
推送通知是移动端特有的触达方式。原型里经常只画一个"推送"开关，但完整的推送设计应该包含：
- 通知触发条件：什么情况下发推送，发几次，间隔多久
- 通知内容结构：标题、正文、缩略图、动作按钮
- 点击通知后的跳转：打开App到哪个页面，是否带参数
- 通知设置：用户可以在设置里关闭哪些类型的通知
- 勿扰模式：夜间、会议期间是否要合并或延迟发送
推送通知设计原则：
- 不要滥用：一天内同一类推送不要超过3条，多了用户直接关通知
- 内容具体：不要"您有一条新消息"，要"张三回复了你的评论：写得不错"
- 提供直达：点击推送后直接进入相关内容，不要让用户再去找
- 允许撤销：用户误触后5秒内可以撤销，收回通知
在Axure中模拟推送：可以用动态面板做一个"通知横幅"，默认隐藏。通过按钮触发Show，设置自动Hide（Wait 3秒后隐藏）。
移动端原型尺寸建议
画移动端原型时，画布尺寸要按目标设备来，不要在PC尺寸上画移动端。
| 设备类型 | 建议画布尺寸 | 说明 |
|---|---|---|
| iPhone 14/15 | 393 × 852 | 带灵动岛状态栏要留出空间 |
| iPhone SE | 375 × 667 | 小屏设备，注意底部安全区 |
| Android主流 | 360 × 800 | 全面屏，底部手势区域要避开 |
| iPad | 768 × 1024 | 横屏竖屏两种状态都要考虑 |
底部安全区：全面屏手机底部有手势条区域，重要按钮不要贴底，至少留34-44px。顶部状态栏：时间、信号、电量区域不要放重要信息。
本章小结
Axure是产品经理画原型的标配工具。掌握元件使用、动态面板、交互动作，就能画出中保真原型。加上高保真的视觉还原和完整的状态设计，就能画出给开发参考的高保真原型。移动端原型还要额外考虑手势交互和弱网、离线、推送等特殊状态。
| 本章核心知识点 | 一句话总结 |
|---|---|
| 元件使用 | 矩形+文本=90%的原型内容 |
| 动态面板 | 带状态的元件，实现Tab切换等交互 |
| 中继器 | 批量生成重复内容，如列表页 |
| 交互事件 | OnClick、OnMouseEnter等触发条件 |
| 交互动作 | Show/Hide/Set Text等响应行为 |
| 条件逻辑 | if-else让交互有分支判断 |
| 变量使用 | 全局变量跨页面，局部变量做临时计算 |
| 四状态设计 | 默认/悬停/按下/禁用，缺一不可 |
| 表单验证 | 实时验证+提交验证，错误文案要具体 |
| 加载状态 | 骨架屏/Loading/进度条，按场景选择 |
| 高保真要点 | 视觉还原+完整交互+页面跳转 |
| 原型评审 | 功能完整、交互一致、边界、空状态、错误处理 |
| 交接规范 | 页面清单、交互说明、状态清单、动效说明、变量说明 |
| 移动端要点 | 手势交互+弱网/离线/推送状态+安全区 |
觉得有用？收藏起来，下次画原型直接照抄。
你画原型时踩过什么坑？评论区说说。
关注怕浪猫，下期我们讲"产品需求文档（PRD）撰写"——PRD怎么写才不会被开发怼，需求怎么描述才没有歧义，怕浪猫的经验之谈。
系列进度 6/16
下章预告： 第7章，PRD是产品经理最重要的输出物之一。很多人写的PRD——逻辑混乱、细节缺失、异常流程全靠开发脑补。下一章，我教你写出一份"开发看了不骂人"的PRD。