APP弹窗设计先看任务是否必须中断：删除草稿需要确认，网络异常需要告诉用户下一步，短结果适合轻提示，长任务应展示进度和恢复入口。以“提交订单”为样本，原型至少要连起触发、确认、处理中、结果未知、失败重试和返回页面，单独展示一张白框无法说明流程是否可用。
可以在墨刀原型中把弹窗与前后页面连起来，再按触发条件、阻断级别和关闭去向选择样式。下面的分类保留了确认、提示、输入、加载、轻量反馈和引导六类场景，同时给出可直接复用的状态检查方法。
1.确认弹窗
用途：用于提示用户进行关键操作的确认，如删除、提交或退出。
设计重点：
- 明确的标题和说明文字，直截了当地告知操作后果。
- 按钮文案说明具体动作，如“保留草稿”和“删除草稿”；用视觉层级区分操作，不只依靠颜色。
- 保持简洁，避免文字冗长。
确认弹窗应把对象和后果写清楚。例如，“删除这份未发布的草稿？删除后无法恢复”比“确定操作吗”更容易判断。若操作可以立即撤销，轻提示配撤销入口可能比连续弹出确认框更合适。
关闭规则也要写进原型：点取消、遮罩和系统返回键是否都意味着“不执行”；关闭后是否仍停在原位置。危险操作不应因误触遮罩而提交，返回页面时也应保留原来的选择和滚动位置。
2.提示弹窗
用途：传达系统状态、错误信息或重要通知。
设计重点：
- 先说明问题与下一步，再用颜色或图标辅助表达；错误不能只靠红色区分。
- 纯告知可提供“知道了”；需要处理的问题应给出“重新连接”“查看设置”等具体入口。
- 可支持图标，如感叹号或警告符号，强化信息传递。
提示应尽量靠近发生问题的位置。表单中的手机号格式错误，优先在输入框附近说明；只有阻止整个任务继续的问题，才需要考虑弹窗。不要把多个字段错误逐个弹出来，让用户关闭一个又遇到一个。
网络异常时要区分“请求失败”和“结果尚未确认”。涉及提交订单、付款或创建记录的操作，先给查询结果的路径，避免一句“失败，请重试”诱导用户重复提交。
3.输入弹窗
用途：要求用户输入信息，如登录、填写表单、评论。
设计重点：
内置输入框，支持单行与多行输入。
清晰的操作按钮，如“提交”、“取消”。
布局合理，输入区与按钮保持易操作距离，适合拇指触控。
以重命名弹窗为例，需要准备初始值、空值、超长、重名、提交中和保存失败等状态。错误出现后保留已输入内容，并把提示放在相关字段旁边。取消是否丢弃输入，应该和任务重要程度匹配。
手机键盘弹出后，再检查输入框、提示与按钮能否看见；多行内容是否能滚动，关闭键盘后布局是否恢复。若必须连续填写多个字段、阅读长协议或频繁切换页面，就不宜继续挤在一个小弹窗内。
4.加载弹窗
用途：提示用户当前操作正在进行，避免二次点击。
设计重点：
简洁的环形加载动画或进度条。
可配合文字说明，如“正在加载，请稍候”。
是否允许取消由任务决定；等待过久时必须有明确说明或恢复路径，不能让加载层无限遮挡页面。
有可靠进度时显示进度；没有进度时说明正在做什么，不要使用虚假的百分比。能够后台完成的任务，可以释放页面并保留状态入口；必须阻止继续操作的任务，则要写明超时后的行为。
“取消等待”也不一定等于“取消服务端任务”。例如文件已提交处理，用户关闭加载层后应能找到处理结果。原型中分别标注请求发出、处理中、完成、失败与结果不明，研发才能确认每一条退出路径的含义。
5.轻量级悬浮弹窗
用途：短暂提示用户操作结果或提醒，不打断流程。
设计重点：
- 通常出现在屏幕底部或顶部，尺寸小巧。
- 简短、可忽略的状态可以自动消失；需要阅读、修复或撤销的信息应有可再次找到的入口。
- 颜色和图标区分不同类型的提示，如成功、失败或普通信息。
轻量提示适合“已复制”“已保存草稿”等结果，不适合承载长说明或重要错误的唯一证据。连续操作时应避免提示层层堆叠，也不要遮住底部主按钮、输入框和系统手势区域。
模板中的状态反馈卡片可供参考，但设计Toast时应按任务减小内容与占用面积。如果提示要求用户作选择，或不操作就无法继续，它已经不是无需处理的轻提示，应采用相应的确认或错误处理方式。
6.引导弹窗
用途：新用户指引、功能介绍或操作步骤提示。
设计重点：
- 通常配合遮罩效果突出重点区域。
- 文字简洁明了，引导用户完成特定操作。
- 支持“跳过”选项和逐步导航，提升新手体验。
引导应出现在用户正需要了解功能时。第一次进入就连续展示多个遮罩，容易让人只想跳过；更有效的做法是先解释当前一步能解决什么问题，并保留以后查看的入口。退出引导不应影响正常使用，已经完成的提示也不应每次重新出现。
评审这6类弹窗时，至少走一遍“触发—理解—操作—关闭—回到任务”的路径。弹窗越能解释为什么出现、现在能做什么、关闭后会怎样，用户越不需要试错。更多页面布局方法可参考APP界面设计技巧。
选对工具，更快更好设计App弹窗
制作弹窗原型时，先画出触发前的页面，再安排浮层和操作后的结果页。只画一张弹窗会遗漏关闭、键盘、滚动位置和失败恢复等问题。下面几类产品操作可用于把这些规则表达清楚。
搭建浮层：按任务选择居中或底部等布局，把内容、遮罩和按钮放在一起检查；同时准备关闭后的页面，而不只替换一份弹窗文案。
复用模板：先保留适合的布局和控件，再替换实际任务、对象名称和按钮文字。模板中的默认规则不一定适合当前业务，特别是删除、付款和信息提交。
连接触发与结果：把按钮与浮层、取消与返回、提交与成功或失败页面连起来。预览时分别走正常和异常路径，确认用户不会被困在加载中，也不会在关闭后丢失已经填写的内容。
围绕同一版本讨论：产品确认触发条件与业务后果，设计检查信息层级和可操作区域，研发确认是否可取消、何时超时以及如何查询结果。评论应落在具体页面和状态上。
交付可执行的规则：在页面旁写明触发条件、关闭方式、按钮动作、异常反馈和返回位置。例如“点击遮罩只关闭浮层，保留输入”就比“支持关闭”更明确。
可以从文中的弹窗模板选一个相关样式，进入墨刀补齐触发、关闭与异常路径，再邀请团队预览讨论。完成一条真实可解释的流程，比在页面里加入更多弹窗更有价值。
提交订单的弹窗状态链
先准备一个订单、一个库存不足的失败响应和一个网络超时场景。每个弹窗都要回答“用户为什么看到它、关闭后回哪里、失败后能做什么”，再决定使用确认弹窗、底部弹层或独立页面。
| 状态 | 用户看到什么 | 关闭或下一步 | 验收结果 |
|---|---|---|---|
| 确认提交 | 商品、金额、配送信息和明确动作 | 取消留在订单页，确认进入处理中 | 不会因遮罩误触提交 |
| 处理中 | 正在提交且按钮不可重复点击 | 等待结果或查看订单状态 | 返回后状态可恢复 |
| 库存不足 | 缺货商品与调整建议 | 修改数量、移除商品或返回购物车 | 已填写信息不丢失 |
| 网络超时 | 结果未知与再次查询入口 | 重试或稍后查看订单 | 不会让用户重复扣款 |
- 先画触发前页面和完成后页面，再补弹窗和遮罩。
- 为确认、加载、成功、失败和关闭分别写出焦点与返回规则。
- 用真实长度的商品名和错误提示检查窄屏折行。
- 让产品确认打断是否必要，让研发确认接口重复提交与键盘返回边界。
交付时留下触发条件、按钮动作、关闭方式、保留字段和失败恢复五项说明，团队才能复用弹窗规则。
弹窗选型要先看触发和退出
同一类内容可能需要不同的呈现方式。把“删除草稿”与“保存成功”放在同一条任务里，先判断动作是否可逆、用户是否必须立即处理、关闭后应回到哪里，再决定使用确认弹窗、提示条、抽屉、底部弹层还是全屏页面。
| 任务特征 | 适合的反馈 | 必须写清 |
|---|---|---|
| 不可逆且需要确认 | 确认弹窗 | 影响范围、主次按钮和取消后的去向 |
| 短暂结果 | 提示条或轻提示 | 停留时间、再次查看入口和失败处理 |
| 需要连续编辑 | 抽屉或底部弹层 | 滚动、保存、关闭和草稿保留 |
| 长表单或复杂任务 | 独立页面 | 返回路径、进度、校验和中断恢复 |
- 先画触发前页面和完成后页面，再补弹窗本身。
- 写出加载、成功、失败、权限不足和重复提交五种状态。
- 用墨刀原型连接主路径和回退路径，检查关闭、返回和重试不会丢数据。
- 让产品确认打断是否必要，让研发确认焦点、键盘和接口边界。
弹窗验收时至少记录触发条件、阻断级别、关闭行为和恢复结果；只检查圆角、阴影和颜色，无法判断它是否帮助用户完成任务。
