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

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

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

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

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

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

1. B端産品的校驗規則為什麼複雜？

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

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

2. 常見的校驗規則

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

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

3. 基本原則

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

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

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

後端校驗涉及到用戶信息确認、業務數據确認等需要跑通數據庫的校驗内容。

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

4. 提示信息的出現順序

校驗步驟的基本規則是先前端校驗，再後端校驗。基礎内容完成後，再進行複雜信息的校驗。

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

（1）Error錯誤類

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

（2）提示無需确認

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

（3）提示需要确認

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

前端校驗與後端校驗提示信息出現的順序基本一緻：Error錯誤類 – 提示需确認&提示無需确認，隻是前端無法調用複雜數據隻能做簡單的字段校驗，而後端校驗涉及到的是數據庫保存的内容信息。

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

校驗後的提示信息一般伴随用戶錄入信息頁面時出現（交互三原則之一：操作後有反饋），錄入過程又分為錄入中校驗和階段提交校驗；提示信息也分為需要确認和無需确認兩種情況。下面是綜合兩者進行的三種形式分類：

1. 錄入過程中，提示無需确認

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

（1）提示無需确認使用的反饋組件

① 警告提示

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

為什麼用：警告的信息的内容需要被用戶确認，它會以非模态的展現形式，始終展現，不會自動消失，用戶需要點擊才能關閉。（根據業務産品需求，也會出現3s自動消失的情況，根據情節而定）

② 全局提示

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

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

顯示位置：頁面頂部居中

2. 錄入過程中，提示需确認

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

比如用戶即将離開頁面，但修改内容未做保存時，給用戶二次确認，減少誤操作的損失。

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

（1）提示需确認常用的反饋組件

① 氣泡卡片

基本定義和使用規則：點擊後觸發，彈出氣泡式的确認框

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

顯示位置：跟随内容展示，有12個方向供選擇

② 通知提醒框

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

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

顯示位置：頁面右上角

③ 對話框（彈窗）

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

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

功能對話框：涉及到平台内容的錄入，信息較為複雜，還會伴随步驟和反饋等等。

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

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

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

④ 抽屜頁面

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

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

3. 階段性提交，提示需确認

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

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

（1）階段性提交，提示需确認常用的反饋形式

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

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

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

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

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

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

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

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

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

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

三、信息反饋的設計原則

1. 輕量化

關于輕量化，不得不提的是非模态提醒。那麼模态與非模态又有什麼區别呢？

（1）模态

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

① 優點

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

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

② 缺點

模态是一種強打斷的形式，直接打斷用戶錄入的過程非常“不禮貌”，會導緻用戶反感，若非必要情況下不要使用。非必要不模态。

（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協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部