提及「设计规范」，我们通常会想到的是UI规范、交互规范。而文案呢？
在我们通常的认知里，应该是运营而不是设计师最终负责的范畴，更没有出规范的必要性。但我个人的习惯是，既然出现在我的设计稿上、由我提出的文案方案，就起码要先过自己这关，无论最终在职责上归谁负责敲定，那是另一码事。文案绝不是在交互文档上随便示意一下，然后写一句「最终文案由运营确定」就甩锅给运营完事了，何况很多时候运营更擅长对业务指标把关，并不看重（或者说不如产品、交互设计师擅长）从用户体验的维度去把关。所以，出现在自己设计稿上的文案，主动权要掌握在自己手里才踏实。
同时，在我看来文案设计规范的必要性一直被忽视了。一个产品的设计稿可能从初稿到定稿之间的修改周期非常长，依据评审结论也有很多变数，设计师今天出几个页面、明天改几个页面，由于个人语言习惯，以及出稿子时思路和心情不同，文案很难从始至终保持一致、不出差错。
2.准确性规范：用词准确、不累赘、不缺失、不模糊。
3.更高的要求——懂用户：从用户视角描述价值、正确使用人称代词、让用户听得懂、告诉用户Whynot。
词汇的一致是文案一致性的根本，但汉语的博大精深，造成在同一个表达中可能换很多词都是说得通的。因此，词汇是在设计过程中最容易出现前后不一致的地方，也是交付前Review的重点。
量词
故事的量词，统一用「篇」，而不是「段」、「条」。
△一站·故事的量词统一用「篇」
「22篇故事」
「22段故事」，「22条故事」
搜索结果的量词，统一用「条」，而不是「个」。
量词的例子还有很多，在此不做过多列举。其中，有些量词的一致化需要考虑符合产品场景和生活习惯，与语文角度可能会有所差异。
比如，车站的量词统一选用「个」，而不是「座」，因为生活中口语中实际上很少用「座」来形容地铁站，且在本产品的环境中并不需要强调其具象建筑层面上的含义。
名词
名词的一致化对产品统一心智的形成非常重要，尤其是一个产品中最核心的概念定义。
动词
动词的一致化不一定要用一个词去涵盖全部，因为通常都要同时应对两种语境（或者说时态）。
以内容发布为例，是表达「正在发出」的行为，还是对「已经发布了的内容」的陈述？
对「正在发出」的行为，通常出现在发布表单、发布后的Toast提示中。有关表单发布的词汇，在「发布」之外的近义词很多，如「确认」、「确定」、「提交」、「保存」、「完成」、「发表」。在本产品的语境中，最合理的应该选用「发布」。
△一站·表示正在发出的动作统一用「发布」
对「已经发布了的内容」的陈述，用「发布了」自然不算错。但根据平台调性的不同，可以有很多比冷冰冰的「发布了」更有温度感的选择，例如我在规范中选择的「写下了」，一方面与「故事」更搭调，一方面也能同时适用于Timeline和用户数据展示等多个场景。
△一站·表示已发布的内容统一用「写下了」
「写下了故事」，「写下了2篇故事」
「发布了故事」，「发表了2篇故事」
其他词汇一致性规范示例
这里看一些其他APP中的例子。
△左：抖音右：网易云音乐
抖音中出现了「赞」和「喜欢」两个近似概念的混用，给别人点「」，在自己的主页显示的是「喜欢」，而被别人点「」，显示的则是「获赞」。网易云音乐中，两个并列的Tab「发动态」和「发布视频」，一个动词是「发」一个是「发布」。
我不太清楚这两组词汇混用的背后是否确实有本质的区别，亦或仅仅是文案上的差别。
但作为用户角度，这样的不一致让我的理解成本增加了。2个词汇对用户而言是2个不同的概念，尤其是很多APP中「赞」和「喜欢」就是两个完全不同性质的功能，因此我在第一次使用时会试图猜测这两者之间的区别在哪。
一站的正常流界面中涉及句法的规范问题较少，主要出现在各类中间态和异常流的提示语中。
同类提示语保持一致，避免每个地方写的句子都完全不一样，最终导致表达同样含义的提示语在整个产品中变得五花八门。
语序一致：「图片上传失败」、「故事发布失败」保持一致的「名+动+状」结构，避免混用「动+名+状」之类的其他语序，如「上传图片失败」、「发布故事失败」。
「图片上传失败」与「故事发布失败」句式一致
「图片上传失败」混用「发布故事失败」
其他产品中，在正常流界面中也需要注意语序一致。比如不要一会写「流量充值」一会写「充值流量」。
建行APP的「全部投资理财产品」页，对所有同时涉及动词和名词的入口文案而言，几乎都采用的是「名+动」，如「资金投资」、「债券投资」、「黄金积存」、「外汇买卖」，唯有「代理贵金属」是「动+名」，类似的词组最好还是做好句式一致。
△建行「全部投资理财产品」页的入口文案
这一点比较容易理解，但在页面设计中，改来改去很容易入口和跳转页面的文案就对不上号了。其中最常见的一种情况是遗漏前缀或者写了多余的前缀：
豆瓣首页的「豆瓣日历」点击后跳转到的页面标题却是「豆瓣市集」，直到看到下面的新品首发才能明白「豆瓣日历」是正在出售的新品中的一种，然而豆瓣市集里明明还同时出售其他很多商品，这个入口名称的设置很容易让用户一头雾水。
△豆瓣首页「豆瓣日历」的跳转去向是「豆瓣市集」
当然，由于入口字数受限，因而不得不缩减字数表达的情况是个例外，在没有其他更好办法的情况下也只能接受。
适用情形：普通内容List、内容末端节点。
△一站·左：普通内容List右：内容详情页
适用情形：Timeline、消息列表等。
至于「近期」到底以什么界线划分，没有绝对的对与错，按产品实际需要制定规范就可以。常见的划分界线是昨天、前天和一星期前。
△一站·左：我的动态右：消息
注意：月、日为1位数字时，前方不补0；小时、分钟为1位数字时，前方补0凑齐2位。
△一站·车站故事的两个Tab
△一站·统一用阿拉伯数字表达
△一站·特殊情况确有需要时，仍用汉字表达
△一站·数量前后有汉字时增加空格
「写下了4篇故事」
这里看两个我们常用APP里的例子。
△左：豆瓣个人设置页右：百度地图的评分弹窗
豆瓣在编辑个人主页的生日设置中，贴心地告诉用户生日设置并不会被用于个性化推荐，但这类说明文案是没有必要加句号的。
再看看百度地图的评分弹窗，这里且不论没用几次就弹出来要求用户评分的弹窗是否合理，就那3个硕大的感叹号已经足够让很多用户心惊肉跳一下了。
这一点应该是文案的基本要求，用词出现不准确、不符合用户习惯的现象，容易增加用户的理解成本，给用户留下不专业的印象。
△电信营业厅APP
这个叫法能不能说得通？当然能，验证码当然是随机的数字组合。但能说得通并不代表用词准确，准确与否是由国内用户的惯有认知决定的。
再比如，喜马拉雅APP在编辑资料时，「简介」是一个输入项，提示「未填写」是正确的，而「生日」和「地区」都是选择器，不应该提示「未填写」而应该是「未选择」。
△喜马拉雅·编辑资料页
在文案复查中留意是否存在冗余的文字，结合页面场景和上下文已经完全能理解的信息无需重复表达，只会徒增用户的信息认知负担和理解成本。
例如在「一站」的故事发布页面中，车站和所属专题的选择提示文案，就不用再强调其与故事之间逻辑从属关系。右上角的「发布」按钮，也不用强调是「发布故事」。
△一站·故事发布
「请选择」
「请选择故事对应的车站」，「请选择故事所属的专题」
在专题首页中，在List内容显然全都是「故事」的前提下，3个Tab也无需再次强调「故事」的字眼。
△一站·专题首页
下面看看这两个阅读压力非常大的页面。
△左：懂球帝右：同花顺
而实际上用户之所以在懂球帝打开了扫一扫，绝大多数情况下都是已经处于这2种场景中的其中一种。绝大多数用户进入扫一扫，并不是闲的没事，进来后看到“哦，原来这两个地方可以用到”，然后去找码扫。而是先有扫码场景，才会进入扫码功能。
那么在扫一扫界面，又有什么必要再告诉用户「你一定是从这两个地方来的」呢？只能徒增用户的阅读负荷。有兴趣的朋友可以去看一下其他APP的扫码页面，提示文案一般只有下方那句「将二维码放入框内即可自动扫描」，这才是不熟悉操作的用户在这个界面可能需要看到的文案。
同花顺的模拟炒股大赛报名页更夸张一点，在每个输入框的占位提示符中重复了「请输入您的」这5个字，一下子让整个页面充满压迫感。同时，主行动按钮文案也略显冗余，「报名」两个字足够说清的事情，却用了「提交资料报名参赛」8个大字。
对行动点文案而言，要做到将行动点背后的关键信息准确、直接的让用户知晓。
例如，在搜索栏的提示占位符中清晰的告知用户可以搜索的数据类型。
△一站·搜索提示文案
「搜索车站故事用户等」
「搜一搜」、「点击进行搜索」、「点击开始搜索」
异常流报错时，应当告诉用户可行的解决方案，或产品为用户做了哪些挽救措施。
Toast：
空态中，也需要告诉用户下一步可以采取的行动，而不是单纯的告诉用户这里为空。这实际上不是一个文案问题，而是一个产品和交互的问题。
避免「可能」、「大概」、「也许」，会为用户凭添一层「到底是不是」的判断，除非在一些异常流中技术上确实无法判断问题所在。
在这方面做得非常棒的一个APP就是Keep，其体验路径的各个环节都能感受到产品在文案上的用心程度。这里只举一个注册流程的例子。在注册完成后，Keep会希望用户完善一些基本资料，对产品来说有利于制订个性化的用户分层策略，也是很有价值的数据沉淀。在这个流程中，Keep充分通过文案向用户传达了完善资料对他的价值（找到合适的训练、实现健身目标、依据身高设计训练内容等），并排除了用户对隐私数据的担忧（放心，Keep不会泄露你的资料）。
△Keep
反例是Airbnb，同样是希望用户完善资料，「我的」页的资料完善进度条下方的文案是这么写的：「我们要求每一位爱彼迎用户在旅行或出租之前提供一些具体信息，现在就来完善这一步吧」。
△Airbnb·「我的」
我不清楚一个以体验优秀著称的产品里怎么会出现这样一句文案，也许是直译导致的问题。
改成「在旅行或出租之前提供一些具体信息，可以在爱彼迎获得更好的服务与体验」，是不是同样的意思，听起来舒服多了？
一站的人称代词规范：默认使用「你」，同时，在语境合理、语法通顺的情况下尽可能使用「我」代替「你」。文案中常用的人称代词是第一人称「我」和第二人称「你」、「您」。第二人称的泛用性比较好，可以适合绝大多数的语境和句式。但在合理的情况下，可以尽可能多的尝试以第一人称「我」为主体进行描述，相比第二人称，更能让用户感受到自己在产品体验过程中的主导地位。
至于第二人称中用「你」还是「您」，并没有绝对的对与错。对年轻群体为主的社交、电商、娱乐型的APP，用「你」更合适、对用户更具亲和力和自由平等的感觉，「您」反而让用户感到与产品之间有一种莫名的距离感。反过来，银行、金融服务产品中，其线下场景「宾至如归」的态度在线上也需要体现，此时用「您」更加合适，面向企业用户的B端产品也同理。
第一与第二人称没有绝对的优劣之分，「你」和「您」也没有绝对的对与错，但至少需要在APP级进行统一，并不意味着可以随意混用。我们看看移动营业厅APP中的两个例子：
△移动营业厅
我到底是「我」还是「你」还是「您」？一会「你」一会「您」，你到底是尊重我还是不尊重我？
根据用户群体的不同，在文案中尽量使用他们能听得懂的词汇。例如，在社交、娱乐、电商、出行等用户群体较广的应用中，用语应当尽可能简单、直白。避免使用一些设计师或者产品团队内部自己明白，而用户听起来一头雾水的词语。
就举一个最简单的例子，12306买票时，这个「受让人」和下面那句温馨的绕口令，请问有谁能在事先不了解「受让人」是什么意思的情况下看懂？
△国民级APP——12306
此外，如果用户的行业属性很强，就要吃透他们的语言习惯。
例如，在一个工程项目管理应用中，「专业负责人」是工程业内用户非常熟悉的一个专有名词，代表暖通、电气、给排水等各个专业的牵头人，这时用互联网行业的「主管」之类的词语就贻笑大方了。
同样，在一个专业理财产品里，一些金融术语该直接使用时就直接使用，写得太白话反而影响专业性。
让用户始终有选择的权利，让他在体验中感觉到可控性是非常重要的。以系统设置为例，尽量保证出现在设置中的选项都是允许用户选择的。而如确有必要不允许用户选择时，应该告诉用户其背后的原因。
△无法选择时告诉用户Whynot左：Airbnb右：知乎
文案设计规范的三个层次中，一致性是文案质量的基石，准确性是提升质量的关键，懂用户则是更高的要求。
这里举的一些反例可能整体看来都是非常优秀的产品，比如Airbnb和网易云音乐，可能有朋友会觉得是不是太吹毛求疵了？好像例子中的这些问题对体验也无伤大雅，也不影响产品全局的评价和口碑。
说实话，如果作为一般用户，可能确实不需要留意到这些细节，大概率对核心体验也没有特别大的影响。
但作为一个具有职业敏感性的产品设计师来说，我觉得对细节的追求还是要有的。换位思考一下，在自己的产品中，能通过规范和走查避免的问题，为什么一定要用「无伤大雅」去开脱呢？
从项目的责任心上说，文案设计是设计师和运营要各自从用户体验和业务指标上共同把关的。而从设计师个人的成长来讲，每多留心一次文案细节，未来出类似方案时就可以信手拈来地给出高质量的文案，对自己在项目中培养更规范、更严谨的设计习惯也大有裨益。