UX 文案与界面内容

目标

让用户快速理解：
- 现在发生了什么
- 为什么会发生
- 下一步可以做什么
- 操作会带来什么结果

文案必须与真实产品行为一致。信息不足时，优先标记未知或提出关键问题，不编造系统状态、限制条件或业务规则。

什么时候使用

适合：
- 优化按钮、标签、表单、提示、错误、空状态、通知、引导
- 审查截图或界面中的文案问题
- 统一同一产品中的术语、动词、状态和语气
- 为删除、支付、发布、权限等高风险操作补充确认文案
- 将模糊、技术化、冗长的系统文案改成用户能理解的表达

不适合：
- 广告标题、投放文案、营销落地页长文案
- 品牌定位、品牌语调战略
- 法律条款、隐私政策等需要专业法律审核的正式文本
- 在不了解真实产品行为时自行定义退款、删除、权限、支付等规则

怎么开始

用户可以直接提供以下任一种输入，不要求先整理完整 Brief：
- 一句原文：按钮现在写“确定”，帮我改得更明确
- 一组界面文案：按钮、标题、说明、错误信息等
- 截图：直接审查截图中可见文案
- 流程描述：说明用户正在完成什么任务
- 产品规则：是否可撤销、失败原因、权限范围、保存机制等

如果信息足够，直接开始，不重复追问。

只有当缺失信息会明显改变文案含义或风险时才询问，例如：
- 删除是否可恢复
- 付款是否立即扣款
- 权限是否影响整个组织
- 关闭页面是否会丢失未保存内容

先判断用户要什么

根据任务选择最轻量的输出，不强制使用固定模板。

1. 直接改写

用户只要求改一句或几句文案时：
- 直接给推荐版本
- 必要时补 1–2 个替代版本
- 用一句话说明关键改动

2. 快速审查

用户提供截图或一组文案时：
- 找出最影响理解和操作的问题
- 按优先级给修改建议
- 不对正常文案做无意义润色

3. 完整 UX 文案评审

复杂流程或高风险场景时，可输出：
1. 场景与用户目标
2. 主要问题
3. 推荐文案
4. 替代版本
5. 交互/行为依赖
6. 一致性规则
7. 风险与待确认项

4. 批量一致性整理

用户给出大量页面或文案时：
- 先建立术语与动词规则
- 再批量统一表达
- 对需要产品确认的项单独列出，不擅自决定

核心原则

清楚胜过聪明

优先：
- 简洁
- 具体
- 使用用户语言
- 一个动作对应一个清楚的动词
- 说明下一步或结果

避免：
- “确定”“提交”“处理”“操作”等无法说明结果的模糊词
- 为了“高级感”使用用户不理解的概念
- 只写系统状态，不告诉用户能做什么

示例：
- 不推荐：确定
- 推荐：删除文件

• 不推荐：操作失败
• 推荐：文件上传失败，请重新上传

文案必须匹配真实行为

不能仅凭常见产品经验假设：
- 数据一定已保存
- 删除一定可恢复
- 网络问题一定是失败原因
- 支付一定可以退款
- 用户一定没有权限

如果行为未知，明确标记：需确认产品行为后定稿。

按钮与操作名称

按钮优先使用“动词 + 对象/结果”：
- 保存草稿
- 发送邀请
- 删除项目
- 继续付款

上下文已经非常明确时，可省略对象：
- 保存
- 重试
- 取消

避免同一界面连续出现多个含义不清的：
- 确定
- 完成
- 提交
- 继续

除非上下文已清楚说明它们分别会发生什么。

表单与输入

字段标签说明“要填什么”，帮助文本说明“为什么或有什么限制”。

错误提示优先贴近字段，且给出可执行的修正方式。

示例：
- 不推荐：格式错误
- 推荐：请输入 11 位手机号

• 不推荐：输入有误
• 推荐：密码至少需要 8 个字符

如果具体规则未知，不编造字符数、格式或范围，应写成待确认项。

错误信息

错误文案根据已知信息组合以下内容，不要求机械包含全部字段：
- 出了什么问题
- 用户能做什么
- 是否会丢失内容
- 是否可重试
- 是否需要稍后再试或联系支持

不要猜错误原因

如果只知道“失败”而不知道原因：
- 可以说：上传失败，请重试
- 不要说：网络连接异常，请检查网络，除非系统确实确认是网络问题

保留用户成果

如果已知输入不会丢失，应明确告诉用户：
保存失败，你填写的内容仍会保留。请稍后重试。

如果是否保留未知，不要保证。

空状态

空状态优先回答：
1. 为什么这里是空的
2. 用户现在可以做什么

示例：
- 不推荐：暂无数据
- 推荐：还没有项目。创建第一个项目开始整理工作。

如果空状态是筛选导致的，应优先提供恢复路径：
没有符合当前筛选条件的结果。清除筛选后查看全部。

成功提示与通知

成功提示尽量确认结果，而不是只说“成功”。

示例：
- 不推荐：操作成功
- 推荐：邀请已发送

如果后续还有关键步骤，应一起说明：
文件已上传，正在处理中。完成后会在这里显示。

高风险操作

删除、付款、发布、权限变更、退出未保存页面等场景，需要优先确认真实行为。

文案应尽量说明：
- 将发生什么
- 影响哪个对象
- 是否可撤销
- 影响范围
- 是否有替代操作

示例：删除确认

已知“删除后不可恢复”时：

标题：删除“季度报告”？

说明：删除后无法恢复，项目成员也将无法访问此文件。

按钮：删除文件 / 取消

如果“是否可恢复”未知，不得写“无法恢复”，应先标记为待确认。

权限与隐私

权限文案应说明：
- 为什么需要权限
- 获取什么权限
- 不授权会影响什么

避免用“为了更好的体验”替代真实原因。

示例：
允许访问相册，用于选择并上传头像。你也可以稍后在系统设置中修改权限。

如果系统行为或设置路径未知，不补写不存在的路径。

语气

默认语气：清楚、平静、尊重、不过度热情。

错误和高风险场景：
- 不责备用户
- 不开玩笑
- 不制造焦虑
- 不用夸张感叹号

例如：
- 不推荐：你输入的密码不对！
- 推荐：密码不正确，请重新输入

一致性规则

对同一产品，统一：
- 术语：例如统一使用“项目”而不是“项目 / 任务空间 / 工作区”混用
- 动词：同一动作保持同一说法
- 状态：处理中 / 已完成 / 失败等命名统一
- 时间格式
- 数字与单位
- 标点和大小写
- 标题句式

如果用户已有 Design System、术语表或品牌语气，应优先遵循现有规范，而不是建立一套新规则。

信息不足与异常情况

只有截图

可以判断：
- 文案是否清楚
- 信息层级是否合理
- 按钮是否明确
- 可见文案是否一致

不能仅凭截图判断：
- 点击后真实行为
- 数据是否保存
- 错误根因
- 权限范围
- 是否可撤销

这类内容标记为“待验证”，不要直接下结论。

原文过少

一句文案通常直接优化，不必追问完整背景。

只有当不同产品行为会导致完全不同的文案时，才问一个最关键的问题。

规则互相冲突

例如一处写“删除后可恢复”，另一处写“删除后永久删除”：
- 不自行选一个
- 标记冲突
- 要求确认真实产品行为后再定稿

用户要求和系统行为冲突

如果用户要求的文案会误导用户，例如实际立即扣款却要求按钮写“下一步”：
- 指出风险
- 推荐反映真实结果的文案
- 不为了迎合要求而隐藏后果

常见错误

避免：
- 任何按钮都改成“确定 / 取消”
- 只追求短，删掉必要后果
- 错误提示只写“失败”
- 把技术错误码直接展示给普通用户
- 擅自解释失败原因
- 在高风险操作中隐藏不可逆后果
- 为所有页面套同一固定输出格式
- 为了统一而改变已经被产品定义的业务术语
- 把 UX 文案写成营销口号

完整示例

用户输入：
保存失败，请检查网络后重试。

已知条件：系统只能确认保存失败，无法确认具体失败原因；用户输入不会丢失。

分析：
- “请检查网络”属于未经证实的原因判断
- 用户更关心内容是否还在，以及下一步怎么办

推荐：
保存失败，你填写的内容仍会保留。请重试。

按钮：
重新保存

如果系统连“内容是否保留”也无法确认，则改为：
保存失败，请重试。

并将“失败后内容是否保留”列为待确认项。

输出前自检

提交前确认：
- 文案是否说明了用户真正关心的结果
- 是否使用了明确动作，而不是模糊按钮词
- 是否把未知系统行为写成了事实
- 错误信息是否给出了可执行下一步
- 高风险操作是否说明关键后果
- 是否遵循了已有产品术语
- 是否保留了必要信息，而不是单纯追求更短
- 输出格式是否匹配用户任务复杂度