通知文本的 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 字是实用上限。人类每秒可阅读约 10-15 个日语字符，5 秒的 Toast 最多可读约 75 字。但考虑到用户注意到 Toast 后开始阅读的延迟 (约 1-2 秒)，实际可读字数限制在 30-45 字。
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"改为"服务器错误" |
Material Design 3 指南规定 Snackbar 文本为"1-2 行"。按每行约 40 字 (英语) 计算，日语约为 30-60 字。Apple 的 Human Interface Guidelines 规定 Alert 消息为"1-2 句"，相当于日语约 30-80 字。
通知频率与字数的平衡
通知字数设计不仅要考虑单条通知，还需要考虑一定时间内显示的通知总量。即使每条通知字数适当，短时间内大量显示也会导致用户"通知疲劳"。
- 批量处理：短时间内发生多条同类通知时，合并为"已上传 3 个文件"而非逐条显示。字数增加但减少通知次数可提升整体 UX
- 优先级过滤：低优先级通知仅记录在通知中心，不显示 Toast 或 Banner。用户主动查看时才可浏览
- 冷却期：同类通知至少间隔 30 秒。连续通知用后一条覆盖前一条
- 聚合通知："田中和其他 4 人发表了评论"将多个事件合并为一条通知。相比逐条显示"田中发表了评论""佐藤发表了评论"，字数增加但通知次数大幅减少
无障碍与通知文本
通知组件的无障碍性对屏幕阅读器用户尤为重要。视觉通知只在屏幕的一部分短暂显示，而屏幕阅读器通过 aria-live 属性以语音朗读。
Toast 消息设置 role="status" 和 aria-live="polite"，在不中断用户当前操作的情况下通知。错误通知设置 role="alert"，立即朗读。
请记住通知文本的字数直接影响屏幕阅读器的朗读时间。40 字的 Toast 消息在标准速度下约需 8 秒，3 倍速也需约 3 秒。需要调整字数以确保朗读在 Toast 显示时间 (3-5 秒) 内完成。理想情况下，为屏幕阅读器用户提供延长 Toast 显示时间的选项，或提供可事后查看的通知历史。
通知 UX 设计相关的 UX 写作书籍可在 Amazon 上找到。系统学习微文案技术可以显著提升通知文本质量。
实现清单
将通知文本字数设计落实到实现中的清单：
- 将最大字数定义为常量：为每个组件定义最大字数常量，超出时用省略号 (...) 截断
- 考虑多语言支持：日语 30 字的消息在英语中可能变为 50-60 字，德语中可能超过 70 字。确认在最长语言中布局不会崩溃
- 将显示时间与字数联动：字数多的 Toast 自动延长显示时间。参考：20 字以下 = 3 秒，21-40 字 = 5 秒，41 字以上 = 7 秒
- 准备测试用例：确认最短消息 (3 字)、标准消息 (20 字)、最长消息 (上限字数)、超出上限消息的显示
- 与动画保持一致：统一淡入/淡出动画时间 (通常 300ms) 是否包含在显示时间内
各平台的通知文本约束
iOS 和 Android 的应用内通知组件规格不同。跨平台开发需要考虑两个 OS 约束的字数设计。
| 元素 | iOS (UIKit / SwiftUI) | Android (Material Design 3) | Web (CSS) |
|---|---|---|---|
| Toast | 无标准 API (自定义实现) | Snackbar (1-2 行，1 个操作) | 自由设计 |
| Banner | UIBannerView (私有 API) | Banner 组件 (2 行 + 2 个操作) | 自由设计 |
| Alert | UIAlertController (标题 + 消息 + 按钮) | AlertDialog (标题 + 消息 + 最多 3 个按钮) | 自由设计 |
| Action Sheet | UIAlertController (.actionSheet) | BottomSheet | 自由设计 |
iOS 没有与 Android Snackbar 对应的标准组件，Toast 通知需要自定义实现。Apple 的 Human Interface Guidelines 推荐在屏幕底部使用低调的显示作为临时反馈，要求文本控制在"一眼可读的量"。虽然没有具体字数规定，但实际上日语 20-35 字较为合适。
Material Design 3 规定 Snackbar 文本为"理想 1 行，最多 2 行"。日语每行约 20-25 字 (基于 360dp 屏幕宽度)，实用上限约为 50 字。操作按钮标签英语推荐 1 个单词 (如"UNDO")，日语控制在 4-6 字 (如"元に戻す")。
通知文本的本地化策略
多语言应用需要应对翻译通知文本时字数变化的问题。日语 20 字的 Toast 消息在德语中膨胀到 45 字并不罕见。
- 以最长语言为基准设计布局：德语和芬兰语相比英语有 1.3-1.5 倍膨胀的趋势。确认在这些语言中布局不会崩溃
- 允许文本换行：设计根据文本量变化高度的组件，而非固定宽度的 Toast
- 向翻译人员传达字数限制：在 i18n 文件中以注释标注最大字数，让翻译人员意识到限制
- 使用伪本地化 (Pseudo-localization) 测试：在开发阶段应用将字符串拉伸 1.5 倍的伪翻译，验证布局的耐受性
在 React Native 或 Flutter 等跨平台框架中，为 i18n 库的字符串附加最大字数元数据并在翻译时自动检查是有效的做法。正如 Slack 消息字数设计中所述，商务工具的通知文本需要兼顾简洁性和准确性。