從界面模式的角度,談談反饋設計

0 評論 5250 瀏覽 24 收藏 17 分鐘

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

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

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

反饋的場景

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

可能會這樣:

反饋設計的9種模式、8個場景及4個思考點

又或者這樣:

反饋設計的9種模式、8個場景及4個思考點

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

反饋設計的9種模式、8個場景及4個思考點

或者

反饋設計的9種模式、8個場景及4個思考點

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

反饋設計的9種模式、8個場景及4個思考點

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

現有的反饋模式

1. 狀態切換

反饋設計的9種模式、8個場景及4個思考點

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

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

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

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

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

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

2. 加載

反饋設計的9種模式、8個場景及4個思考點

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

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

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

3. Toast

反饋設計的9種模式、8個場景及4個思考點

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

4. Snackbar

反饋設計的9種模式、8個場景及4個思考點

Snackbar與Toast提示類似,不同點在于:

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

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

5. 氣泡

反饋設計的9種模式、8個場景及4個思考點

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

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

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

6. Action Sheet

反饋設計的9種模式、8個場景及4個思考點

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

7. 彈窗

反饋設計的9種模式、8個場景及4個思考點

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

8. 整頁反饋

反饋設計的9種模式、8個場景及4個思考點

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

反饋設計的9種模式、8個場景及4個思考點

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

反饋設計的9種模式、8個場景及4個思考點

9. 批量操作反饋

反饋設計的9種模式、8個場景及4個思考點

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

一些思考點

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

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

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

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

反饋設計的9種模式、8個場景及4個思考點

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

反饋設計的9種模式、8個場景及4個思考點

2. 時間

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

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

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

3. 位置

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

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

反饋設計的9種模式、8個場景及4個思考點

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

反饋設計的9種模式、8個場景及4個思考點

4. 反饋遠不止反饋

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

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

#專欄作家#

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

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

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!