资讯详情
提及「设计规范」，我们通常会想到的是UI规范、交互规范。而文案呢？
在我 们通常的认知里，应该是运营而不是设计师最终负责的范畴，更没有出规范的必要性。但我个人的习惯是，既然出现在我的设计稿上、由我提出的文案方 案，就起码要先过自己这关，无论最终在职责上归谁负责敲定，那是另一码事。文案绝不是在交互文档上随便示意一下，然后写一句「最终文案由运营确定」就甩锅给运营完事了，何况很多时候运营更擅长对业务指标把关，并不看重（或者说不如产品、交互设计师擅长 ）从用户体验的维度去把关。所以，出现在自己设计稿上的文案，主动权要掌握在自己手里才踏实。
同时，在我看来文案设计规范的必要性一 直被忽视了。一个产品的设计稿可能从初稿到定稿之间的修改周期非常长，依据评审结论也有很多变数，设计师今天出几个页面、明天改几个页面，由于个人语言习惯，以及出稿子时思路和心情不同，文案很难从始至终保持一致、不出差错。
所以在定稿交付开发 前，根据统一的文案设计规范，重新对文案彻底Review一遍是很有必要的。就像这次用作案例的概念方案「一站」，在根据规范进行一次细致的走查后，相比一个月前分享出来的版本也完善了很多文案上的细节。
在我的了解范围内，目前很少看到有对文案规范的 总结与分享。只有Ant Design在其组件文档中对文案注意事项有一个相对系统的总结，在思考的系统性上比较有学习价值，在此前用于工作上的文案自查中给了我很大的帮助。但其中很多结论是基于一款金融服务行业的Web端中后台产品制定的，个人觉得有很多不一定适 用于这个范围之外的产品。
因此，一直希望通过一篇文章，对移动端产品的文案设计规范进行一次适用面更广的梳理和总结——一份文案设计规范需要包括哪些层次的内容？有哪些原则需要在规范中写明？
本文将以一个基于地铁查询工具的心情分享平台「一站」为例，其间也会穿插一些其他APP中的例子，尽可能详细介绍文案设计中可 能出现的常见问题类型，以及一份比较完善的文案设计规范由哪些内容构成。
文章内容：文案设计规范的三个层次
1. 一致性规范：词汇一致、句式一致、行动点与目的页面标题一致、时间表达规范、数字一致性规范、标点一致性规范。
2. 准确性规范：用词准确、不累赘、不缺失、不模糊。
3. 更高的要求——懂用户：从用户视角描述价值、 正确使用人称代词、让用户听得懂、告诉用户Why not。
词汇的一致是文案一致性的根本，但汉语的博大精深，造成在同一个表达中可能换很多词都是说得通的 。因此，词汇是在设计过程中最容易出现前后不一致的地方，也是交付前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种不同的提示文案「请登录~」、「立即登录」、「登录」、「马上登录」。
△ 电信营业厅：五花八门的登录提示语
一站的正常流界面中涉及句法的规范问题较少，主 要出现在各类中间态和异常流的提示语中。
同类提示语保持一致，避免每个地方写的句子都完全不一样，最终导致表达同样含义的提示语在整个产品中变得五花八门。
?? 「你已经输入了故事内容，确定放弃并返回吗？」与「你已经输入了 评论内容，确定放弃并返回吗？」句式一致
? 「你已经输入了故事内容，确定放弃并返回吗？」混用「确定放弃已输入的评论并返回吗？」
语序一致：「图片上传失败」、「故事发布失败」保持一致的「名+动+状」结构，避免混用「动+名 +状」之类的其他语序，如「上传图片失败」、「发布故事失败」。
?? 「图片上传失败」与「故事发布失败」句式一致
? 「图片上传失败」混用「发布故事失败」
其他产品中，在正常流界面中也需要注意语序一致。 比如不要一会写「流量充值」一会写「充值流量」。
建行APP的「全部投资理财产品」页 ，对所有同时涉及动词和名词的入口文案而言，几乎都采用的是「名+动」，如「资金投资」、「债券投资」、「黄金积存」、「外汇买卖」，唯有「代理贵金属」是「动+名」，类似的词组最好还是做好句式一致。
△ 建行「全部投资理财产品」页的入口文案
这一点比较容易理解，但在页面设计中，改来改去很容易入口和跳 转页面的文案就对不上号了。其中最常见的一种情况是遗漏前缀或者写了多余的前缀：
「编辑精选」跳转到了「精选」
「我的动态」跳转到了「动态」
「关于一站」跳转到了「关于我们」
「设置」跳转到了「系统设置」
豆瓣首页的「豆瓣日历」点击后跳转到的页面标题却是「豆瓣市集」，直到看到下面的新品首发才能明白「豆瓣日历」是正在出售的新品中的一种，然而豆瓣市集里明明还同时出售其他很多商品，这个入口名称的设置很容易 让用户一头雾水。
△ 豆瓣首页「豆瓣日历」的跳转去向是「豆瓣市集」
当然，由于入 口字数受限，因而不得不缩减字数表达的情况是个例外，在没有其他更好办法的情况下也只能接受。
内容发布时间的表达上，按照所处场景本身是否有时间属性，需要分成两个大的类型进行考虑。
方案A. 全 部采用绝对时间
适用情形：普通内容List、内容末端节点。
在普通内容List中，内容以热度、运营策略或其他逻辑决定排序，本身没有时间相关的属性，此时发布时间没有必要也不合适用「X小时前」这样的相对时间进行表达。例如首页本周热门、编辑精 选、车站详情页的故事List、热门评价区等。
同时，在内容浏览链路的末端节点（如内容详情页和对话气泡列表），需要保证所有关于内容的信息不能出现缺失，因此在这里需要具体的告诉用户这篇内容发布的绝对时间。
△ 一站 · 左：普通内容List 右：内容详情页
在这两种情况下，用绝对时间表达更加合适：
方案B. 相对时间+绝对时间
适用情形：Timeline、消息列表等。
在Timeline、消息列表等本身包含了时间逻辑（通常是默认 倒序）的列表中，可以在近期内按相对时间表达，向用户传达更直观的时间概念，减轻用户对时间的思考负荷。一站中典型的例子，如我的收藏、我的关注Feeds、我的动态、最新评价区等。
至于「近期」到底以什么界线划分，没有绝对的对与错，按产品实际需 要制定规范就可以。常见的划分界线是昨天、前天和一星期前。
△ 一站 · 左：我的动态 右：消息
对上述类型的时间信息，近期内 采用相对时间表达，更早的则依旧采用绝对时间表达：
注意：月、日为1位数字时，前方不补0；小时、分钟为1位数字时，前方补0 凑齐2位。
此外有一个特殊情况，以车站故事的「最热/最新」两个Tab为例，那么虽然「最新」理论上符合基于车站维度聚合、按时间倒序的内容流，应该采用方案B。但为了保证同一信息结构下的两个Tab中时间呈现格式一致，格式上仍与「最热」一同采用方案A 。
△ 一站 · 车站故事的两个Tab
涉及数字的表达统一使用阿拉伯数字，这点在设计 过程中一般不会出错，但数字是1的时候偶尔可能会习惯性地写成「一」，如地铁线路表达为「1号线」而不是「一号线」；新评论提醒的Push文案是「您的故事收到了1条新的评论」，而不是「您的故事收到了一条新的评论」。
△ 一站 · 统一用阿拉 伯数字表达
?? 「1号线」，「您的故事收到了1条新的评论」
? 「一号线」，「您的故事收到了一条新的评论」
但一站中存在一些例外情况，如我的故事中的时间戳、专题卷数等需要突出时间痕迹、历史感的场景下 ，仍用汉字数字表达。因此，数字格式的规范要根据产品实际需要，明确特殊用例。
△ 一站 · 特殊情况确有需要时，仍用汉字 表达
此外，数量信息前后有汉字时需要加空格，让写死的文本字段和变量字段的区隔更清晰。注意像「7号线」等不表达数量信息的阿拉伯数字无需补加空格。此外，系统Push中的数量（如「你的故事收到了3条新的评论」）也不需要补加空格，因为Push只是一串 文本，不需要考虑作为界面元素呈现时的清晰性。
△ 一站 · 数量前后有汉字时增加空格
?? 「写下了 4 篇故事」
? 「写下了4篇故事」
地铁线路或地铁站前方需要注明城市时：由居中点号「 · 」区隔，注意不是小数点，前后各有1个空格。例：「广州 · 4号线」，「重庆 · 杨家坪 」。
换乘站的所属线路表达：由「/」区隔，前后无空格。例：「4号线/7号线」。
括号规范：统一使用英文半角括号，前方或后方有汉字时，补充1个空格间隔。例：「故事 (1292篇)」。
超长截断：采用半个省略号「…」（1个全角字符） ，而不是整个省略号「……」（2个全角字符）或「…」（3个半角英文小数点）。
不使用句号等标点的情况：页面主标题与副标题、输入提示符、输入框下方或输入框中的提示文字、Toast中、弹窗或Actionsheet的选项、按钮中。确有必要需要使用逗号和问号 时除外。
这里看两个我们常用APP里的例子。
△ 左：豆瓣个人设置页 右：百度地图的评分弹窗
豆瓣在编辑个人主页的生日设置中，贴心地告诉用户生日设置并不会被用于个性化推荐，但这类说明文案是没 有必要加句号的。
再看看百度地图的评分弹窗，这里且不论没用几次就弹出来要求用户评分的弹窗是否合理，就那3个硕大的感叹号已经足够让很多用户心惊肉跳一下了。
这一点应该是文案的基本要求，用词出现不准确、不符合用户习惯的现象，容易增加用户的理解成本，给用户留下不专业的印象。
举个简单的例子，短信验证登录是现在移动端登录的标配途径，用户对「验证码」的概念已经建立了相当牢固的 心智，99%的产品中也都遵循了这一惯例叫法，而偏偏有一些APP里会沿用自己独特的术语，比如电信营业厅的登录页中就叫「随机码」（这里就不说「获取随机码」和「请输入随机密码」不一致的问题了）。
△ 电信营业厅APP
这个叫法能不能说得通？当然能，验证码当然是随机的数字组合。但能说得通并不代表用词准确，准确与否是由国内用户的惯有认知决定的。
再比 如，喜马拉雅APP在编辑资料时，「简介」是一个输入项，提示「未填写」是正确的，而「生日」和「 地区」都是选择器，不应该提示「未填写」而应该是「未选择」。
△ 喜马拉雅 · 编辑资料页
此外，在toB的企业管理应用、金融支付 相关、行业背景专业性较强的应用中，更需要注意一些行业术语的使用准确。这点在之前做过的B端企业应用、项目管理平台里感触颇多，不过因为行业背景离日常生活比较远，这里就不过多举例了。
在文案复查中留意是否 存在冗余的文字，结合页面场景和上下文已经完全能理解的信息无需重复表达，只会徒增用户的信息认知负担和理解成本。
例如在「一站」的故事发布页面中，车站和所属专题的选择提示文案，就不用再强调其与故事之间逻辑从属关系。右上角的「发布」按钮， 也不用强调是「发布故事」。
△ 一站 · 故事发布
?? 「请选择」
? 「请 选择故事对应的车站」，「请选择故事所属的专题」
在专题首页中，在List内容显然全都是「故事」的前提下，3个Tab也无需再次强调「故事」的字眼。
△ 一站 · 专题首页
?? 「最新」/「最热」/「精选」
? 「最热故事」/「最新故事」/「精选故事」
下面看看这两个阅读压 力非常大的页面。
△ 左：懂球帝 右：同花顺
懂球帝的扫一扫界面中，在扫码框上方写了两行文案「打开网页版懂球帝登录页面，扫描二维码登录」和「扫描懂球号二维码，关注懂球号」，介绍了懂球帝里 扫码的2个场景。
而实际上用户之所以在懂球帝打开了扫一扫，绝大多数情况下都是。
