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

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

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

反饋的場景

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

可能會這樣：

又或者這樣：

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

或者

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

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

現(xiàn)有的反饋模式

1. 狀態(tài)切換

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

而我個人認(rèn)為這也是一種最基礎(chǔ)最重要的反饋模式。好比，我們呼喊一個人的時候會預(yù)期他們會作出響應(yīng)，所以，在我們操作系統(tǒng)的時候，同樣也會預(yù)期有響應(yīng)，而狀態(tài)切換正契合我們這種預(yù)期。

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

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

這個經(jīng)歷提醒我，狀態(tài)切換能給予用戶最直觀的回應(yīng)，一旦反饋缺失即會使用戶發(fā)生認(rèn)知沖突，而后果可能會很嚴(yán)重。

回到狀態(tài)切換這種反饋模式，它可以適用于很多場景：收到請求、遇到阻礙、遇到風(fēng)險請再次確認(rèn)、等待中、任務(wù)完成等等。

2. 加載

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

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

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

3. Toast

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

4. Snackbar

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

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

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

5. 氣泡

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

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

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

6. Action Sheet

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

7. 彈窗

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

8. 整頁反饋

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

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

9. 批量操作反饋

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

一些思考點

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

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

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

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

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

2. 時間

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

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

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

3. 位置

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

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

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

4. 反饋遠(yuǎn)不止反饋

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

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

#專欄作家#

Genrry，公眾號：設(shè)計師阿余，人人都是產(chǎn)品經(jīng)理專欄作家。關(guān)注用戶體驗，擅長多端交互設(shè)計、界面設(shè)計。曾負(fù)責(zé)大型B端產(chǎn)品及VR游戲產(chǎn)品體驗設(shè)計，制定設(shè)計規(guī)范，打磨細(xì)節(jié)體驗，探索創(chuàng)新交互體驗。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議