最后更新:
通知文本的 UX 设计 - 应用内通知、Toast 和 Banner 的最佳字数
应用内通知、Toast 消息和 Banner 通知是在不中断用户操作流程的情况下传递信息的 UI 组件。然而，在显示时间有限的 Toast 中塞入长文，或 Banner 通知的字数太少导致无法传达含义，这类字数设计失败在日常中屡见不鲜。推送通知的字数设计受 OS 层面限制的约束，而应用内通知由开发者自由设计，因此适当的字数判断更为重要。
通知组件分类与基本字数设计
应用内通知组件按显示时间、显示位置和是否需要用户操作进行分类。需要根据各组件的特性进行相应的字数设计。
| 组件 | 显示时间 | 显示位置 | 是否需要操作 | 推荐字数 | 用途 |
|---|---|---|---|---|---|
| Toast | 3-5 秒 | 屏幕底部或顶部 | 不需要 (自动消失) | 15-40 字 | 操作成功/失败确认 |
| Snackbar | 5-10 秒 | 屏幕底部 | 可选 (带操作按钮) | 20-50 字 | 确认 + 撤销 |
| Banner | 持续 (手动关闭) | 屏幕顶部 | 需要 (关闭按钮) | 30-80 字 | 重要公告、系统状态 |
| 内联提示 | 持续 | 内容区域内 | 不需要 | 40-120 字 | 表单错误、注意提醒 |
| 模态对话框 | 持续 (直到操作) | 屏幕中央 | 需要 (确认/取消) | 50-200 字 | 重要确认、破坏性操作警告 |
| 通知中心 (应用内) | 持续 (列表) | 专用页面 | 不需要 | 40-100 字 | 历史通知列表 |
字数限制最严格的是 Toast。在 3-5 秒的显示时间内传达内容，日语 15-40 字是实用上限。决定这个上限的，与其说是阅读速度本身，不如说是开始阅读之前的那段延迟。Toast 会毫无预告地出现在屏幕一角，用户察觉它并把视线移过去就要花掉时间，能真正用来跟读文本的往往只剩显示时间的一半左右。刚完成操作时，眼睛还停在刚按下的按钮上，而那个位置常常离屏幕底部的 Toast 很远。与其从阅读速度反推出一个理论上限，不如把文本放到实机上显示，用眼睛确认它是否在读完之前就消失了。
Toast 消息的字数设计 - 3 秒内传达的技术
Toast 消息作为用户操作的即时反馈。"已保存""已复制""已发送"等简短确认消息是典型用途。
| 模式 | 字数 | 示例 | 评价 |
|---|---|---|---|
| 仅动词 | 3-5 字 | "已保存" | ○ 最简洁但不清楚保存了什么 |
| 对象 + 动词 | 8-15 字 | "草稿已保存" | ◎ 对象明确且简洁 |
| 对象 + 动词 + 补充 | 15-30 字 | "草稿已保存。自动保存每 5 分钟执行一次" | △ 对 Toast 来说太长 |
| 图标 + 动词 | 3-8 字 | "✓ 保存完成" | ○ 图标增强可见性 |
"对象 + 动词"模式 (8-15 字) 是 Toast 消息的最佳字数范围。明确对象可以让用户在多个操作并行时 (如上传文件的同时保存设置) 准确判断哪个操作已完成。
在 Toast 中添加"撤销"按钮时，应设计为 Snackbar 并将显示时间延长至 5-10 秒。Gmail 的"邮件已发送 - 撤销"是这种模式的典型案例。包含撤销按钮时，消息文本应控制在 20 字以内，并确保按钮有足够的点击区域。
Banner 通知的字数设计 - 持续显示的信息密度
与 Toast 不同，Banner 通知会持续显示直到用户手动关闭。因此可以包含更多信息，但由于持续占用屏幕有效区域，字数过多会妨碍内容浏览。
Banner 通知的字数根据显示位置和用途有不同的最佳值。
| Banner 类型 | 推荐字数 | 示例 | 操作按钮 |
|---|---|---|---|
| 信息 Banner (Info) | 30-60 字 | "新功能：深色模式现已可用" | "试试看"/"关闭" |
| 警告 Banner (Warning) | 30-70 字 | "您的支付方式即将到期，请更新" | "更新"/"稍后" |
| 错误 Banner (Error) | 30-80 字 | "服务器连接不稳定，部分功能受限" | "重试"/"详情" |
| 成功 Banner (Success) | 20-50 字 | "套餐升级已完成" | "查看详情"/"关闭" |
| Cookie 同意 Banner | 50-120 字 | "本站使用 Cookie 以提升您的体验" | "同意"/"设置" |
Cookie 同意 Banner 因 GDPR 的影响在全球网站中普及，但也是字数设计失败最多的组件。为满足法律要求而塞入 200 字以上说明文的 Banner 会占据屏幕三分之一以上，严重妨碍内容访问。Cookie Banner 正文应控制在 50-120 字，详情通过"Cookie 政策"页面的链接提供。
通知的层级设计 - 紧急程度与字数的关系
根据通知的紧急程度选择适当的组件和字数的层级设计至关重要。错误消息设计中介绍的重要度分类也适用于通知全般。
| 紧急程度 | 推荐组件 | 字数 | 示例 | 用户操作 |
|---|---|---|---|---|
| 低 (确认) | Toast | 10-25 字 | "设置已保存" | 不需要 |
| 中 (注意) | Snackbar / Banner | 20-60 字 | "存储使用量已达 80%" | 可选 |
| 高 (警告) | Banner / 内联提示 | 30-80 字 | "需要安全更新，请在设置中更新" | 建议 |
| 紧急 (立即处理) | 模态对话框 | 50-150 字 | "有未保存的更改。确定不保存就离开吗？" | 必须 |
对低紧急度通知使用长文或以模态对话框显示，会产生"狼来了"效应。不重要的通知频繁中断用户操作，真正重要的通知也会被忽视。严格匹配通知紧急度与字数、组件选择，是维护整个通知系统可信度的关键。
作为微文案的通知文本
通知文本是 UX 写作中"微文案"的典型代表。需要在短小的字数中凝缩情况说明、情感关怀和下一步行动指引的技术。
将有效微文案原则应用于通知文本：
- 具体描述："发生错误"改为"图片上传失败 (文件大小上限：5 MB)"。具体传达发生了什么、为什么发生
- 从用户视角描述："数据库连接错误"改为"当前无法连接服务，请稍后重试"。传达对用户的影响和解决方法，而非技术原因
- 正面表达："密码错误"改为"密码不匹配，请重试"。避免否定表达，提供解决方案
- 保持一致的语气：在整个应用中统一通知的语气 (正式/随意)。与聊天机器人消息设计一样，反映品牌声音
设计系统中的通知文本指南
在大型应用中，多个团队独立创建通知文本，导致字数和语气不一致。将通知文本指南纳入设计系统可以维护一致性。
| 指南项目 | 规则 | 示例 |
|---|---|---|
| 最大字数 | Toast：40 字，Banner：80 字，模态：200 字 | 通过 Lint 规则自动检查 |
| 句末表达 | 统一为"已……""请……" | "已保存""请更新" |
| 标点 | Toast 不加句号，Banner 以上加句号 | "已保存" vs "需要更新。" |
| 图标使用 | 成功：✓，警告：⚠，错误：✕，信息：ℹ | 在文本前放置图标 |
| 操作按钮 | 以动词开头，8 字以内 | "更新""查看详情""关闭" |
| 技术术语 | 面向用户的文本中禁止使用 | "HTTP 500"改为"服务器错误" |
这里有一点需要强调：上表这类字数上限，并没有写进任何官方设计指南。翻遍平台的设计指南，也找不到针对 Snackbar 或 Alert 的字数上限。文本分量通常是用行数或句数来描述的，因为一行能容纳多少字会随屏幕宽度、文字大小和语言而变化，字数无法充当共同基准。反过来看，这恰恰是设计系统自己的工作：在应用支持的最窄宽度下量出一行能放多少字，再把以行为单位的规则换算成自己的字数上限。上表中的数字也应当同样看待，它是把这次换算结果固定下来、供团队内部共用的约定，而不是有外部权威背书的规定。
通知频率与字数的平衡
通知字数设计不仅要考虑单条通知，还需要考虑一定时间内显示的通知总量。即使每条通知字数适当，短时间内大量显示也会导致用户"通知疲劳"。
- 批量处理：短时间内发生多条同类通知时，合并为"已上传 3 个文件"而非逐条显示。字数增加但减少通知次数可提升整体 UX
- 优先级过滤：低优先级通知仅记录在通知中心，不显示 Toast 或 Banner。用户主动查看时才可浏览
- 冷却期：同类通知至少间隔 30 秒。连续通知用后一条覆盖前一条
- 聚合通知："田中和其他 4 人发表了评论"将多个事件合并为一条通知。相比逐条显示"田中发表了评论""佐藤发表了评论"，字数增加但通知次数大幅减少
无障碍与通知文本
通知组件的无障碍性对屏幕阅读器用户尤为重要。视觉通知只在屏幕的一部分短暂显示，而屏幕阅读器通过 aria-live 属性以语音朗读。
Toast 消息设置 role="status" 和 aria-live="polite"，在不中断用户当前操作的情况下通知。错误通知设置 role="alert"，立即朗读。
请记住通知文本的字数直接影响屏幕阅读器的朗读时间。麻烦的地方在于，这个朗读时间无法从开发侧估算出来。朗读速度是用户自己的设置，差异很大，熟练的屏幕阅读器用户往往把语音调得比默认快出许多。再加上 aria-live="polite" 会等待正在进行的朗读结束，因此连朗读开始的时刻也会前后浮动。"多少字能在显示时间内读完"这种形式的计算站不住脚，因为它的前提无法固定下来。另有一个陷阱是，在通知消失的同一瞬间把被朗读的元素从 DOM 中移除，朗读会中途被切断。正因如此，更好的做法是为屏幕阅读器用户提供延长 Toast 显示时间的选项，或提供可事后查看的通知历史。
实现清单
将通知文本字数设计落实到实现中的清单：
- 将最大字数定义为常量：为每个组件定义最大字数常量，超出时用省略号 (...) 截断
- 考虑多语言支持：翻译带来的膨胀，原文越短反而越大。W3C 国际化解说文章引用的粗略目安是，10 个英文字符以下的字符串翻译后约为 200-300%，而超过 70 个字符的长文则收敛在 130% 左右。通知文本正处在这个范围里最容易膨胀的一端，因此要确认在最长语言中布局不会崩溃
- 将显示时间与字数联动：字数多的 Toast 自动延长显示时间。参考：20 字以下 = 3 秒，21-40 字 = 5 秒，41 字以上 = 7 秒
- 准备测试用例：确认最短消息 (3 字)、标准消息 (20 字)、最长消息 (上限字数)、超出上限消息的显示
- 与动画保持一致：统一淡入/淡出动画时间 (通常 300ms) 是否包含在显示时间内
各平台的通知文本约束
iOS 和 Android 的应用内通知组件规格不同。跨平台开发需要考虑两个 OS 约束的字数设计。
| 元素 | iOS (UIKit / SwiftUI) | Android | Web (CSS) |
|---|---|---|---|
| Toast | 无标准 API (自定义实现) | Snackbar (文本 + 操作按钮) | 自由设计 |
| Banner | 无标准 API (自定义实现) | 无标准 API (自定义实现) | 自由设计 |
| Alert | UIAlertController (标题 + 消息 + 按钮) | AlertDialog (标题 + 消息 + 最多 3 个按钮) | 自由设计 |
| Action Sheet | UIAlertController (.actionSheet) | BottomSheet | 自由设计 |
iOS 没有与 Android Snackbar 对应的标准组件，Toast 通知需要自定义实现。字数上限可以自己设定，代价是显示时间、位置和动画也都得自己决定。容易被忽略的，是文本变长时会跟着动的那些东西：高度增加后压到标签栏或主屏幕指示条上；通知滑出安全区域，圆角把字符遮住。这两类破面，都不是只靠设定一个字数上限就能防住的。许多团队最后落在日语 20-35 字这样的数字上，原因之一就是要停在高度从一行变成两行的那个边界的这一侧。
Android 的 Snackbar 因为有标准组件，可以用更具体的方式来考虑上限。文本变长时会逐行增加，放不下的部分被截断，所以上限不是由字数、而是由"愿意允许到几行"来划定的。日语每行约 20-25 字 (在 360dp 屏幕宽度和默认文字大小下的粗略数值)，因此两行大约 50 字是一条现实的线。用户一旦调大文字大小，这个字数会立刻缩水。除此之外，操作按钮标签与正文共享同一行的宽度，仅仅放上"元に戻す"这样 4-6 字的标签，正文可用的宽度就会明显变窄。把最大文字大小、打算支持的最窄设备宽度、最长的操作标签这三个条件放在一起确认，布局才不会在后面崩掉。
通知文本的本地化策略
多语言应用需要应对翻译通知文本时字数变化的问题。棘手的是，恰恰像通知文本这样的短字符串，膨胀得最厉害。长篇的说明性文字增幅停在 30% 左右，而只有几个词的字符串却可能翻上一倍以上。也就是说，翻译预算最紧的地方，正好落在上限本来就最严格的 Toast 和操作按钮上。另一件容易被漏掉的事是，字数和显示宽度是两把不同的尺子。一个中文或日文字符大致占两个拉丁字符的宽度，因此字数少并不保证一行放得下。只管字数上限，这两处缺口就都暴露在外。
- 以最长语言为基准设计布局：膨胀率并不只由语言决定，它很大程度上取决于字符串的长度。按长文所说的 1.3 倍左右余量去搭布局，按钮标签这类短字符串会先崩。短字符串则要预留两倍以上的余量
- 允许文本换行：设计根据文本量变化高度的组件，而非固定宽度的 Toast
- 向翻译人员传达字数限制：在 i18n 文件中以注释标注最大字数，让翻译人员意识到限制
- 使用伪本地化 (Pseudo-localization) 测试：在开发阶段应用把字符串拉长的伪翻译，验证布局的耐受性。拉伸率不要一律相同，越短的字符串就拉得越狠 (两倍以上)，这样才更接近真实的翻译结果
在 React Native 或 Flutter 等跨平台框架中，为 i18n 库的字符串附加最大字数元数据并在翻译时自动检查是有效的做法。正如 Slack 消息字数设计中所述，商务工具的通知文本需要兼顾简洁性和准确性。