提及「设计规范」，我们通常会想到的是UI规范、交互规范。而文案呢？
在我们通常的认知里，应该是运营而不是设计师最终负责的范畴，更没有出规范的必要性。但我个人的习惯是，既然出现在我的设计稿上、由我提出的文案方案，就起码要先过自己这关，无论最终在职责上归谁负责敲定，那是另一码事。文案绝不是在交互文档上随便示意一下，然后写一句「最终文案由运营确定」就甩锅给运营完事了，何况很多时候运营更擅长对业务指标把关，并不看重（或者说不如产品、交互设计师擅长）从用户体验的维度去把关。所以，出现在自己设计稿上的文案，主动权要掌握在自己手里才踏实。
同时，在我看来文案设计规范的必要性一直被忽视了。一个产品的设计稿可能从初稿到定稿之间的修改周期非常长，依据评审结论也有很多变数，设计师今天出几个页面、明天改几个页面，由于个人语言习惯，以及出稿子时思路和心情不同，文案很难从始至终保持一致、不出差错。
所以在定稿交付开发前，根据统一的文案设计规范，重新对文案彻底Review一遍是很有必要的。就像这次用作案例的概念方案「一站」，在根据规范进行一次细致的走查后，相比一个月前分享出来的版本也完善了很多文案上的细节。
在我的了解范围内，目前很少看到有对文案规范的总结与分享。只有Ant Design在其组件文档中对文案注意事项有一个相对系统的总结，在思考的系统性上比较有学习价值，在此前用于工作上的文案自查中给了我很大的帮助。但其中很多结论是基于一款金融服务行业的Web端中后台产品制定的，个人觉得有很多不一定适用于这个范围之外的产品。
因此，一直希望通过一篇文章，对移动端产品的文案设计规范进行一次适用面更广的梳理和总结——一份文案设计规范需要包括哪些层次的内容？有哪些原则需要在规范中写明？
本文将以一个基于地铁查询工具的心情分享平台「一站」为例，其间也会穿插一些其他APP中的例子，尽可能详细介绍文案设计中可能出现的常见问题类型，以及一份比较完善的文案设计规范由哪些内容构成。
鉴于工作中的案例不便讨论，专门为设计交流做的一个概念方案，详情见：《进阶学习！如何做好产品界面中的内容设计？》
文章内容：文案设计规范的三个层次
1. 一致性规范：词汇一致、句式一致、行动点与目的页面标题一致、时间表达规范、数字一致性规范、标点一致性规范。
2. 准确性规范：用词准确、不累赘、不缺失、不模糊。
3. 更高的要求——懂用户：从用户视角描述价值、正确使用人称代词、让用户听得懂、告诉用户Why not。
一. 一致性规范
1. 词汇一致
词汇的一致是文案一致性的根本，但汉语的博大精深，造成在同一个表达中可能换很多词都是说得通的。因此，词汇是在设计过程中最容易出现前后不一致的地方，也是交付前Review的重点。
一些用词、句式的选取上，可能未必我选择的就是最好的，但还是那句话，统一了就比不统一要好一百倍。这篇文章也不是为了细究A和B哪个表达更好，只是探讨统一规范的必要性和构成内容。
量词
故事的量词，统一用「篇」，而不是「段」、「条」。
△ 一站 · 故事的量词统一用「篇」
?? 「22 篇故事」
? 「22 段故事」，「22 条故事」
搜索结果的量词，统一用「条」，而不是「个」。
量词的例子还有很多，在此不做过多列举。其中，有些量词的一致化需要考虑符合产品场景和生活习惯，与语文角度可能会有所差异。
比如，车站的量词统一选用「个」，而不是「座」，因为生活中口语中实际上很少用「座」来形容地铁站，且在本产品的环境中并不需要强调其具象建筑层面上的含义。
名词
名词的一致化对产品统一心智的形成非常重要，尤其是一个产品中最核心的概念定义。
例如，「一站」中最核心的内容元素就是用户发布的地铁「故事」，这是一定要统一的词汇，不能混用「文章」、「评论」等等词。
动词
动词的一致化不一定要用一个词去涵盖全部，因为通常都要同时应对两种语境（或者说时态）。
以内容发布为例，是表达「正在发出」的行为，还是对「已经发布了的内容」的陈述？
对「正在发出」的行为，通常出现在发布表单、发布后的Toast提示中。有关表单发布的词汇，在「发布」之外的近义词很多，如「确认」、「确定」、「提交」、「保存」、「完成」、「发表」。在本产品的语境中，最合理的应该选用「发布」。
△ 一站 · 表示正在发出的动作统一用「发布」
?? 「发布」，「发布中…」，「故事发布成功」，「评论发布成功」
? 「完成」，「提交中…」，「故事发表成功」，「评论提交成功」
对「已经发布了的内容」的陈述，用「发布了」自然不算错。但根据平台调性的不同，可以有很多比冷冰冰的「发布了」更有温度感的选择，例如我在规范中选择的「写下了」，一方面与「故事」更搭调，一方面也能同时适用于Timeline和用户数据展示等多个场景。
△ 一站 · 表示已发布的内容统一用「写下了」
?? 「写下了故事」，「写下了 2 篇故事」
? 「发布了故事」，「发表了 2 篇故事」
其他词汇一致性规范示例
- 「评论了 Qinsman 的故事」，而不是「回复了 Qinsman 的故事」、「评价了 Qinsman 的故事」
- 「开往长湴」，而不是「去往长湴」、「开向长湴」
- 「点赞」，而不是「喜欢」
- 「TA」，而不是「他」或「她」（这是考虑到产品的场景并没有强化用户性别认知的需求，且需要考虑到用户设置性别保密的情况。相反，如果是一款主打异性陌生人社交的产品，那么显示的告知用户性别的意义就大了很多）
- 「车站」，而不是「地铁站」、「站点」（有个例外是「站点列表」页，因为需要强调List中的每个站在「车站」这一统称下的个体性，因此仅在此页面使用「站点」）
- 「专题」，而不是「话题」、「主题」
- 「故事发布成功」，而不是「故事发布完成」
- 「互相关注」，而不是「相互关注」
这里看一些其他APP中的例子。
△ 左：抖音 右：网易云音乐
抖音中出现了「赞」和「喜欢」两个近似概念的混用，给别人点「??」，在自己的主页显示的是「喜欢」，而被别人点「??」，显示的则是「获赞」。网易云音乐中，两个并列的Tab「发动态」和「发布视频」，一个动词是「发」一个是「发布」。
我不太清楚这两组词汇混用的背后是否确实有本质的区别，亦或仅仅是文案上的差别。
但作为用户角度，这样的不一致让我的理解成本增加了。2个词汇对用户而言是2个不同的概念，尤其是很多APP中「赞」和「喜欢」就是两个完全不同性质的功能，因此我在第一次使用时会试图猜测这两者之间的区别在哪。
下面这个例子更夸张一点。电信营业厅APP里，在4个一级Tab中都要求用户登录，但4个Tab分别用了4种不同的提示文案「请登录~」、「立即登录」、「登录」、「马上登录」。
△ 电信营业厅：五花八门的登录提示语
2. 句式一致
一站的正常流界面中涉及句法的规范问题较少，主要出现在各类中间态和异常流的提示语中。
同类提示语保持一致，避免每个地方写的句子都完全不一样，最终导致表达同样含义的提示语在整个产品中变得五花八门。
?? 「你已经输入了故事内容，确定放弃并返回吗？」与「你已经输入了评论内容，确定放弃并返回吗？」句式一致
? 「你已经输入了故事内容，确定放弃并返回吗？」混用「确定放弃已输入的评论并返回吗？」
语序一致：「图片上传失败」、「故事发布失败」保持一致的「名+动+状」结构，避免混用「动+名+状」之类的其他语序，如「上传图片失败」、「发布故事失败」。
?? 「图片上传失败」与「故事发布失败」句式一致
? 「图片上传失败」混用「发布故事失败」
其他产品中，在正常流界面中也需要注意语序一致。比如不要一会写「流量充值」一会写「充值流量」。
建行APP的「全部投资理财产品」页，对所有同时涉及动词和名词的入口文案而言，几乎都采用的是「名+动」，如「资金投资」、「债券投资」、「黄金积存」、「外汇买卖」，唯有「代理贵金属」是「动+名」，类似的词组最好还是做好句式一致。
