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

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

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

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

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

因此，一直希望通過一篇文章，對移動端產(chǎn)品的文案設(shè)計規(guī)范進行一次適用面更廣的梳理和總結(jié)??一份文案設(shè)計規(guī)范需要包括哪些層次的內(nèi)容？有哪些原則需要在規(guī)范中寫明？

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

文章內(nèi)容：文案設(shè)計規(guī)范的三個層次

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

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

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

一. 一致性規(guī)范

1. 詞匯一致

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

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

量詞

故事的量詞，統(tǒng)一用「篇」，而不是「段」、「條」。

△ 一站 ? 故事的量詞統(tǒng)一用「篇」

?? 「22 篇故事」

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

搜索結(jié)果的量詞，統(tǒng)一用「條」，而不是「個」。

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

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

名詞

名詞的一致化對產(chǎn)品統(tǒng)一心智的形成非常重要，尤其是一個產(chǎn)品中最核心的概念定義。

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

動詞

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

以內(nèi)容發(fā)布為例，是表達「正在發(fā)出」的行為，還是對「已經(jīng)發(fā)布了的內(nèi)容」的陳述？

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

△ 一站 ? 表示正在發(fā)出的動作統(tǒng)一用「發(fā)布」

?? 「發(fā)布」，「發(fā)布中…」，「故事發(fā)布成功」，「評論發(fā)布成功」

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

對「已經(jīng)發(fā)布了的內(nèi)容」的陳述，用「發(fā)布了」自然不算錯。但根據(jù)平臺調(diào)性的不同，可以有很多比冷冰冰的「發(fā)布了」更有溫度感的選擇，例如我在規(guī)范中選擇的「寫下了」，一方面與「故事」更搭調(diào)，一方面也能同時適用于Timeline和用戶數(shù)據(jù)展示等多個場景。

△ 一站 ? 表示已發(fā)布的內(nèi)容統(tǒng)一用「寫下了」

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

? 「發(fā)布了故事」，「發(fā)表了 2 篇故事」

其他詞匯一致性規(guī)范示例

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

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

△ 左：抖音 右：網(wǎng)易云音樂

抖音中出現(xiàn)了「贊」和「喜歡」兩個近似概念的混用，給別人點「??」，在自己的主頁顯示的是「喜歡」，而被別人點「??」，顯示的則是「獲贊」。網(wǎng)易云音樂中，兩個并列的Tab「發(fā)動態(tài)」和「發(fā)布視頻」，一個動詞是「發(fā)」一個是「發(fā)布」。

我不太清楚這兩組詞匯混用的背后是否確實有本質(zhì)的區(qū)別，亦或僅僅是文案上的差別。

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

下面這個例子更夸張一點。電信營業(yè)廳APP里，在4個一級Tab中都要求用戶登錄，但4個Tab分別用了4種不同的提示文案「請登錄~」、「立即登錄」、「登錄」、「馬上登錄」。

△ 電信營業(yè)廳：五花八門的登錄提示語

2. 句式一致

一站的正常流界面中涉及句法的規(guī)范問題較少，主要出現(xiàn)在各類中間態(tài)和異常流的提示語中。

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

?? 「你已經(jīng)輸入了故事內(nèi)容，確定放棄并返回嗎？」與「你已經(jīng)輸入了評論內(nèi)容，確定放棄并返回嗎？」句式一致

? 「你已經(jīng)輸入了故事內(nèi)容，確定放棄并返回嗎？」混用「確定放棄已輸入的評論并返回嗎？」

語序一致：「圖片上傳失敗」、「故事發(fā)布失敗」保持一致的「名+動+狀」結(jié)構(gòu)，避免混用「動+名+狀」之類的其他語序，如「上傳圖片失敗」、「發(fā)布故事失敗」。

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

? 「圖片上傳失敗」混用「發(fā)布故事失敗」

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

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

△ 建行「全部投資理財產(chǎn)品」頁的入口文案

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

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

「編輯精選」跳轉(zhuǎn)到了「精選」 「我的動態(tài)」跳轉(zhuǎn)到了「動態(tài)」 「關(guān)于一站」跳轉(zhuǎn)到了「關(guān)于我們」 「設(shè)置」跳轉(zhuǎn)到了「系統(tǒng)設(shè)置」

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

△ 豆瓣首頁「豆瓣日歷」的跳轉(zhuǎn)去向是「豆瓣市集」

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

4. 時間表達規(guī)范

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

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

適用情形：普通內(nèi)容List、內(nèi)容末端節(jié)點。

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

同時，在內(nèi)容瀏覽鏈路的末端節(jié)點（如內(nèi)容詳情頁和對話氣泡列表），需要保證所有關(guān)于內(nèi)容的信息不能出現(xiàn)缺失，因此在這里需要具體的告訴用戶這篇內(nèi)容發(fā)布的絕對時間。

△ 一站 ? 左：普通內(nèi)容List 右：內(nèi)容詳情頁

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

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

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

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

至于「近期」到底以什么界線劃分，沒有絕對的對與錯，按產(chǎn)品實際需要制定規(guī)范就可以。常見的劃分界線是昨天、前天和一星期前。

△ 一站 ? 左：我的動態(tài) 右：消息

對上述類型的時間信息，近期內(nèi)采用相對時間表達，更早的則依舊采用絕對時間表達：

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

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

△ 一站 ? 車站故事的兩個Tab

5. 數(shù)字一致性規(guī)范

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

△ 一站 ? 統(tǒng)一用阿拉伯數(shù)字表達

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

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

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

△ 一站 ? 特殊情況確有需要時，仍用漢字表達

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

△ 一站 ? 數(shù)量前后有漢字時增加空格

?? 「寫下了 4 篇故事」

? 「寫下了4篇故事」

6. 標點一致性規(guī)范

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

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

△ 左：豆瓣個人設(shè)置頁 右：百度地圖的評分彈窗

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

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

二. 準確性規(guī)范

1. 用詞準確

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

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

△ 電信營業(yè)廳APP

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

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

△ 喜馬拉雅 ? 編輯資料頁

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

2. 不累贅

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

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

△ 一站 ? 故事發(fā)布

?? 「請選擇」

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

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

△ 一站 ? 專題首頁

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

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

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

△ 左：懂球帝 右：同花順

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

而實際上用戶之所以在懂球帝打開了掃一掃，絕大多數(shù)情況下都是已經(jīng)處于這2種場景中的其中一種。絕大多數(shù)用戶進入掃一掃，并不是閑的沒事，進來后看到“哦，原來這兩個地方可以用到”，然后去找碼掃。而是先有掃碼場景，才會進入掃碼功能。

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

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

3. 不缺失

對行動點文案而言，要做到將行動點背后的關(guān)鍵信息準確、直接的讓用戶知曉。

例如，在搜索欄的提示占位符中清晰的告知用戶可以搜索的數(shù)據(jù)類型。

△ 一站 ? 搜索提示文案

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

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

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

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

Toast：

?? 「評論發(fā)布失敗，該故事已被發(fā)布者刪除，內(nèi)容已保存至系統(tǒng)剪貼板」

? 「評論發(fā)布失敗」

空態(tài)中，也需要告訴用戶下一步可以采取的行動，而不是單純的告訴用戶這里為空。這實際上不是一個文案問題，而是一個產(chǎn)品和交互的問題。

空態(tài)的處理做得好的產(chǎn)品，很容易讓用戶對平臺的「體貼」產(chǎn)生好感度，同時遵循文案的引導，去執(zhí)行對產(chǎn)品有利的操作，達成業(yè)務目標與體驗的雙贏。例如關(guān)注列表的空態(tài)就非常適合引導拉新。

△ 一站 ? 關(guān)注的人（空態(tài)）

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

? 「還什么都沒有哦」、「這里空空如也」、「還沒有關(guān)注任何用戶」

4. 不模糊

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

三. 更高的要求??懂用戶

1. 從用戶視角描述價值

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

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

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

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

△ Keep

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

△ Airbnb ? 「我的」

我不清楚一個以體驗優(yōu)秀著稱的產(chǎn)品里怎么會出現(xiàn)這樣一句文案，也許是直譯導致的問題。

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

2. 正確使用人稱代詞

一站的人稱代詞規(guī)范：默認使用「你」，同時，在語境合理、語法通順的情況下盡可能使用「我」代替「你」。
文案中常用的人稱代詞是第一人稱「我」和第二人稱「你」、「您」。第二人稱的泛用性比較好，可以適合絕大多數(shù)的語境和句式。但在合理的情況下，可以盡可能多的嘗試以第一人稱「我」為主體進行描述，相比第二人稱，更能讓用戶感受到自己在產(chǎn)品體驗過程中的主導地位。

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

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

△ 移動營業(yè)廳

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

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

3. 讓用戶聽得懂

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

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

△ 國民級APP??12306

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

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

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

4. 告訴用戶Why not

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

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

△ 無法選擇時告訴用戶Why not 左：Airbnb 右：知乎

結(jié)語

文案設(shè)計規(guī)范的三個層次中，一致性是文案質(zhì)量的基石，準確性是提升質(zhì)量的關(guān)鍵，懂用戶則是更高的要求。

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

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

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

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

作者：西市饅頭鋪子，微信公眾號：西市饅頭鋪子。

標簽： 電商 互聯(lián)網(wǎng) 互聯(lián)網(wǎng)行業(yè) 金融 企業(yè) 搜索 問題 行業(yè) 選擇 隱私 用戶

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。