移動端產品文案設計規範的3個層次

提及「設計規範」，我們通常會想到的是UI規範、交互規範。

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

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

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

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

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

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

注① 鑒於工作中的案例不便討論，專門為設計交流做的一個概念方案，背景見「一站：提起一個地鐵站時，你會想起什麼？」。

目錄：文案設計規範的三個層次

1、一致性規範：辭彙一致、句式一致、行動點與目的頁面標題一致、時間表達規範、數字一致性規範、標點一致性規範

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

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

1. 一致性規範

1.1 辭彙一致

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

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

A. 量詞

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

?? 「22 篇故事」

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

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

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

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

B. 名詞

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

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

C. 動詞

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

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

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

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

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

對「已經發布了的內容」的陳述，用「發布了」自然不算錯。但根據平台調性的不同，可以有很多比冷冰冰的「發布了」更有溫度感的選擇，例如我在規範中選擇的「寫下了」，一方面與「故事」更搭調，一方面也能同時適用於Timeline和用戶數據展示等多個場景。

?? 「寫下了故事」，「寫下了 2 篇故事」

? 「發布了故事」，「發表了 2 篇故事」

D. 其他辭彙一致性規範示例

• 「評論了 Qinsman 的故事」，而不是「回復了 Qinsman 的故事」、「評價了 Qinsman 的故事」
• 「開往長湴」，而不是「去往長湴」、「開向長湴」
• 「點贊」，而不是「喜歡」
• 「TA」，而不是「他」或「她」（這是考慮到產品的場景並沒有強化用戶性別認知的需求，且需要考慮到用戶設置性別保密的情況。相反，如果是一款主打異性陌生人社交的產品，那麼顯式地告知用戶性別的意義就大了很多）
• 「車站」，而不是「地鐵站」、「站點」（有個例外是「站點列表」頁，因為需要強調List中的每個站在「車站」這一統稱下的個體性，因此僅在此頁面使用「站點」）
• 「專題」，而不是「話題」、「主題」
• 「故事發布成功」，而不是「故事發布完成」
• 「互相關注」，而不是「相互關注」

這裡看一些其他APP中的例子。

抖音中出現了「贊」和「喜歡」兩個近似概念的混用，給別人點「??」，在自己的主頁顯示的是「喜歡」，而被別人點「??」，顯示的則是「獲贊」。網易雲音樂中，兩個並列的Tab「發動態」和「發布視頻」，一個動詞是「發」一個是「發布」。

我不太清楚這兩組辭彙混用的背後是否確實有本質的區別（只是作為用戶沒有get到？），抑或僅僅是文案上的差別。

但作為用戶角度，這樣的不一致讓我的理解成本直接double了。2個辭彙對用戶而言是2個不同的概念，尤其是很多APP中本身「贊」和「喜歡」本身就是兩個完全不同性質的功能，因此我在第一次使用時會試圖猜測這兩者之間的區別在哪。

下面這個例子更誇張一點。電信營業廳APP里，在4個一級Tab中都要求用戶登錄，但4個Tab分別用了4種不同的提示文案「請登錄~」（注意還有個小尾巴）、「立即登錄」、「登錄」、「馬上登錄」。

1.2 句式一致

一站的正常流界面中涉及句法的規範問題較少，主要出現在各類中間態和異常流的提示語中。

• 同類提示語保持一致，避免每個地方寫的句子都完全不一樣，最終導致表達同樣含義的提示語在整個產品中變得五花八門。

?? 「你已經輸入了故事內容，確定放棄並返回嗎？」與「你已經輸入了評論內容，確定放棄並返回嗎？」句式一致

? 「你已經輸入了故事內容，確定放棄並返回嗎？」混用「確定放棄已輸入的評論並返回嗎？」

• 語序一致：「圖片上傳失敗」、「故事發布失敗」保持一致的「名+動+狀」結構，避免混用「動+名+狀」之類的其他語序，如「上傳圖片失敗」、「發布故事失敗」。

?? 「圖片上傳失敗」與「故事發布失敗」句式一致

? 「圖片上傳失敗」混用「發布故事失敗」

其他產品中，在正常流界面中也需要注意語序一致。比如不要一會寫「流量充值」一會寫「充值流量」。例子：

建行APP的「全部投資理財產品」頁，對所有同時涉及動詞和名詞的入口文案而言，幾乎都採用的是「名+動」，如「資金投資」、「債券投資」、「黃金積存」、「外匯買賣」，唯有「代理貴金屬」是「動+名」，類似的片語最好還是做好句式一致。

1.3 行動點與目的頁面標題一致

這一點比較容易理解，但在頁面設計中，改來改去很容易入口和跳轉頁面的文案就對不上號了。其中最常見的一種情況是遺漏前綴或者寫了多餘的前綴：

• 「編輯精選」跳轉到了「精選」
• 「我的動態」跳轉到了「動態」
• 「關於一站」跳轉到了「關於我們」
• 「設置」跳轉到了「系統設置」

豆瓣首頁的「豆瓣日曆」點擊後跳轉到的頁面標題卻是「豆瓣市集」，直到看到下面的新品首發才能明白「豆瓣日曆」是正在出售的新品中的一種，然而豆瓣市集里明明還同時出售其他很多商品，這個入口名稱的設置很容易讓用戶一頭霧水。

當然，由於入口字數受限，因而不得不縮減字數表達的情況是個例外，在沒有其他更好辦法的情況下也只能接受。

1.4 時間表達規範

內容發布時間的表達上，按照所處場景本身是否有時間屬性，需要分成兩個大的類型進行考慮。

方案A. 全部採用絕對時間

適用情形：普通內容List、內容末端節點

在普通內容List中，內容以熱度、運營策略或其他邏輯決定排序，本身沒有時間相關的屬性，此時發布時間沒有必要也不合適用「X小時前」這樣的相對時間進行表達。例如首頁本周熱門、編輯精選、車站詳情頁的故事List、熱門評價區等。

同時，在內容瀏覽鏈路的末端節點（如內容詳情頁和對話氣泡列表），需要保證所有關於內容的信息不能出現缺失，因此在這裡需要具體地告訴用戶這篇內容發布的絕對時間。

在這兩種情況下，用絕對時間表達更加合適：

方案B. 相對時間+絕對時間

適用情形：Timeline、消息列表等

在Timeline、消息列表等本身包含了時間邏輯（通常是默認倒序）的列表中，可以在近期內按相對時間表達，向用戶傳達更直觀的時間概念，減輕用戶對時間的思考負荷。一站中典型的例子如我的收藏、我的關注Feeds、我的動態、最新評價區等。

至於「近期」到底以什麼界線劃分，沒有絕對的對與錯，按產品實際需要制定規範就可以。常見的劃分界線是昨天、前天和一星期前。

對上述類型的時間信息，近期內採用相對時間表達，更早的則依舊採用絕對時間表達：

注意，月、日為1位數字時，前方不補0；小時、分鐘為1位數字時，前方補0湊齊2位。

此外有一個特殊情況。以車站故事的「最熱/最新」兩個Tab為例，那麼雖然「最新」理論上符合基於車站維度聚合、按時間倒序的內容流，應該採用方案B。但為了保證同一信息結構下的兩個Tab中時間呈現格式一致，格式上仍與「最熱」一同採用方案A。

1.5 數字一致性規範

涉及數字的表達統一使用阿拉伯數字，這點在設計過程中一般不會出錯，但數字是1的時候偶爾可能會習慣性地寫成「一」，如地鐵線路表達為「1號線」而不是「一號線」；新評論提醒的Push文案是「您的故事收到了1條新的評論」，而不是「您的故事收到了一條新的評論」。

?? 「1號線」，「您的故事收到了1條新的評論」

? 「一號線」，「您的故事收到了一條新的評論」

但一站中存在一些例外情況，如我的故事中的時間戳、專題卷數等需要突出時間痕迹、歷史感的場景下，仍用漢字數字表達。因此，數字格式的規範要根據產品實際需要，明確特殊用例。

此外，數量信息前後有漢字時需要加空格，讓寫死的文本欄位和變數欄位的區隔更清晰。注意像「7號線」等不表達數量信息的阿拉伯數字無需補加空格。此外，系統Push中的數量（如「你的故事收到了3條新的評論」）也不需要補加空格，因為Push只是一串文本，不需要考慮作為界面元素呈現時的清晰性。

?? 「寫下了 4 篇故事」

? 「寫下了4篇故事」

1.6 標點一致性規範

• 地鐵線路或地鐵站前方需要註明城市時：由居中點號「 · 」區隔，注意不是小數點，前後各有1個空格。例：「廣州 · 4號線」，「重慶 · 楊家坪」。
• 換乘站的所屬線路表達：由「/」區隔，前後無空格。例：「4號線/7號線」。
• 括弧規範：統一使用英文半形括弧，前方或後方有漢字時，補充1個空格間隔。例：「故事 (1292篇)」。
• 超長截斷：採用半個省略號「…」（1個全形字元），而不是整個省略號「……」（2個全形字元）或「...」（3個半形英文小數點）。
• 不使用句號等標點的情況：頁面主標題與副標題、輸入提示符、輸入框下方或輸入框中的提示文字、Toast中、彈窗或Actionsheet的選項、按鈕中。確有必要需要使用逗號和問號時除外。

這裡看兩個我們常用APP里的例子。

豆瓣在編輯個人主頁的生日設置中，貼心地告訴用戶生日設置並不會被用於個性化推薦，但這類說明文案是沒有必要加句號的。

再看看百度地圖的評分彈窗，這裡且不論沒用幾次就彈出來要求用戶評分的彈窗是否合理，就那3個碩大的感嘆號已經足夠讓很多用戶心驚肉跳一下了。

2.準確性規範

2.1 用詞準確

這一點應該是文案的基本要求，用詞出現不準確、不符合用戶習慣的現象，容易增加用戶的理解成本，給用戶留下不專業的印象。

舉個簡單的例子，簡訊驗證登錄是現在移動端登錄的標配途徑，用戶對「驗證碼」的概念已經建立了相當牢固的心智，99%的產品中也都遵循了這一慣例叫法，而偏偏有一些APP里會沿用自己獨特的術語，比如電信營業廳的登錄頁中就叫「隨機碼」（這裡就不說「獲取隨機碼」和「請輸入隨機密碼」不一致的問題了）。

這個叫法能不能說得通？當然能，驗證碼當然是隨機的數字組合。但能說得通並不代表用詞準確，準確與否是由國內用戶的慣有認知決定的。

再比如，喜馬拉雅APP在編輯資料時，「簡介」是一個輸入項，提示「未填寫」是正確的，而「生日」和「地區」都是選擇器，不應該提示「未填寫」而應該是「未選擇」。

此外，在toB的企業管理應用、金融支付相關、行業背景專業性較強的應用中，更需要注意一些行業術語的使用準確。這點在之前做過的B端企業應用、項目管理平台里感觸頗多，不過因為行業背景離日常生活比較遠，這裡就不做過多舉例了。

2.2 不累贅

在文案複查中留意是否存在冗餘的文字，結合頁面場景和上下文已經完全能理解的信息無需重複表達，只會徒增用戶的信息認知負擔和理解成本。

例如在「一站」的故事發布頁面中，車站和所屬專題的選擇提示文案，就不用再強調其與故事之間邏輯從屬關係。右上角的「發布」按鈕，也不用強調是「發布故事」。

?? 「請選擇」

? 「請選擇故事對應的車站」；「請選擇故事所屬的專題」

在專題首頁中，在List內容顯然全都是「故事」的前提下，3個Tab也無需再次強調「故事」的字眼。

?? 「最新」/「最熱」/「精選」

? 「最熱故事」/「最新故事」/「精選故事」

下面看看這兩個閱讀壓力非常大的頁面。

懂球帝的掃一掃界面中，在掃碼框上方寫了兩行文案「打開網頁版懂球帝登錄頁面，掃描二維碼登錄」和「掃描懂球號二維碼，關注懂球號」，介紹了懂球帝里掃碼的2個場景。

而實際上用戶之所以在懂球帝打開了掃一掃，絕大多數情況下都是已經處於這2種場景中的其中一種。絕大多數用戶進入掃一掃，並不是閑的沒事，進來後看到「哦原來這兩個地方可以用到」，然後去找碼掃。而是先有掃碼場景，才會進入掃碼功能。

那麼在掃一掃界面，又有什麼必要再告訴用戶「啊哈，知道，你一定是從這兩個地方來的」呢？只能徒增用戶的閱讀負荷。有興趣的朋友可以去看一下其他APP的掃碼頁面，提示文案一般只有下方那句「將二維碼放入框內即可自動掃描」，這才是不熟悉操作的用戶在這個界面可能需要看到的文案。

同花順的模擬炒股大賽報名頁更誇張一點，在每個輸入框的佔位提示符中重複了「請輸入您的」這5個字，一下子讓整個頁面充滿壓迫感。同時，主行動按鈕文案也略顯冗餘，「報名」兩個字足夠說清的事情，卻用了「提交資料 報名參賽」8個大字。

2.3 不缺失

對行動點文案而言，要做到將行動點背後的關鍵信息準確、直接地讓用戶知曉。

例如，在搜索欄的提示佔位符中清晰地告知用戶可以搜索的數據類型。

?? 「搜索車站 故事 用戶等」

? 「搜一搜」、「點擊進行搜索」、「點擊開始搜索」

異常流報錯時，應當告訴用戶可行的解決方案，或產品為用戶做了哪些挽救措施。

例如，A用戶發布了一條故事，他的好友B用戶看到後，用幾分鐘寫了評論，但點擊發布之前A用戶已經刪了這條故事。那麼此時應該在Toast中告訴B用戶評論發布失敗的具體原因。

Toast：

?? 「評論發布失敗，該故事已被發布者刪除，內容已保存至系統剪貼板」

? 「評論發布失敗」

空態中，也需要告訴用戶下一步可以採取的行動，而不是單純地告訴用戶這裡為空。這實際上不是一個文案問題，而是一個產品和交互的問題。

空態的處理做得好的產品，很容易讓用戶對平台的「體貼」產生好感的同時遵循文案的引導，去執行對產品有利的操作，達成業務目標與體驗的雙贏。例如關注列表的空態就非常適合引導拉新。

?? 「關注可能感興趣的人」+「或者 我要邀請我的好友」

? 「還什麼都沒有哦」、「這裡空空如也」、「還沒有關注任何用戶」

2.4 不模糊

避免「可能」、「大概」、「也許」，會為用戶憑添一層「到底是不是」的判斷，除非在一些異常流中技術上確實無法判斷問題所在。

3. 更高的要求——懂用戶

3.1 從用戶視角描述價值

在行動點相關的文案中，以用戶的視角描述「你」能通過此操作達到的目的，為用戶創造合適的動機，幫其排除擔憂和解決障礙，都能更好地撬動用戶去執行，而不是從「我們」（產品團隊）的角度強迫用戶接受某一設定。

以一站在「設置」中的綁定郵箱和消息推送開關的說明文案為例：

• 創造動機、排除擔憂：「綁定郵箱可以讓你快速找回或者重置密碼，一站不會向你發送任何廣告或營銷郵件」
• 解決障礙：「消息推送的開啟和關閉，需要前往iPhone系統設置的「通知」中進行設置」

在這方面做得非常棒的一個APP就是Keep，其體驗路徑的各個環節都能感受到產品在文案上的用心程度。這裡只舉一個註冊流程的例子。在註冊完成後，Keep會希望用戶完善一些基本資料，對產品來說有利於制訂個性化的用戶分層策略，也是很有價值的數據沉澱。在這個流程中，Keep充分通過文案向用戶傳達了完善資料對他的價值（找到合適的訓練、實現健身目標、依據身高設計訓練內容等…），並排除了用戶對隱私數據的擔憂（放心，Keep不會泄露你的資料）。

反例是Airbnb（是的，Airbnb很罕見的出現在了反例里），同樣是希望用戶完善資料，「我的」頁的資料完善進度條下方的文案是這麼寫的：「我們要求每一位愛彼迎用戶在旅行或出租之前提供一些具體信息，現在就來完善這一步吧」。

我不清楚一個以體驗優秀著稱的產品里怎麼會出現這樣一句文案，也許是直譯導致的問題。

改成「在旅行或出租之前提供一些具體信息，可以在愛彼迎獲得更好的服務與體驗」，是不是同樣的意思，聽起來舒服多了？

3.2 正確使用人稱代詞

• 一站的人稱代詞規範：默認使用「你」，同時，在語境合理、語法通順的情況下儘可能使用「我」代替「你」。

文案中常用的人稱代詞是第一人稱「我」和第二人稱「你」、「您」。第二人稱的泛用性比較好，可以適合絕大多數的語境和句式。但在合理的情況下，可以儘可能多地嘗試以第一人稱「我」為主體進行描述，相比第二人稱，更能讓用戶感受到自己在產品體驗過程中的主導地位。

至於第二人稱中用「你」還是「您」，並沒有絕對的對與錯。對年輕群體為主的社交、電商、娛樂型的APP，用「你」更合適、對用戶更具親和力和自由平等的感覺，「您」反而讓用戶感到與產品之間有一種莫名的距離感。反過來，銀行、金融服務產品中，其線下場景「賓至如歸」的態度在線上也需要體現，此時用「您」更加合適，面向企業用戶的B端產品也同理。

第一與第二人稱沒有絕對的優劣之分，「你」和「您」也沒有絕對的對與錯，但至少需要在APP級進行統一，並不意味著可以隨意混用。我們看看移動營業廳APP中的兩個例子：

左圖是服務頁，在服務項的副標題中，同屏出現了「修改您的寬頻密碼」和「管理我的發票抬頭」，如果說兩個混用的還算常見，再看看三個一起混用的場面有多混亂——右圖的移動體檢頁面，共出現了3個涉及人稱代詞的文案：「關注您每一分權益」、「套餐合不合適，我來告訴你」、「今天，我4G了嗎？」。

那啥，我到底是「我」還是「你」還是「您」？一會「你」一會「您」，你到底是尊重我還是不尊重我……

3.3 讓用戶聽得懂

根據用戶群體的不同，在文案中盡量使用他們能聽得懂的辭彙。例如，在社交、娛樂、電商、出行等用戶群體較廣的應用中，用語應當儘可能簡單、直白。避免使用一些設計師或者產品團隊內部自己明白、而用戶聽起來一頭霧水的詞語。

就舉一個最簡單的例子，12306買票時，這個「受讓人」和下面那句溫馨的繞口令，請問有誰能在事先不了解受讓人是什麼意思的情況下看懂么？

此外，如果用戶的行業屬性很強，就要吃透他們的語言習慣。

例如，在一個工程項目管理應用中，「專業負責人」是工程業內用戶非常熟悉的一個專有名詞，代表暖通、電氣、給排水等各個專業的牽頭人，這時用互聯網行業的「主管」之類的詞語就貽笑大方了。

同樣，在一個專業理財產品里，一些金融術語該直接使用時就直接使用，寫得太白話反而影響專業性。

3.4 告訴用戶Why not

讓用戶始終有選擇的權利，讓他在體驗中感覺到可控性是非常重要的。以系統設置為例，盡量保證出現在設置中的選項都是允許用戶選擇的。而如確有必要不允許用戶選擇時，應該告訴用戶其背後的原因。

例如，知乎不允許用戶關閉已關注話題的推送，Airbnb不允許用戶關閉郵箱推送。而相比之下，Airbnb就比知乎解釋地清楚很多。

結語

文案設計規範的三個層次中，一致性是文案質量的基石，準確性是提升質量的關鍵，懂用戶則是更高的要求。

這裡舉的一些反例可能整體看來都是非常優秀的產品，比如Airbnb和網易雲音樂，可能有朋友會覺得是不是太吹毛求疵了？好像例子中的這些問題對體驗也無傷大雅，也不影響產品全局的評價和口碑。

說實話，如果作為一般用戶，可能確實不需要留意到這些細節，大概率對核心體驗也沒有特別大的影響。

但作為一個具有職業敏感性的產品設計師來說，我覺得對細節的追求還是要有的。換位思考一下，在自己的產品中，能通過規範和走查避免的問題，為什麼一定要用「無傷大雅」去開脫呢？

從項目的責任心上說，文案設計是設計師和運營要各自從用戶體驗和業務指標上共同把關的。而從設計師個人的成長來講，每多留心一次文案細節，未來出類似方案時就可以信手拈來地給出高質量的文案，對自己在項目中培養更規範、更嚴謹的設計習慣也大有裨益。

- END -

歡迎關注我的公眾號「西市饅頭鋪子」