提及「設計規范」，我們通常會想到的是UI規范、交互規范。而文案呢？

在我們通常的認知里，應該是運營而不是設計師最終負責的范疇，更沒有出規范的必要性。但我個人的習慣是，既然出現在我的設計稿上、由我提出的文案方案，就起碼要先過自己這關，無論最終在職責上歸誰負責敲定，那是另一碼事。文案絕不是在交互文檔上隨便示意一下，然后寫一句「最終文案由運營確定」就甩鍋給運營完事了，何況很多時候運營更擅長對業務指標把關，并不看重（或者說不如產品、交互設計師擅長）從用戶體驗的維度去把關。所以，出現在自己設計稿上的文案，主動權要掌握在自己手里才踏實。

同時，在我看來文案設計規范的必要性一直被忽視了。一個產品的設計稿可能從初稿到定稿之間的修改周期非常長，依據評審結論也有很多變數，設計師今天出幾個頁面、明天改幾個頁面，由于個人語言習慣，以及出稿子時思路和心情不同，文案很難從始至終保持一致、不出差錯。

所以在定稿交付開發前，根據統一的文案設計規范，重新對文案徹底Review一遍是很有必要的。就像這次用作案例的概念方案「一站」，在根據規范進行一次細致的走查后，相比一個月前分享出來的版本也完善了很多文案上的細節。

在我的了解范圍內，目前很少看到有對文案規范的總結與分享。只有Ant Design在其組件文檔中對文案注意事項有一個相對系統的總結，在思考的系統性上比較有學習價值，在此前用于工作上的文案自查中給了我很大的幫助。但其中很多結論是基于一款金融服務行業的Web端中后臺產品制定的，個人覺得有很多不一定適用于這個范圍之外的產品。

因此，一直希望通過一篇文章，對移動端產品的文案設計規范進行一次適用面更廣的梳理和總結——一份文案設計規范需要包括哪些層次的內容？有哪些原則需要在規范中寫明？

本文將以一個基于地鐵查詢工具的心情分享平臺「一站」為例，其間也會穿插一些其他APP中的例子，盡可能詳細介紹文案設計中可能出現的常見問題類型，以及一份比較完善的文案設計規范由哪些內容構成。

鑒于工作中的案例不便討論，專門為設計交流做的一個概念方案，詳情見：《進階學習！如何做好產品界面中的內容設計？》

文章內容：文案設計規范的三個層次

1. 一致性規范：詞匯一致、句式一致、行動點與目的頁面標題一致、時間表達規范、數字一致性規范、標點一致性規范。

2. 準確性規范：用詞準確、不累贅、不缺失、不模糊。

3. 更高的要求——懂用戶：從用戶視角描述價值、正確使用人稱代詞、讓用戶聽得懂、告訴用戶Why not。

一. 一致性規范

1. 詞匯一致

詞匯的一致是文案一致性的根本，但漢語的博大精深，造成在同一個表達中可能換很多詞都是說得通的。因此，詞匯是在設計過程中最容易出現前后不一致的地方，也是交付前Review的重點。

一些用詞、句式的選取上，可能未必我選擇的就是最好的，但還是那句話，統一了就比不統一要好一百倍。這篇文章也不是為了細究A和B哪個表達更好，只是探討統一規范的必要性和構成內容。

量詞

故事的量詞，統一用「篇」，而不是「段」、「條」。

△ 一站 · 故事的量詞統一用「篇」

?? 「22 篇故事」

? 「22 段故事」，「22 條故事」

搜索結果的量詞，統一用「條」，而不是「個」。

量詞的例子還有很多，在此不做過多列舉。其中，有些量詞的一致化需要考慮符合產品場景和生活習慣，與語文角度可能會有所差異。

比如，車站的量詞統一選用「個」，而不是「座」，因為生活中口語中實際上很少用「座」來形容地鐵站，且在本產品的環境中并不需要強調其具象建筑層面上的含義。

名詞

名詞的一致化對產品統一心智的形成非常重要，尤其是一個產品中最核心的概念定義。

例如，「一站」中最核心的內容元素就是用戶發布的地鐵「故事」，這是一定要統一的詞匯，不能混用「文章」、「評論」等等詞。

動詞

動詞的一致化不一定要用一個詞去涵蓋全部，因為通常都要同時應對兩種語境（或者說時態）。

以內容發布為例，是表達「正在發出」的行為，還是對「已經發布了的內容」的陳述？

對「正在發出」的行為，通常出現在發布表單、發布后的Toast提示中。有關表單發布的詞匯，在「發布」之外的近義詞很多，如「確認」、「確定」、「提交」、「保存」、「完成」、「發表」。在本產品的語境中，最合理的應該選用「發布」。

△ 一站 · 表示正在發出的動作統一用「發布」

?? 「發布」，「發布中…」，「故事發布成功」，「評論發布成功」

? 「完成」，「提交中…」，「故事發表成功」，「評論提交成功」