如何写好移动端产品文案？这儿有份超详细的规范指南

提及「设计规范」，我们通常会想到的是UI规范、交互规范。而文案呢？

在我们通常的认知里，应该是运营而不是设计师最终负责的范畴，更没有出规范的必要性。但我个人的习惯是，既然出现在我的设计稿上、由我提出的文案方案，就起码要先过自己这关，无论最终在职责上归谁负责敲定，那是另一码事。文案绝不是在交互文档上随便示意一下，然后写一句「最终文案由运营确定」就甩锅给运营完事了，何况很多时候运营更擅长对业务指标把关，并不看重（或者说不如产品、交互设计师擅长）从用户体验的维度去把关。所以，出现在自己设计稿上的文案，主动权要掌握在自己手里才踏实。

同时，在我看来文案设计规范的必要性一直被忽视了。一个产品的设计稿可能从初稿到定稿之间的修改周期非常长，依据评审结论也有很多变数，设计师今天出几个页面、明天改几个页面，由于个人语言习惯，以及出稿子时思路和心情不同，文案很难从始至终保持一致、不出差错。

所以在定稿交付开发前，根据统一的文案设计规范，重新对文案彻底Review一遍是很有必要的。就像这次用作案例的概念方案「一站」，在根据规范进行一次细致的走查后，相比一个月前分享出来的版本也完善了很多文案上的细节。

在我的了解范围内，目前很少看到有对文案规范的总结与分享。只有Ant Design在其组件文档中对文案注意事项有一个相对系统的总结，在思考的系统性上比较有学习价值，在此前用于工作上的文案自查中给了我很大的帮助。但其中很多结论是基于一款金融服务行业的Web端中后台产品制定的，个人觉得有很多不一定适用于这个范围之外的产品。

因此，一直希望通过一篇文章，对移动端产品的文案设计规范进行一次适用面更广的梳理和总结——一份文案设计规范需要包括哪些层次的内容？有哪些原则需要在规范中写明？

本文将以一个基于地铁查询工具的心情分享平台「一站」为例，其间也会穿插一些其他APP中的例子，尽可能详细介绍文案设计中可能出现的常见问题类型，以及一份比较完善的文案设计规范由哪些内容构成。

鉴于工作中的案例不便讨论，专门为设计交流做的一个概念方案，详情见：《进阶学习！如何做好产品界面中的内容设计？》

文章内容：文案设计规范的三个层次

1. 一致性规范：词汇一致、句式一致、行动点与目的页面标题一致、时间表达规范、数字一致性规范、标点一致性规范。

2. 准确性规范：用词准确、不累赘、不缺失、不模糊。

3. 更高的要求——懂用户：从用户视角描述价值、正确使用人称代词、让用户听得懂、告诉用户Why not。

一. 一致性规范

1. 词汇一致

词汇的一致是文案一致性的根本，但汉语的博大精深，造成在同一个表达中可能换很多词都是说得通的。因此，词汇是在设计过程中最容易出现前后不一致的地方，也是交付前Review的重点。

一些用词、句式的选取上，可能未必我选择的就是最好的，但还是那句话，统一了就比不统一要好一百倍。这篇文章也不是为了细究A和B哪个表达更好，只是探讨统一规范的必要性和构成内容。

量词

故事的量词，统一用「篇」，而不是「段」、「条」。

△ 一站 · 故事的量词统一用「篇」

「22 篇故事」

「22 段故事」，「22 条故事」

搜索结果的量词，统一用「条」，而不是「个」。

量词的例子还有很多，在此不做过多列举。其中，有些量词的一致化需要考虑符合产品场景和生活习惯，与语文角度可能会有所差异。

比如，车站的量词统一选用「个」，而不是「座」，因为生活中口语中实际上很少用「座」来形容地铁站，且在本产品的环境中并不需要强调其具象建筑层面上的含义。

名词

名词的一致化对产品统一心智的形成非常重要，尤其是一个产品中最核心的概念定义。

例如，「一站」中最核心的内容元素就是用户发布的地铁「故事」，这是一定要统一的词汇，不能混用「文章」、「评论」等等词。

动词

动词的一致化不一定要用一个词去涵盖全部，因为通常都要同时应对两种语境（或者说时态）。

以内容发布为例，是表达「正在发出」的行为，还是对「已经发布了的内容」的陈述？

对「正在发出」的行为，通常出现在发布表单、发布后的Toast提示中。有关表单发布的词汇，在「发布」之外的近义词很多，如「确认」、「确定」、「提交」、「保存」、「完成」、「发表」。在本产品的语境中，最合理的应该选用「发布」。

△ 一站 · 表示正在发出的动作统一用「发布」

「发布」，「发布中…」，「故事发布成功」，「评论发布成功」

「完成」，「提交中…」，「故事发表成功」，「评论提交成功」

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!