從實際案例出發,說說交互文案設計的幾個原則

3 評論 13075 瀏覽 144 收藏 14 分鐘

想必大家都見過下圖所示的著名的“交互文案”反例吧?

圖1:著名反例

如果文案寫成這樣,無論設計師在文案出現方式、時機等方面再怎么優化,這也不可能成為一個合格的設計。因為“看起來重復、讀起來繞口、理解起來更是云里霧里”的文案很難讓用戶獲得良好的閱讀體驗和使用體驗。

可見,文案本身是交互設計不可忽視的一部分。而不像許多交互設計部分受產品需求、技術現狀等的限制,交互文案是在交互設計師的可控范圍內的,只要你愿意,你總是可以寫出“趨近完美”的交互文案。

理解需求

交互設計師寫文案,好比是翻譯家將英語(功能語言)翻譯成中文(用戶語言)。比如產品經理可能會這么描述一個需求:It rains cats and dogs。要翻譯這句話,首先要透過cats and dogs這個俗語(產品經理的描述習慣)去理解這句話的含義,即需要交互設計師理解需求。

圖2:翻譯需求

以上圖為例,產品經理一開始在PRD中將這個分頁標題定為“興趣”;然而由需求本身可知,這個分頁包含的是推薦的優質版塊,并不是由用戶選擇自己“感興趣”的版塊構成的,所以談不上“興趣”,經過交互設計后,該分頁標題最終定為“頻道”。

下面的設計,卻是理解需求后的“直譯”。

圖3:意譯需求

產品經理要求在編輯直播間推薦頁提供“該推薦是否顯示到大廳”的設置,優化前完全按照需求的表述來進行設計,不能說有錯,但不夠明確。

深入了解需求,我們發現,這里的設置其實是對當前推薦類型的選擇(選擇否時,推薦為一般推薦,不顯示至大廳)。優化后,直接將選擇“是”和“否”的結果明確寫出。

理解了需求,才能知道要“寫什么”以及“寫成什么意思”,才能把“It rains cats and dogs.”翻譯成“天上下了很大的雨。”而不是“天上下起了貓貓狗狗?!?/p>

基本原則

用語確切

文案作為被閱讀的對象,需要被用戶理解。

我在使用網上銀行找回用戶名的時候,收到這么一個提示:

圖4:網銀文案

主提示句明顯是一個病句,就算進行修正我也無法理解,無奈只能大膽猜測我的銀行卡是不是沒有開通網銀。文案撰寫時如果沒有準確使用詞匯、語法來表述其含義,用戶就無法理解,甚至容易產生歧義讓用戶誤解。

不過,僅僅“用語”準確還不夠。

我曾經設計了這樣的分享文案“給大家安利[用戶昵稱]的直播……”?!鞍怖币辉~在網絡用語發展過程中,逐步演變為比“推薦”更具情感化的表述。使用“安利”一詞在達意上自然沒有問題,而且更顯詼諧。不料,我卻發現有不少用戶反饋“是不是寫錯字了?”“安利什么意思啊?”這時,再拿“安利”對一些用戶進行隨機調研時,我才發現原來太多知道“土豪”的用戶都不知道“安利”。這說明用語還要恰當。

這就要求設計師根據用戶特征和習慣來撰寫文案,做到“用語確切”,文案才能被用戶準確理解。

全局一致

由于漢語博大精深,同一含義的確切表述可能有許多種。為了符合用戶的心理預期,同一產品的同一功能、含義的表述必須一致。

下圖設計中,“校驗碼”“驗證碼”甚至“動態碼”等表述都可以用在這里。然而同一功能、同一頁面上卻用了兩種表述,就會讓用戶迷惑“到底是驗證碼還是動態碼”?

圖5:驗證文案

同一產品中,同一流程或同類功能,如果短語結構、句式等可以一致,那么也應該遵循一致性原則。

圖6:流程文案

一個流程中的三步文案分別使用了動名、名動、動名形三種短語結構,感覺有些雜亂,不如統一使用“動名”或“動名、動形”的結構來的舒服。

此外,同類或相似功能的文案敘述視角也應該一致。

圖7:會員介紹文案

同類功能描述差異性的文案,卻分別從產品和用戶的兩個角度去描述,也給人以混亂的感覺。

這需要設計師從實際需求出發,多維度地去考慮一致性,以給用戶安全感和舒適感。

情感關懷

滿足用語確切、全局一致的文案,達到了文案的基本要求。這樣就夠了嗎?

在“網銀文案”一例中,假設我們將文案按我猜測的意思優化為“請使用已開通網銀的賬戶進行操作”,那么某些有且僅有一張未開通網銀的銀行卡的用戶如何使用另一張并不存在的卡呢?某些就想對該賬戶進行操作的用戶又該怎么辦呢?文案應該以當前操作為出發點去描述問題,才能幫用戶解惑。因此,本案例中優化為“本賬戶暫未開通網銀,請前往柜臺開通”更明確合理。

當我點擊下圖設計中的“確定”時,彈出了“領取失敗”的文案,閱讀后能夠理解當前“失敗”的狀態,然而失敗原因是什么呢?我還能怎么做呢?這些都無法從交互文案中獲知,因此用戶會產生迷茫。文案應該描述失敗原因,比如“今日兌換結束,明天再來試試”“您的淘金幣余額不足”等等。

圖8:失敗文案

某次,我在登錄某手機銀行時,忽然彈出下圖中的彈框,我一下子懵了,什么地方出錯了?我的賬戶還安全嗎?等我顫抖地關掉彈框時,我發現我輸錯了驗證碼……用戶小小的失誤,卻鄭重地用彈框和語焉不詳外加如此多的感嘆號來提示,著實讓人受到驚嚇。(值得欣慰的是,某行已經優化了這個提示。)文案應該考慮用戶情緒,使用合理的語氣進行表述。

圖9:錯誤文案

在某些場景中,我們還可以考慮使用一些有趣的文案去打動用戶,賣賣萌、調調侃,讓用戶在閱讀時不那么枯燥,從而感受到一些趣味性。

總之,設計師需要懷著同理心去思考用戶的情感需求,將對用戶的情感關懷注入到交互文案中,才能提供更好的用戶體驗。

其他原則

功能文案控制字數

所謂功能文案,指產品界面上描述功能本身的文案,如導航、分頁、按鈕、表單、操作等。

對APP來說,由于界面空間限制,功能文案一般簡短;對WEB來說,則沒有那么嚴格的字數限制。但對多平臺產品來說,由于需要滿足一致性,所以WEB上的功能文案一般會向APP文案靠攏。

提示文案進行引導

所謂提示文案,指在特殊場景、狀態下,告知用戶狀態、引導用戶操作的文案,如表單缺省文案、狀態說明文案等。

表單缺省文案需要告訴用戶表單的輸入要求、限制等,以引導用戶正確輸入。

狀態說明文案則需要告知用戶目前所屬狀態,根據需要增加建議操作。若是出錯、操作失敗等狀態,則必須告訴用戶原因、提供解決方案。但對于復雜原因造成的出錯,如果“誠實”地告知用戶,反而會讓用戶迷茫,這時候不如說一個能夠為用戶所理解的原因,并且提供解決方案。

圖10:提示文案優化

反饋文案情感引導

所謂反饋文案,指在用戶某些操作、行為后系統反饋的文案,如表單校驗文案、操作反饋文案等。

反饋文案需要基于對用戶的情感關懷以及產品本身的功能推廣等等的考量,鼓勵積極、推薦的操作,不鼓勵消極的操作;恭喜成功的操作,不打擊失敗的操作。如“添加好友成功”“已刪除該好友”“恭喜您成功充值100元”“啊哦~充值遇到問題”等等。

首行文案注重隱私或便捷

所謂首行文案,特指郵件、短信列表和提醒時預覽出現的文案。

這類文案需要根據隱私、便捷性等產品特征考慮文案首行顯示的內容。比如記賬產品發送用戶月度記賬財報郵件,由于隱私性考慮,前幾行一定不能出現金額等敏感信息。而短信驗證碼文案,為了方便用戶在不切換界面的情況下輸入驗證碼,必須在優先寫出產品名稱、驗證碼的信息,以便讓用戶在收到短信提醒時就可以快速操作。

Don’t make me think

“Don’t make me think”原則除了運用在上述“意譯需求”的操作文案中外,最常運用在彈框操作文案中。為了防止誤操作,用戶在進行某些操作時,通常會讓用戶二次確認。而為了方便用戶進行確認操作,彈框按鈕的文案需要直接明確地寫出相應操作(此外按鈕還會使用彩色-主流程操作;線框-分支流程操作;紅色警示色-慎重操作來進行區別)。這樣,用戶甚至可以不需要仔細閱讀和思考,只要輕掃文案就可以快速做出選擇。

圖11:操作文案優化

重視整體閱讀體驗

前面舉例說了一些示例,除了寫好每一例文案外,我們還應該注重界面整體的閱讀體驗。比如整體界面不應該是重復的、冗余的,“驗證文案”一例中,就出現兩句差不多的文案,閱讀體驗就有所下降。

因此交互設計時,還需要綜合考慮所有文案,以整體提供良好的閱讀體驗。

結語

想寫好交互文案的方法、原則還有很多,本文僅從我過去看到的案例、獲得的收獲出發撰寫。歡迎大家交流:)

 

本文由 @小七isue 原創發布于人人都是產品經理。未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. ??

    來自北京 回復
  2. Don’t make me think中,你舉得例子確實是更好的體驗反饋方式,但是對『設計者』來說是災難。因為這些『設為默認ID』文案只能通過人肉維護,難免產生遺漏和錯別字,增大了系統的不確定性,這在多人合作和需求變更時尤為明顯。

    來自浙江 回復
    1. 頂樓上的看法,『設為默認ID』將可被通用的文案抽象成『確定』、『操作』等通用術語,集中進行調用和維護。雖然『用戶』體驗 -1 分,但是『設計者』體驗 +5 分。

      來自浙江 回復