UX 写作（UX Writing），也常常被称为体验文案编写，指的是设计师产出体验文案的过程。而体验文案是指存在于界面中来帮助用户完成任务的各类文本，包括操作指引、说明、导航按钮、确认消息、错误反馈等。
1. 文案应当清晰准确
Material design：文案应当清晰明了、准确易懂。
清晰准确是指传达的语义能让用户快速了解到当前最为重要的信息或状态，不存在歧义或误导。如下图所示，当用户已发表的游记数量为 0 时，可能存在两种情况：
因此，「暂无已发表的游记哦」才是对当前状态准确的表达。
2. 避免使用专业术语或简称
Material design：避免使用术语或技术专用词，除非这些词语对理解上下文不可或缺。
在面向 C 端用户的产品中，除了避免使用专业术语外，某些情况下还需避免使用简称，案例如下。
值得一提的是，这里需分 B 端和 C 端进行考虑。对于较为专业的 B 端用户，有些专业术语或简称已经在行业内形成了习惯，B 端用户基本都能理解，就没有必要转化为更通俗易懂的词语或使用全称了。案例如下：
3. 专有名词需规范
与上文中的「专业术语」不同，这里的「专有名词」指的是某一特定事物的专有表达，通常已经形成了规范或约定俗成的习惯。某些专有名词可能并不晦涩难懂，但是却容易用错。下面案例中的「4A景点」和「4A景区」就是我自己在设计过程中所犯下的错误。对专有名词的表达不确定时，除了查看竞品的表达外，也可以直接查询官方有无对此作出明确的规定。同样以「4A景区」为例，可以在旅游部官方网站中查询到国家旅游局在2012年发布的《旅游景区质量等级管理办法》，其中明确规定「旅游景区质量等级划分为5个等级，从低到高依次为1A、2A、3A、4A、5A。无论是文件名称，还是其中条例，用到的都是「景区」而非「景点」。这样一来，就能确定规范的表达应为「4A景区」了。
4. 简洁明了，效率至上
Microsoft：体验文案通常都是越短越好。文案的信息量足够让用户自信地做决策就好，删掉其他多余的词句。
Material design：使用简单、直接的语言，让文案易于被用户理解。
我自己的语言习惯是比较啰嗦的，因此在方案自查的过程中会发现很多复杂冗长的文案，以下方案的修改过程就是一个例子。
结合上述实例，我觉得简化文案可从以下角度考虑：
5. 操作按钮采用更直接的文案
Material design：避免采用无法明确指示操作结果的文案。
「确定/确认」大概是操作按钮中最为常见的文案了。按以上这条指南，如果单看「确定/确认」，是无法获知其操作结果的，必须结合弹框中的内容才能知晓。因此，在编写操作按钮文案时，不妨思考一下，有没有更直接的文案能代替「确定/确认」。案例如下图所示：
6. 保持一致
Shopify：为了帮助用户理解核心概念和操作，尽可能使用一致的名词和动词。
如下面的案例所示，除了名词和动词需尽量保持一致外，称谓同样是需要统一的，一旦选择了「你」或「您」，在同一个产品中，就应该始终保持统一，不要出现混用。另外，整体的语气同样需保持一致，如果产品的风格偏商务和正式，就不要出现过于随意和亲昵的语气，否则会让用户感觉产品和服务不够专业。
1. 文案应传达给用户友好尊重的感受
Shopify：文案切忌使用高人一等的语气。
Canada post：永远站在用户的角度考虑，并采用包容的语调。
Microsoft：避免使用带有居高临下意味的文案。
下图案例为供应商合作首页中的常见问题模块。刚拿到业务部门提供的文案时（图片中上方的文案），就觉得语气给人一种不舒服的感觉。推敲后，发现是由于「我司」、「方可上线」这两个词给用户一种我司居高临下且审核很难通过的感觉。供应商来到我们的 APP 或网站寻求合作信息，当然是本着加盟合作的期望，希望借助我们平台上线自己的产品。因此，在修改文案时，增加了「我们」一词，借此传达出诚挚和欢迎的态度，又将最后一句文案改为了「经过审核之后就可以上线」，让供应商感觉我们审核流程是简单而快捷的。修改后的文案在语气和态度上有了很大的改善。
2. 免责文案≠推卸责任
由于免责文案是对不承担责任的声明，因此，在语气和态度上，它往往给用户不友好的感觉。如下案例所示，我对入园时间的免责文案进行了修改（上方为线上文案，下方为修改后的文案）。「所有上海迪士尼乐园时间仅供参考」，免责是阐述清楚了，但是不够为用户考虑。为什么这个时间仅供参考？如果时间有变更，作为用户该如何获知呢？基于此，在参考上海迪士尼度假区官方的声明后，加上了仅供参考的原因（迪士尼可能根据运营情况调整），以及用户应该如何获知（服务处索取乐园时间表）。
对于重要信息的免责文案，在阐述清楚免责条款的基础上，可考虑加上免责原因，以及可行的解决方案。这样不仅让免责文案更加完善，也能让用户感知到友好贴心的服务态度。
2. 态度客观中立，责任划分明晰
上文中我们提到不要使用推卸责任的语气，但这并不意味着责任揽得越多越好。如下的案例是返回首页的二次确认弹框：如果用户在表单填写过程中点击返回首页，我们在技术上无法为用户保存其之前填写的信息。在这种情况下，用「无法保存」则比「不会被保存」好，因为「无法保存」更为客观地表明了原因──技术上做不到。
在某些报错提示上，同样需要注意这一点。下图中报错弹框出现的场景是：用户在浏览某权益时，该权益的库存还不为 0，但是当用户点击领取按钮时，该权益已经被领光。用「刚被领光」代替「已经被领光」，在责任的划分上更加明晰，这样不仅能让用户更准确地理解报错原因，也更能避免用户对产品的功能或服务质量产生怀疑。
如下所示，原方案中 Tab 的名称是「差评」。在开评审会时，业务部门同事提出有些合作景区不太能接受露出差评 Tab。综合各部门的意见，将「差评」改为了「不满意」。虽然「差评」这个文案更直接，也更符合用户的习惯，但是考虑到合作景区的顾虑和诉求，「不满意」可能更为恰当。
尽管「用户体验至上」、「以用户为中心」是许多公司设计部门所大力倡导的，但不可否认的是，利益相关者（如供应商、合作商家、赞助商等）的配合与否对产品的顺利运转同样起着重要的作用。因此，照顾到利益相关者的需求，也是设计师在编写文案时不可忽略的一点。
1. 在表达数值和数量时，使用数字代替文字
Canada post：指代具体数值时，使用阿拉伯数字。
那么，有没有需要用文字代替数字的情况呢？也是有的。
Canada post：当数字指代的不是具体的数值，只是一个概括区间，则使用文字。
举例：研究显示，数以千计的加拿大人每天都会网购。
Microsoft：当 2 个必须同时出现的数值指代不同分类时，其中 1 个可以使用文字。
2. 句末是否要使用句号
Material design：出现在标签、悬停文本、列表项、弹框中唯一的句子，需避免在其句末使用句号；如果句子后面有链接（这个链接本身不是完整的句子），则需在其句末使用句号；较长或复杂的句子是否要在其句末使用句号，则取决于上下文的句末中是否有句号。
3. 慎用感叹号
感叹号容易带给用户一种训斥的感觉，在报错提示中需尽量避免使用。除非表示较高的正面情绪（例如祝贺、鼓励、欢迎等），其他情况下应慎用感叹号。
无论是指南还是注意事项，尽管具有一定的普适性，但在实际运用时，还需结合具体情况考虑。它们不应该成为限制设计师编写文案时的条条框框，而旨在引发更多的设计思考。
参考文献
优设 内容总监
2012年成立至今，是国内极具人气的设计师交流学习平台
优设是国内专业设计师平台，2012年创办至今，作为行业风向标，我们13年来专注于设计师创作者的学习成长交流。 通过优设网、优优教程网、优创网分别沉淀优质内容。是一家集齐媒体、内容、服务的多元化平台。MCN矩阵@优设AIGC 在微博、微信、小红书、抖音、B站布局，全网粉丝过千万。