生活中充斥著各種各樣的反饋，而我們就是在這些輸入輸出中認知事物。本文以界面模式的角度，聊一聊反饋模式，enjoy~

開燈會有光、開風扇會有風，開電視會有影像……生活中充斥著各種各樣的反饋，而我們就是在這些輸入輸出中認知事物。同樣，我們向系統輸入一些指令，如果沒有收到反饋，我們不可能認知一個系統。

我之前已經寫過一篇文章聊了一下反饋的重要性，當時說的是一種廣義的反饋，今天再以界面模式的角度，聊一聊反饋模式。

反饋的場景

回想一下一些生活場景：當你想讓你的男/女朋友幫忙倒杯水，會有怎樣的情況會發生？

可能會這樣：

又或者這樣：

在上述場景中，我們可以看出任務是在多輪的執行與反饋中完成的。而且每次反饋都會基于不同的場景。我們來拆解一下：

或者

可見，在日常生活中，我們可以有8種出現反饋的場景。同理，在人和系統的交互中，也會這8種場景。

而每種場景都會有不同的原因、對被反饋者的決策要求和信息輸入要求等等。所以，如果界面模式需要覆蓋以上場景，單一的反饋模式遠遠不夠，而事實上現有的反饋模式確實是多種多樣的。

現有的反饋模式

1. 狀態切換

狀態切換是指用戶與界面元素交互的過程中，界面元素的狀態發生了變化，比如鼠標懸停到按鈕中，按鈕會有高亮的顯示，當鼠標點擊按鈕時，按鈕又有其他的變化等等。這是一種非常輕量而且常見的反饋模式。

而我個人認為這也是一種最基礎最重要的反饋模式。好比，我們呼喊一個人的時候會預期他們會作出響應，所以，在我們操作系統的時候，同樣也會預期有響應，而狀態切換正契合我們這種預期。

分享一個經歷，在一次用戶測試中，我們的系統出現了BUG：用戶填寫完彈窗上的表單后點擊保存，彈窗沒有關閉，但仍然出現一個Toast提示“保存成功”。我原以為這是一個不太嚴重的BUG，最多只會增加用戶的操作步驟去關閉彈窗，不會影響用戶整個任務的完成。

然而，用戶在此彈窗上足足停留了兩分多鐘，最后得知是因為：他覺得彈窗沒有自動關閉就是沒有保存成功，但系統仍然提示“保存成功”，所以很疑惑到底有沒有保存成功。同時他不敢關閉彈窗，因為他生怕沒有保存，不想重頭再來。

這個經歷提醒我，狀態切換能給予用戶最直觀的回應，一旦反饋缺失即會使用戶發生認知沖突，而后果可能會很嚴重。

回到狀態切換這種反饋模式，它可以適用于很多場景：收到請求、遇到阻礙、遇到風險請再次確認、等待中、任務完成等等。

2. 加載

加載能表示系統正在運行，需要用戶再稍等片刻。通常，都會用一些小動效來表現加載中，以降低用戶在等待中的焦慮感，甚至有些產品會以不同的等待時間劃分加載動效。例如：去哪兒的加載動效以0-3秒、3-6秒和6秒以上，三種時長來提供不同的動效。

這樣做的好處在于，能持續地給予用戶反饋，讓用戶知道系統確實在運行中，而不是卡死在這里。否則用戶可能會頻繁地刷新頁面，或者直接離開。

加載模式可以分為模態加載和非模態加載：模態加載即在加載過程中不允許用戶進行其他操作，非模態加載即允許用戶其他操作。設計時要特別留意考慮周全，因為很多時候我們會忽略兩者的區別，過多地使用模態加載。

3. Toast

Toast在移動端非常常見，是一個很輕量的反饋模式，打斷感弱。Toast適用于：任務完成、遇到阻礙等場景。弊端在于不能承載過多的內容。而且提醒性較弱，用戶往往會將其忽略。

4. Snackbar

Snackbar與Toast提示類似，不同點在于：

1. Snackbar位于界面頂部或底部，對內容的遮擋更弱。
2. 可以帶有操作按鈕允許用戶繼續操作。
3. 能提供不同的顏色，可以用顏色區分信息的重要程度。

可以說Snackbar是Toast的加強版，適用于：任務完成、遇到阻礙和提供更多可選方案等場景。

5. 氣泡

氣泡在移動端和PC端都很常見，適用場景也很廣泛，包括：任務不明確、遇到阻礙、遇到風險和提出更多選擇。氣泡有諸多優點：

1. 屬于非模態提示，打斷感較輕。
2. 出現位置在操作區域附近，用戶不容易忽略，同時符合菲茨定律，使得用戶操作更輕快。
3. 可拓展性強，能承載各種樣式的內容。

而缺點在于空間有限，無法適用于內容較多的情況。

6. Action Sheet

Action Sheet 與氣泡提示類似，有同樣的適用場景。而且具有更強的拓展性，即使遇到內容較多的情況也游刃有余。由于極高的可拓展性，它不僅僅能用于反饋，還能適配成為各類的界面模式，如信息錄入、信息列表、詳情展示等等。而且能減少頁面跳轉，讓界面層級扁平化。所以，Action Sheet 這種模式也正越來越流行。

7. 彈窗

可以說，彈窗是一個萬能的反饋模式，可用于所有的場景。但由于彈窗的打斷感極強，所以需要謹慎使用。

8. 整頁反饋

整頁反饋即使用一整個界面來顯示反饋信息，通常用于任務完成的場景。當用戶任務的步驟比較多時，可能需要用到整頁反饋。如下圖，當用戶從一個主頁面的任務入口進入任務時，他需要執行多個步驟，而當任務完成時，他需要返回主頁面而不是上一步驟的頁面。

這種情況下，整頁反饋能讓用戶離開整個任務，而不是仍停留在任務的某個節點。而在PC端，整頁反饋通常會與向導組件一起使用，讓用戶清楚了解任務的步驟和終點，如下圖。

9. 批量操作反饋

批量操作反饋是一個比較特殊的反饋模式，通常在B端產品才能看到。因為B端用戶會經常批量操作，但如果將操作后的結果一條條反饋給用戶顯然不實際，所以批量操作通常是集合式地將信息反饋給用戶。

一些思考點

1. 打斷感、頻次與注意力

打斷感對用戶的注意力有顯著影響，打斷感越強的模式越能吸引用戶的注意力。除打斷感外，頻次也同樣影響著注意力。

《邏輯思維》其中一期《這起醫療事故是誰的錯？》中舉了一實例：“在一次診斷中，醫生失誤開出遠超安全標準劑量的藥物，醫療系統也給出了警報，但醫生卻把警報忽略了，而導致了悲劇的發生”。但這不能全怪醫生，因為一個臨床醫生每個月面對系統發出的警報有一萬七千多條，在這種頻次下，誰都會將警報當耳邊風。

所以，為了讓用戶能更專注于一些重要的提醒，我們的策略應該是：讓打斷感強的模式更低頻出現，讓高頻但次要的信息以打斷感更弱的形式呈現。如下圖，每種場景下的適用反饋模式有多種，模式的打斷感從左往右依次增強，我們應該盡量使用靠左的反饋模式。而彈窗作為一種已知的打斷感最強的模式，我們應非?？酥频厥褂盟?。

另外，針對一些反饋頻次更多的B端產品，我們可以擴展各個模式的顆粒度，讓不同重要程度的信息能有更細致的區分。例如下圖，ant design 的toast（其稱為message提示），將不同的結果按不同的顏色區分，如此一來用戶就可以通過顏色分辨他需要關注的信息。

2. 時間

一些反饋模式會帶有時間屬性，例如Toast，它出現后會自動消失，所以我們需要定義它的停留時間。2-3秒是現今比較常見的時長，但這種簡單的邏輯能覆蓋的場景其實非常有限。

• 首先，不同類型的反饋信息，用戶的關注程度不一樣，所以閱讀時間也不一樣。例如任務出錯比任務成功的內容需要消化的時間會截然不同。
• 其次，反饋內容的長度也會影響時間。較長的文本肯定需要更長的時間去消化，而且較長的問題通常是比較特殊的場景下才出現，不具備通用性，用戶理解起來也會更費勁。
• 最后，在高頻反饋的場景下，對時間的需求也會不一樣。例如，用戶操作單次時，Toast停留3秒沒有問題，但當用戶重復多次操作時，多條Toast就會在提留時間內重疊顯示。

所以，盡管是一個停留時間，我們也應該對各種場景考慮周到，并歸類抽象出共性再定義時間的規則。

3. 位置

在我看來，在移動端反饋的出現位置其實并不是一個需要十分考究的點，因為屏幕就那么大，無論在哪用戶都容易發現。但是在PC端卻是一個需要考究的問題，因為屏幕會大很多，在一些區域用戶很可能感知不到反饋的出現。

一些學者已經指出，用戶在瀏覽網頁時對各個區域的偏好：中部為最高注視區，而其他區域的關注度從左上角到右下角依次遞減，如下圖。這是一個非常有用的參考，我們可以根據信息的重要程度來定義反饋模式應該在哪個區，不干擾用戶的同時又不被用戶忽略。

另外一個問題是大屏的趨勢。2k屏、4K屏甚至AR、VR等無邊界界面的流行，使得屏幕邊緣的信息將會越來越弱化，因為它們離視中心會越來越遠。這會使得反饋位置的定位方式發生改變：從以屏幕邊緣為錨點轉向以屏幕中心為錨點。這兩種選擇會在大小屏切換時呈現不一樣的效果，如下圖：

4. 反饋遠不止反饋

讓我們跳出反饋的框架看一看，其實僅僅提供反饋是遠不夠的：當用戶收到一個報錯反饋時，他不是想要知道錯誤的原因，而是需要知道下一步要怎么做；當用戶收到一個警報信息時，用戶不是想要知道原因，而是要知道如何解決。

一種好的反饋模式不僅僅是反饋，更是一種導航，引導用戶下一步應該做什么、怎么解決問題。真正能讓用戶開心的反饋永遠只有一個，就是“任務成功”，所以在給出反饋之前，我們應該好好想想，怎么才能讓用戶更簡單地到達這一步。

#專欄作家#

Genrry，公眾號：設計師阿余，人人都是產品經理專欄作家。關注用戶體驗，擅長多端交互設計、界面設計。曾負責大型B端產品及VR游戲產品體驗設計，制定設計規范，打磨細節體驗，探索創新交互體驗。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議