一條提示信息的N種表現方式

6 評論 11477 瀏覽 117 收藏 24 分鐘

編輯導語:本篇文章聚焦在校驗規則及提示信息,幫助新手B端體驗設計師快速了解提示信息的觸發規則及注意事項,搭配復雜案例助力融會貫通。歡迎感興趣的小伙伴們一起閱讀分享。

業務性強,內容復雜度高是ToB產品的典型特征。當用戶需要在產品流程中錄入大量數據信息時,業務本身的復雜性會大大增加錄入成本

作為體驗設計師,通過系統引導性提示校驗性提示信息幫助用戶快速完成工作是我們的職責所在。下面我們一起來看看復雜的校驗性提示信息如何去做:

一、提示信息存在的必要性

提示信息是系統與用戶之間信息反饋的載體,告知用戶當前操作的可行性,減少操作損失,引導用戶進行。

提示信息是反饋組件的一部分,屬于反饋組件,但不包含所有的反饋組件。因為只有在錄入內容出現報錯、阻斷時才需要提示信息。

1. B端產品的校驗規則為什么復雜?

C端產品的提示信息除了提示以外還起到安撫用戶的作用,適當進行情感化的設計幫助留住用戶。

B端提示信息只有在必要時才會展示,能不要提示盡量不要提示,不要給用戶額外的“負擔”,提升工作效率和使用效率才是我們的目標。所以提示信息的設計需要謹慎,謹慎的事情必然伴隨一定的復雜性。

2. 常見的校驗規則

提示信息分為系統性提示和校驗性提示,我們這次只針對校驗性提示進行講解。

提示信息跟隨校驗結果出現,本質上也是一種信息反饋。

3. 基本原則

信息校驗一般分為前端校驗和后端校驗。舉個例子,前端校驗就像我們登錄郵箱,輸入了密碼,主觀判斷輸入正確,但是提交后發現后輸入錯誤。如果這里系統強制要求是12位數密碼,你只輸入了11位,那么這里提示:“請輸入12位數的登錄密碼”就屬于前端校驗,而提交后提示的:“賬號或密碼錯誤”是屬于后端校驗。

前端校驗常見的有:字段校驗、必填項校驗、完成度校驗、產品業務數據校驗等等。比如電話號碼少填寫一位數、必填內容未完成、一共三個步驟只填寫了兩步。

當產品業務數據校驗放在前端去做時,多半是因為校驗內容過多,想給后端校驗跑數據時減輕壓力,將一些簡單的業務功能性校驗放在前端去做。但是這里要注意,要跟前端工程師溝通好,并不是所有內容都適合放在前端進行校驗的。

后端校驗涉及到用戶信息確認、業務數據確認等需要跑通數據庫的校驗內容

常見的比如保險理賠中我們報案提交理賠的時間,不能早于事故發生的日期,這方面的數據存儲于后端數據庫,所以需要后端調取數據進行核實才能出校驗結果。

4. 提示信息的出現順序

校驗步驟的基本規則是先前端校驗,再后端校驗?;A內容完成后,再進行復雜信息的校驗。

校驗出現以下3種情況,才會對應展示提示信息:

(1)Error錯誤類

具有強打斷性,如果錯誤內容未做修改,是不能繼續提交進行下一階段的,所以Error類是最先進行報錯并提示的。

(2)提示無需確認

不會被強制打斷,但是會作為普通提示告知用戶。比如我們在校驗用戶身份信息時,會根據用戶提供的證件類型來判斷校驗的內容,若用戶未填寫,需要提示用戶必須先錄入證件信息才能編輯其他內容。

(3)提示需要確認

具有打斷性,這時的提示信息一定要給出用戶明確提示,以及提交保存或確認后影響的內容。因為強打斷,所以需謹慎。但是也不用畏手畏腳,該提示的必須提示,掌握好這個分寸。

前端校驗與后端校驗提示信息出現的順序基本一致:Error錯誤類 – 提示需確認&提示無需確認,只是前端無法調用復雜數據只能做簡單的字段校驗,而后端校驗涉及到的是數據庫保存的內容信息。

二、校驗提示的三類情況及表現形式

校驗后的提示信息一般伴隨用戶錄入信息頁面時出現(交互三原則之一:操作后有反饋),錄入過程又分為錄入中校驗和階段提交校驗;提示信息也分為需要確認和無需確認兩種情況。下面是綜合兩者進行的三種形式分類:

1. 錄入過程中,提示無需確認

當信息錄入中,有些小錯誤給用戶簡單的提示即可。比如“需要錄入身份證信息,才能查看您的用戶數據”,這時候給一個全局提示,不需要用彈窗、氣泡卡片這種打斷性強的內容。

(1)提示無需確認使用的反饋組件

① 警告提示

基本定義和使用規則:展示需要關注的信息,適用于簡短的警告提示。有用戶操作觸發或系統觸發兩種情況。警告提示有四種樣式,帶有底色,顏色更能吸引人的注意力,所以警告提示的內容優先級一般高于全局提示。

為什么用:警告的信息的內容需要被用戶確認,它會以非模態的展現形式,始終展現,不會自動消失,用戶需要點擊才能關閉。(根據業務產品需求,也會出現3s自動消失的情況,根據情節而定)

② 全局提示

基本定義和使用規則:由用戶的操作觸發的“輕量級”全局反饋。默認3秒即消失

何時使用:用來提供成功、警告和錯誤等反饋信息,而且不會打斷用戶的操作。

顯示位置:頁面頂部居中

2. 錄入過程中,提示需確認

比如列表中的“刪除”按鈕,用戶有可能不小心點擊,這時候給一個氣泡卡片,二次確認即可。

比如用戶即將離開頁面,但修改內容未做保存時,給用戶二次確認,減少誤操作的損失。

需要確認的原因:減少用戶誤操作、操作聯動、影響用戶下一流程的內容。

(1)提示需確認常用的反饋組件

① 氣泡卡片

基本定義和使用規則:點擊后觸發,彈出氣泡式的確認框

何時使用:氣泡確認框是一種輕量的反饋方式,承載的內容也相對較少。主要用于二次確認操作。對比較為常規的對話框二次確認,氣泡確認框從形式上更輕量,干擾更小,控件的打開關閉方式也更為便捷。

顯示位置:跟隨內容展示,有12個方向供選擇

② 通知提醒框

基本定義和使用規則:用于向用戶反饋重要的警告提示和通知消息。

何時使用:一般用于系統級通知,需要吸引用戶關注但又不強制用戶去處理的場景。當消息出現時,用戶可以選擇繼續當前操作,也可以選擇處理當前消息。因為是系統級通知,所以顯示位置也不用跟隨操作,在指定的位置展示即可。

顯示位置:頁面右上角

③ 對話框(彈窗)

基本定義和類型:對話框是模態形式的浮層,在當前頁面打開后承載相關操作。因為會中斷用戶當前的任務流程,所以需要謹慎使用,一般用于快捷且不需要頻繁操作的任務,滿足用戶執行操作且不離開當前頁面。

對話框的類型有三種:功能對話框、確認對話框、消息提示對話框。

功能對話框:涉及到平臺內容的錄入,信息較為復雜,還會伴隨步驟和反饋等等。

今天我們主要講的是提示信息相關的反饋,也就是確認對話框、消息提示對話框這兩種。

何時使用:要求用戶立即響應、通知用戶緊急信息、確認用戶決定時使用。

顯示位置:頁面上下左右居中

④ 抽屜頁面

抽屜頁還能承載提示信息?

沒錯!有時會因為業務的復雜關聯性導致一個任務提交,觸發多種校驗提示。彈窗已經不能滿足我們內容承載,我們需要使用抽屜頁面來承載大量的提示信息,而且伴隨分類和不同的提示話術。最后的案例會具體講。

3. 階段性提交,提示需確認

提交成功,給一個彈窗(對話框)明確告知用戶已成功提交,必要時配圖,培養用戶的操作習慣和對品牌的感知。但這僅僅是用于多步驟錄入或大量信息錄入時使用,簡單的錄入不需要這樣“聲勢浩大”的提交反饋。

提交失敗,給出明確的錯誤原因和錯誤引導。如果錯誤內容數量多,種類多,可進行分類展示。

(1)階段性提交,提示需確認常用的反饋形式

當商戶入駐蝦皮,需要填寫關于個人身份、店鋪詳情等信息,分步驟填寫并提交保存時,視為階段性提交。

當然這只是比較簡單的形式,相信很多B端從業的伙伴們都見過超長表單,當表單過長,系統進行階段性提交就會觸發比較多的提示信息。

所以下面講解的是常見的三種階段性提交,系統反饋的提示信息類型:

① 只觸發一項內容需要校驗并修改時 – 單條信息 – 對話框

② 觸發一項以上內容需要校驗 – 多條信息對話框聚合

用總結性話術,幫助用戶確認所有提示信息,比如【具體修改內容描述,可自定義的一句話】修改影響以下內容,是否確認?

③ 內容過多需要逐個確認- 用抽屜頁面承載 – 同時考慮是否一個折疊入口

根據業務訴求,有2點體驗細節需要考慮:

  1. 內容過多,用戶需要一一查看,有時無法一次性確認,可以給一個折疊入口,方便用戶再次確認
  2. 但是用戶每次提交都會給出最新的校驗后提示信息,所以“折疊入口”也不是非要有,根據業務需求來決定

以上是提示信息常用的反饋組件,下面這張圖是關于反饋的強度和提示時間的對比:

三、信息反饋的設計原則

1. 輕量化

關于輕量化,不得不提的是非模態提醒。那么模態與非模態又有什么區別呢?

(1)模態

用戶在完成任務的過程中,界面會出現彈窗打斷用戶的操作行為,用戶必須通過主動點擊才可以進行下一步操作,這即是模態彈窗。

① 優點

模態彈窗通常能較好的獲取用戶的視覺焦點,并通過承載的內容、按鈕主次層級來引導用戶完成他們的需求,這也會根據用戶、產品側重點的不同,彈出樣式也有所不同。

常見的模態彈窗有對話框、動作欄、抽屜…等。

② 缺點

模態是一種強打斷的形式,直接打斷用戶錄入的過程非?!安欢Y貌”,會導致用戶反感,若非必要情況下不要使用。非必要不模態。

(2)非模態

相比模態彈窗,非模態提示較為輕量,觸發后以一種非阻礙的的方式呈現,不會打斷用戶的當前操作,主要是給予用戶即時反饋,讓用戶清楚應用當前的交互后狀態。

優點:非模態彈窗不強制用戶操作,根據反饋信息的重要程度及意愿,可在一定的時間內自動消失,也可等待用戶操作后消失。

(3)常見非模態

前面我們講過的氣泡卡片、全局提示、警告提示都是常見的非模態提示。

2. 精準化

(1)文案清晰

引導文案一定要清晰有效,不要說了半天用戶無法理解。

(2)目標清晰

我們需要幫助用戶完成目標,直接給出“友好”的目標提示。

(3)引導清晰

對于復雜業務場景,給出“新手引導”式有指向性的提示,幫助用戶理解、方便用戶操作。

3. 高效化

(1)節省時間

能在前端校驗的內容不要放到后端校驗,減少后端校驗時的反饋時間。

(2)聚合反饋

能一次提示清楚內容不要分多個反饋組件出現,會讓“眼花繚亂”無法識別。

(3)讀取效率

能分類的、能明確錯誤模塊的一定要給到,方便用戶快速定位錯誤區域。

四、復雜案例帶練

說了這么多,可能還是有點懵,下面我有一個復雜案例帶大家拆解。

案例介紹:

  • 業務特點:流程型業務,涉及多個操作角色,每一環節疊加內容
  • 內容特點:復雜表單錄入,涉及內容聯動,“牽一發而動全身”
  • 涉及模塊:頁面錄入、觸發編輯態錄入、抽屜錄入

1. 模塊保存-校驗規則/交互規范

  1. 點擊“修改”,激活模塊內容,內容由只能查看,變為可以編輯的狀態
  2. 當內容有修改時,點擊“取消”觸發前端校驗,給用戶一個氣泡確認的反饋,告知用戶有內容未保存
  3. 點擊“保存”,觸發后端校驗,后端校驗需要時間(一般不超過5s)
  4. 這時“保存”變成“加載狀態”,“取消”按鈕不可點擊
  5. 提示需求確認的信息使用“全局提示”給用戶反饋

2. 阻斷類:校驗提示信息

阻斷:不修改正確無法繼續進行下一步流程。這時候我們的提示信息要給出明確指導提示。

3. 抽屜提交/保存-校驗規則/交互規范

使用抽屜頁錄入信息并提交或保存時,一般有兩種結果,成功或失敗。保存成功的反饋比較簡單我們就不細講了。

提交成功/保存成功 :關閉彈窗并給到全局提示

而提交失敗含有兩種情況:

  1. 第一種情況:校驗出錯誤,需要修改后重新提交
  2. 第二種情況:無錯誤信息,但是有些內容修改會出現聯動變化,需要用戶進行確認才能保存。

當提示信息有且只有一條,用一個對話框進行展示:

若提示需確認信息超過2條,使用抽屜聚合。通過信息分類和專業的話術方案幫助用戶決策。

4. 頁面提交/保存-校驗規則/交互規范

錄入信息超過一屏,在進行保存提交時,如果觸發超過2條及以上的報錯、提示信息,我們會用抽屜頁面去展示。依然保持錯誤類型、內容模塊的分類。

  1. 錯誤類型:普通提示、需確認
  2. 內容模塊:基本信息、賬戶信息、支付信息等錄入時涉及到的具體模塊
  3. 提示信息內容:文案話術盡可能的簡潔易懂,做到多一個字少一個字都會影響閱讀的程度

五、文章總結

B端交互體驗的魅力在于“解決問題,提升操作效率,降低工作成本”,但常常因為業務本身的復雜性而屢屢受挫。

就像我們之前可能認為“很簡單”的提示信息和校驗規則,在跟產品經理、前后端小伙伴們討論拆解中竟也能發現如此多需要注意的細節點。

下面我嘗試用3句話總結文章重點:

  1. 校驗順序:先前端再后端。
  2. 提示規則:阻斷類先行;提示無需確認隨時可能出現;提示需確認必須出現。
  3. 提示信息在校驗后出現,結合業務需求考量,使用操作效率更高的的反饋組件,非必要不出現。

 

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

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 證明你是人類的正確方式是:向右拖動滑塊驗證

    回復
  2. 有些app的提示信息太過頻繁,讓人一看就想屏蔽,有時候重要的都看不見了

    回復
  3. 當產品業務數據校驗放在前端去做時,多半是因為校驗內容過多,想給后端校驗跑數據時減輕壓力

    來自廣西 回復
    1. 有些數據放在前端和后端都可以處理(手機號及密碼格式校驗)。有些校驗是前端處理不了,只能放在后端處理(手機號匹配密碼)。一個用戶感覺前端和后端校驗感覺沒啥,如果上萬用戶同時操作那就不一樣。
      前端能處理的就沒有必要留在后端了,當然最總也要看功能及業務的需求。

      來自上海 回復
  4. B端交互體驗的魅力在于“解決問題,提升操作效率,降低工作成本”

    來自吉林 回復
  5. 總結的太好了,以前總覺得提示隨便用,看了后大有所獲

    來自湖北 回復