ux-writing

UX 文案

为数字产品和体验编写清晰、简洁、以用户为中心的界面文案（UX 文本／微文案）。本技能提供框架、模式和最佳实践，帮助创建能助用户实现目标的文本。

何时使用此技能

在以下情况下使用此技能：

• 编写界面文案（按钮、标签、标题、消息、表单）
• 编辑现有 UX 文本，使其更清晰、更有效
• 创建错误消息、通知或成功消息
• 设计对话流程或新手引导体验
• 为产品确立语气与风格
• 审查产品内容的一致性和易用性

UX 文案核心原则

四项质量标准

每一段 UX 文本都应做到：

1. 有目的 — 帮助用户或业务实现目标
2. 简洁 — 在不丢失含义的前提下尽可能少用字词
3. 自然对话 — 听起来自然、人性化，而非机械生硬
4. 清晰 — 含义明确、准确且易于理解

关键最佳实践

简洁

• 每行最多使用 40-60 个字符
• 每个字词都必须发挥作用
• 将密集文本拆分成便于浏览的小段
• 将重要信息前置
• 删除冗余表达（“为了” → “以便”，“由于……这一事实” → “因为”，“在这个时间点” → “现在”）
• 将短语动词替换为直接动词（“找出” → “发现”，“设置” → “配置”，“开展” → “执行”）
• 避免堆叠修饰语——通常一个形容词就足够

清晰

• 使用浅白语言（面向大众时达到七年级阅读水平，面向专业人士时达到十年级阅读水平）
• 避免行话、习语和技术术语
• 始终使用一致的术语
• 选择有意义、具体的动词
• 避免歧视性或排斥性语言（默认使用带性别倾向的表达、歧视残障人士的习语、具有特定文化背景的隐喻）

对话式语气

• 按照平时说话的方式写作
• 85% 的情况下使用主动语态
• 使用介词和冠词
• 避免机械生硬的措辞

以用户为中心

• 关注用户获益，而非功能特性
• 预判并回答用户的问题
• 使用第二人称（“你”）表述
• 符合用户的语言习惯和思维模式

UX 文本模式

将这些常见模式应用于界面元素。

标题

• 目的：让用户了解自己当前所在的位置
• 格式：名词短语。页面标题、模态框／对话框标题以及菜单／导航项使用标题式大小写（标题式大小写的具体规则请参见下文的大小写部分）。较低级别的标题（H3+）、图注、说明框和表格标题使用句首字母大写格式。
• 类型：品牌标题、内容标题、类别标题、任务标题
• 示例：
  • 页面标题（标题式大小写）：“账户设置”、“你的资料库”、“运行薪资”
  • 较低级别的标题（句首字母大写格式）：“近期活动”、“银行账户详情”、“税款预扣”

按钮和链接

• 目的：帮助用户执行操作
• 格式：主动祈使动词，句首字母大写格式
• 模式：[动词] [对象]
• 示例：“保存更改”、“删除账户”、“查看详情”
• 避免：使用“确定”、“提交”、“点击这里”等通用标签

错误消息

• 目的：说明问题并提供解决方案
• 格式：富有同理心、清晰、可执行
• 模式：[发生的问题]。[原因/背景]。[处理方法]。

错误消息类型

验证错误（行内）

• 在用户填写完字段或离开字段时显示
• 提供简短、具体的输入修正指引
• 模式：[字段] [具体要求]
• 示例：
  • “电子邮件必须包含 @”
  • “密码至少需要 8 个字符”
  • “请选择未来的日期”
• 显示时机：实时显示或离开字段时
• 显示位置：字段下方或旁边

系统错误（模态框/横幅）

• 后端操作失败时显示
• 说明发生了什么以及原因
• 模式：[操作失败]。[可能的原因]。[恢复步骤]。
• 示例：
  • “付款失败。您的银行卡被拒。请尝试其他付款方式。”
  • “无法保存更改。连接已断开。请重新连接后重试。”
  • “上传失败。文件过大。请选择小于 10MB 的文件。”
• 显示时机：失败后立即显示
• 显示位置：模态对话框或醒目的横幅

阻断错误（全屏）

• 在问题解决前阻止用户继续使用
• 清楚说明阻断原因和解决方法
• 模式：[被阻止的事项]。[原因]。[需要采取的具体操作]。
• 示例：
  • “需要更新。此版本已不再受支持。请立即更新以继续。”
  • “订阅已过期。您的账户已暂停。请续订以恢复访问权限。”
  • “需要验证。请确认您的电子邮件以使用各项功能。请检查收件箱。”
• 显示时机：应用启动时或访问功能时
• 显示位置：全屏或大型模态框

权限错误

• 请求权限前先说明用户可获得的好处
• 模式：[用户获益]。[所需权限]。
• 示例：
  • “及时获知订单发货情况。请启用通知。”
  • “查找附近的商店。请允许访问位置信息。”
  • “备份您的照片。请授予存储权限。”
• 显示时机：首次使用功能时
• 显示位置：功能相关界面中

应避免的内容

• 不作解释的技术代码（“错误 403”）
• 责怪用户的措辞（“输入无效”“非法字符”）
• 机械生硬的语气（“发生错误”）
• 没有后续处理方法的错误提示
• 含糊的原因（“出了点问题”）

成功消息

• 目的：确认操作已完成
• 格式：使用过去时，内容具体且积极
• 模式：[操作] [结果/益处]
• 示例：“更改已保存”“电子邮件已发送”“个人资料已更新”

空状态

• 目的：在没有内容时引导用户
• 类型：首次使用、用户清空内容、错误/无结果
• 格式：说明 + 引导用户添加内容的 CTA
• 示例：“还没有消息。开始对话，与团队保持联系。”

表单字段

• 标签：使用描述输入内容的清晰名词短语（“电子邮件地址”“电话号码”）
• 说明：以动词开头，解释为什么需要这些信息
• 占位符：谨慎使用，仅用于“[email protected]”等常见输入
• 辅助文本：根据重要程度采用静态显示、按需显示或自动显示

通知

• 目的：及时传达有价值的信息
• 类型：需要采取操作（打扰性较强）、被动通知（打扰性较低）
• 格式：以动词开头的标题 + 上下文描述
• 示例：“需要更新。请安装最新版本以继续。”

格式与风格约定

大小写

• 句首字母大写（默认）：正文、描述、辅助文本、错误消息、成功消息、工具提示、占位文本、按钮标签、较低级别的标题（H3 及以上）、图注、提示框、表格标题
• 标题式大小写：页面标题、模态框／对话框标题、菜单和导航项、表单字段标签
• 全大写：仅用于位于标题或指标上方的简短眉题／引题标签（不超过 3 个词）——例如统计卡片的分区标题，如 EMPLOYEES、TOTAL PAY、LAST UPDATED，以及 KPI 数值上方的类别标签——以及用于首字母缩略词（PDF、URL、API、EIN、SSN）。简短类别眉题采用全大写是一种有意的排版信号，并非大喊大叫。不要将正文、按钮标签、错误消息、页面标题、标签页／菜单标签，或任何超过约 3 个词的字符串设为全大写——超过这个长度后，可读性会急剧下降，读起来像是在大喊。

标题式大小写规则（适用于所有使用标题式大小写的地方）：

• 无论词性如何，标题中的第一个词和最后一个词都大写首字母。
• 所有形容词、副词和名词都大写首字母。
• 所有代词（包括“it”）都大写首字母。
• 所有动词都大写首字母，包括各种形式的动词“to be”（is、are、was、has been 等）。
• “no”“not”和感叹词“O”都大写首字母。
• 不要将冠词（“a”“an”“the”）大写首字母，除非它们位于标题开头或结尾。
• 不要将并列连词（“and”“or”“nor”“but”“for”“yet”“so”）大写首字母，除非它们位于标题开头或结尾。
• 不要将“to”（无论是否用于不定式）大写首字母，除非它位于标题开头或结尾。
• 不要将介词（例如“in”“on”“at”“by”“of”“with”）大写首字母，除非它们位于标题开头或结尾。

示例：

• “Run Payroll for the Pay Period”
• “Add a New Employee”
• “How to File Quarterly Taxes”

特殊情况：

• “Coming soon” 是所有位置（徽章、提示框、文案）中统一使用的未来功能标签。即使在标题式大小写的上下文中，也要使用句首字母大写形式。面向用户的字符串中不要透露具体里程碑阶段（“Coming at Beta”“Coming at GA”）。
• 下拉菜单中的操作项（按钮触发菜单中的祈使动词项，例如 "Add employee"、"See payroll runs"、"Export report"）视作按钮 → 句首字母大写，而不是静态导航菜单项。“菜单项使用标题式大小写”的规则适用于导航菜单（侧边导航、面包屑、指向页面的顶级导航链接），不适用于操作菜单。
• 引用命名页面的按钮（例如 "Go to Setup Wizard"、"Back to Payroll Hub"、"Open Time Review"）应保留页面名称的标题式大小写，按钮周围的文案则使用句首字母大写形式。在此上下文中，页面名称是专有名词。

数字和日期

• 使用数字，不要拼写数字（用“12”，而不是“twelve”）——这样更省空间，也更便于快速浏览。
• 日期中的月份要拼写完整：“August 5, 2025”或“5 August 2025”——不要使用“8/5/2025”或“8.5.2025”（不同地区的理解不一致）。
• 星期和月份要拼写完整；仅在空间受限时（例如表格、移动端）使用缩写：“Sat., Jan. 24”。
• 避免在日期中使用序数后缀：写“August 5”，而不是“August 5th”；写“May 1”，而不是“May 1st”。
• 年份范围使用连字符，并在两端写出完整年份：“2015-2016”，不要写“2015-16”或“2015 to 2016”。

时态

• 状态消息优先使用过去时，而非现在完成时：“File uploaded”，不要写“File has been uploaded”。
• 在大多数 UI 场景中，现在完成时会增加字数，却不会增加含义。

缩写

• 仅使用用户能立即理解的缩写（常见的有：PDF、URL、ID）。
• 如果不确定，首次出现时写出全称，之后再使用缩写：“application programming interface (API)”。
• 拉丁文缩写（例如 i.e.、etc.）——使用正确的标点：每个字母后加句点，在句子中前后加逗号。
• 不确定时，写出全称。

语气与风格

声音（统一的品牌个性）

声音是产品始终如一的个性。通过以下内容确立声音：

• 概念：3-5 个关键品牌原则／价值观
• 声音特征：描述每个概念的形容词
• 该做／不该做的示例：展示声音如何体现的具体示例

请参阅 references/voice-chart-template.md，了解如何创建声音图表。

语气（随情境调整）

语气是声音如何适应具体情境。声音始终保持一致，而语气会根据用户的情境和情绪状态调整。

语气变量

• 目的：用户为什么会看到这段文本（获取信息、执行操作、确认）
• 情境：用户想要做什么（学习、完成任务、从错误中恢复）
• 情绪状态：用户可能的感受（沮丧、兴奋、困惑、谨慎）
• 风险程度：操作的影响（低：更改主题；高：删除账户）

根据用户情绪状态调整语气

沮丧（错误、失败、阻碍）

• 富有同理心，注重解决问题
• 承认问题，但不责怪用户
• 提供清晰的恢复路径
• 示例：“付款失败。您的银行卡被拒付了。请尝试其他付款方式。”

困惑（首次使用、复杂功能）

• 耐心解释
• 清晰地分解步骤
• 提供背景信息和指导
• 示例：“连接您的银行账户，即可查看消费分析。我们会引导您完成操作。”

自信（日常任务、再次访问）

• 高效直接
• 尽量少做解释
• 快速确认
• 示例：“已保存”

谨慎（高风险操作、数据丢失）

• 严肃、坦诚
• 清楚说明后果
• 尊重用户的决定
• 示例：“删除账户？您将丢失所有数据，而且此操作无法撤销。”

成功（完成任务、取得成就）

• 积极鼓励
• 表达程度与成就相称
• 简短庆祝
• 示例：“个人资料已更新。您的更改已生效。”

根据内容类型调整语气

错误消息：富有同理心、让人安心、注重解决问题

• 绝不责怪用户
• 说明发生了什么
• 提供清晰的下一步

成功消息：积极、具体、鼓励

• 确认发生了什么
• 表达程度与操作的重要性相称
• 简短清晰

说明：清晰、直接、有帮助

• 先说明关键操作
• 必要时解释原因
• 使用简单步骤

引导流程：热情、鼓励、简洁

• 表示欢迎，但不过度提供信息
• 聚焦价值
• 庆祝早期成果

确认信息：严肃、坦诚、尊重

• 清楚说明后果
• 不操纵用户
• 方便用户取消操作

空状态：充满希望、提供操作指引

• 说明内容为空的原因
• 提供清晰的下一步操作
• 保持鼓励的语气

编辑流程

分四个阶段编辑 UX 文本：

阶段 1：明确目的

• 文本是否有助于用户达成目标？
• 文本是否服务于业务目标？
• 用户能否清楚了解其价值？
• 是否预见并解决了用户的顾虑？

阶段 2：简洁

• 删除不必要的词语
• 合并重复信息
• 确保每个词都有存在的价值
• 重要概念前置

阶段 3：对话化

• 大声读出来——你会这样说吗？
• 使用主动语态（除非被动语态更清晰）
• 加入自然的衔接词
• 避免企业套话

阶段 4：清晰

• 使用具体、准确的动词
• 保持术语一致
• 测试可读性（Hemingway Editor、Flesch-Kincaid）
• 确保含义明确无歧义

工作流

1. 了解情境

   • 用户目标和需求
   • 业务目标
   • 技术限制
   • 用户的情绪状态

2. 起草内容

   • 从对话入手（你会怎么说？）
   • 应用合适的模式
   • 考虑声音和语气
   • 重要信息前置

3. 反复编辑

   • 阶段 1：明确目的
   • 阶段 2：简洁
   • 阶段 3：对话化
   • 阶段 4：清晰

4. 测试和衡量

   • 与团队一起审阅
   • 尽可能邀请用户测试
   • 衡量任务完成情况和理解程度
   • 根据反馈迭代

UX 写作中的无障碍设计

撰写无障碍内容，能确保所有用户（包括使用辅助技术的用户）都能理解并与产品互动。

无障碍设计的核心原则

优化屏幕阅读器体验

• 明确标注所有交互元素（使用“提交表单”，而不只是“提交”）
• 编写描述性链接文本（使用“阅读定价详情”，而不是“点击此处”）
• 设计错误消息时，确保屏幕阅读器能将错误信息与字段标签一起读出
• 仅当视觉上下文不足以表达含义时，才使用 ARIA 标签

认知无障碍

• 每句话以 8–14 个词为目标（8 个词 = 100% 理解率，14 个词 = 90%）
• 将复杂信息拆分为便于浏览的小块
• 使用清晰的标题和合理的层级结构
• 提供一致且可预测的模式

多模态沟通

• 不要仅依靠颜色传达含义
• 将视觉指示与文本搭配使用（例如，红色图标配上“错误：需要填写电子邮件”）
• 为图标和图像提供文本替代内容
• 确保颜色对比度充足（WCAG AA 最低标准：4.5:1）

人人都能看懂的浅显语言

• 面向一般受众时，以美国 7–8 年级阅读水平为目标
• 首次使用技术术语时，先加以定义
• 避免使用习语、隐喻和文化典故
• 使用常见的日常用语

无障碍模式示例

按钮

• ❌ 不佳：“提交”（屏幕阅读器缺少上下文）
• ✅ 良好：“提交申请”

链接

• ❌ 不佳：“点击此处了解更多信息”
• ✅ 良好：“阅读我们的隐私政策”

错误消息

• ❌ 不佳：红色文本显示“无效”
• ✅ 良好：“错误：电子邮件必须包含 @”（配有错误图标）

表单标签

• ❌ 不佳：仅使用占位符的字段
• ✅ 良好：可见标签 + 可选占位符

UX 文案基准

使用这些基于研究的指标，撰写有效的 UX 文案。

句子长度目标

按内容类型划分

• 按钮/CTA：理想长度为 2–4 个词，最多 6 个词
• 标题：3–6 个词，最多 40 个字符
• 错误消息：12–18 个词（包括解决方案）
• 说明：最多 20 个词，理想长度为 14 个词
• 正文：平均每句 15–20 个词
• 通知：标题 + 正文共 10–15 个词

理解率

• 不超过 8 个词：用户理解率为 100%
• 不超过 14 个词：用户理解率为 90%
• 25 个词：理解率大幅下降前的上限

字符数和行长

最佳范围

• 行长：40–60 个字符，可实现最佳可读性
• 按钮标签：15–25 个字符
• 页面标题：30–50 个字符
• 通知标题：35–45 个字符

阅读水平指南

按受众划分

• 普通公众：美国 7–8 年级（Flesch-Kincaid）
• 专业工具：美国 9–10 年级
• 技术产品：美国 10–11 年级
• 专业领域：美国 11–12 年级（仅在必要时）

测试工具

• Hemingway Editor：突出显示复杂句子
• Readable.com：提供多种可读性评分
• Microsoft Word：内置 Flesch-Kincaid 评分

应避免的常见错误

• 过度使用被动语态
• 使用笼统的按钮标签（“提交”“确定”）
• 在错误消息中责怪用户
• 在严肃情境中过度卖弄幽默
• 术语使用不一致
• 隐藏说明或解释
• 使用面向系统而非面向用户的语言
• 用词过多（不够简洁）
• 语气机械、生硬，或过于官腔
• 仅依靠颜色表达含义
• 编写无障碍性差的链接文本（“点击此处”）

快速参考

句首字母大写：“Save your changes”（而非“Save Your Changes”）
按钮使用主动祈使句：“Delete account”（而非“Account deletion”）
以用户为中心：“Save time with shortcuts”（而非“We offer shortcuts”）
动词具体明确：永久删除时使用“Delete”（而非“Remove”）
关键信息前置：“Password must be 8 characters”（而非“Must be 8 characters for your password”）

风格参考

本技能所依据的外部参考资料（本技能未涵盖的情况可查阅这些资料）：

• 《芝加哥格式手册》——语法、标点和引用问题的备选参考。
• 《韦氏词典》——拼写和用词问题的备选参考。

资源

本技能包含：

• references/accessibility-guidelines.md：面向所有用户撰写无障碍 UX 文本的综合指南
• references/voice-chart-template.md：用于创建产品语调图表的模板
• references/content-usability-checklist.md：用于评估 UX 文本质量的综合检查清单
• references/patterns-detailed.md：不同语调下 UX 文本模式的扩展示例
• examples/real-world-improvements.md：改进前后的对照示例，附有详细分析和评分
• templates/error-message-template.md：用于撰写有效错误消息的可填写模板
• templates/empty-state-template.md：创建实用空状态的指南
• templates/onboarding-flow-template.md：用于设计清晰入门体验的框架