10個場景、40+案例,總結 APP 反饋設計

生活中處處是反饋，而這種普遍性更是延伸到了移動端與app上。同時，因為不同場景適用的反饋模式有所不同，那麼我們需要認識不同場景的特性，並針對場景特性做出對應的反饋設計。那麼具體如何做呢？本文將告訴你答案。

一、前言

現實生活中反饋無處不在，你和他人溝通（問答反饋），使用物品（比如現在我在敲打鍵盤，顯示屏顯示了這段文字）等。及時且合理的反饋，讓我們的體驗更加順暢，反饋設計是用戶體驗設計中至關重要的一環。

1. 反饋場景

我們在現實中會碰到哪些反饋場景呢？剛好我在今年1月底去大使館辦理俄羅斯籤證，就從辦理過程中碰到的場景展開，聽我娓娓道來。

2. 方式選擇

朋友告知我可選擇網上代理辦理或者自行前往大使館或籤證中心辦理（明確辦理方式後可確定下一步操作）

3. 資料準備

確定前往大使館辦理要自己準備好資料，那我需要提前了解準備哪些資料？（遇到任務不明確需要更多信息）

4. 提交資料

在申請表貼照片時，同伴提醒我照片要貼在申請表上規定的範圍內（在操作時獲得反饋）

全部資料遞交給工作人員，工作人員初步審核資料時將前面的帘子拉下讓我稍等片刻（狀態切換告知）

告知我還需要補全近半年銀行流水單（遇到阻礙，流程被中斷，給出解決方案）

5. 等待審核

過了幾天，補全資料再次提交審核（信息提交終審進行資料校驗）

需要等待5個工作日才有結果（等待結果）

6. 接收結果

在規定日期取護照，拿到護照即知道辦理結果（最終結果獲知，結果可能成功也可能失敗）

因新冠肺炎較為嚴重，新聞報導俄羅斯關閉邊境入口（獲得外界信息反饋，近期無法出行）

實際App設計中，我們也同樣會碰到以上類似的場景，通過拓展，可以總結為以下10種場景。

以上每個場景中都有一個核心要點，我們的反饋設計便是針對這些關鍵要點確定設計目標，應用合適的反饋模式，讓用戶不迷茫，讓體驗順利執行。

下圖為App反饋設計的10個場景以及對應的設計目標。

下面通過實例來解析這些反饋場景。

二、實例解析App反饋場景

在App中操作中，從交互方式來說，有點擊、滑動、長按等；從伺服器數據接收來說，用戶輸入和選擇都是數據傳輸行為，我們所進行的這一些操作，都是在App界面上實現的。

我將反饋場景分成了2個一級分類，4個二級分類，10個反饋場景，一級分類分為「自主操作獲得反饋」和「被動接收反饋信息」。

• 自主操作獲得反饋：指用戶自己在App上操作而獲得的反饋，這裡用戶流是「自己操作->獲得反饋」
• 被動接收反饋信息：指因其他用戶或系統操作需要傳輸反饋給「你」，從而「你」被動接收到了反饋，這裡用戶流是「他人操作->獲得反饋」

下面結合案例就不同反饋場景適用的反饋模式應用具體展開說明。

1. 自主操作獲得反饋

用戶自主操作獲得反饋，可以拆分成3個部分，按操作流程來分類，從「操作過程」，到「操作過渡」，再到「操作結果」。

「操作過程」、「操作過渡」、「操作結果」覆蓋用戶操作的時時刻刻，當你點擊某個按鈕、當你進入詳情頁時、當你提交個人信息時、當你完成支付訂單時…。

1.1 操作過程

1.1.1 操作即變化

當我們在界面上進行操作時，App界面呈現視覺、聽覺或觸覺方面的變化告知我們操作有效。

從反饋模式來看，主要有操作組件的狀態切換（視覺層面）、和物理反饋（聽覺和觸覺層面）。

a 狀態切換

我們點擊按鈕時，按鈕的狀態從「正常狀態」切換為「按下時狀態」；我們選擇某個頁籤時，被選中的頁籤從「未選中狀態」切換為「選中狀態」；點擊輸入框，輸入框即獲取焦點等等，這些都是狀態切換反饋告訴用戶App在正常有效執行著。

在App中，所有組件在用戶操作時即立馬給出反饋，單一組件的操作是「起點」也是「終點」，這裡分類劃分到「操作過程」而不是「操作結果」，是因為對於流程較長、重要級別較高、信息量較大的操作流來說，眾多單一組件的操作構成了長流程的整個操作，所以這裡將操作即發生的狀態切換歸併到「操作過程」中，不用過多細究和糾結。（題外話：在場景劃分的時候，「操作即反饋」場景的劃分讓我有點糾結，這裡給出我的劃分解釋，你也可以根據你的理解自行劃分）

舉例：在美團外賣App編輯收貨地址，進行選擇性別、點擊手機號輸入框、選擇標籤、點擊保存地址按鈕這些操作時，組件的狀態都在跟著操作在進行切換。

b 物理反饋

操作即反饋除了視覺層面的反饋，還有聽覺和觸覺層面的，通過聲音和手指在手機上感受到的震動來傳達。

舉例：安卓自帶的鬧鐘工具，通過滑動時針或分針來確定小時和分鐘，滑動過程中伴有聲音和震動。

1.1.2  任務不明確

用戶在操作過程中，需要周全地考慮用戶是否會存在對當前界面內容或當前操作存在疑惑的場景，若有需要給予用戶更多的信息解決用戶的困惑，否則用戶可能會錯過重要信息，也可能會自主中斷整個操作流程從而流失。

a 本頁面

說明內容較少則在本頁面進行描述或點擊氣泡展開描述。

舉例：去哪兒App實名認證選擇「港澳臺及外籍人士認證」方式，需要上傳手持身份證照片，用戶可能會手持的方式產生疑惑，當前頁有卡通形象示意手持的位置，同時點擊「照片實例」按鈕在新頁面也可以看到真實人物範本。

b 新頁面

說明內容超級多則在新啟頁面描述。

舉例：美團外賣App某商品詳情頁點擊「價格說明?」按鈕跳到新頁面。

c 氣泡

氣泡上可以加上關閉按鈕也可不加，有的話，用戶點擊關閉按鈕後氣泡消失。

舉例1：去哪兒App搜索機票，為了讓用戶理解降價提醒的含義，頁面上以氣泡的形式加上了降價提醒功能的解釋說明。

舉例2：訂閱號App中「近15天數據」右側有個解釋圖標，點擊後通過氣泡告知數據在每天上午9時更新，再次點擊關閉氣泡。

d 彈窗

說明內容稍多可通過彈窗描述。

舉例：唯品會App我的訂單列表中，支持退換商品有「7天退換」的標籤，而不支持的則有「不支持換貨?」文字按鈕，點擊按鈕會有彈窗說明。

e 點擊展開

默認展示摘要內容，將重要信息收起，可展開查看更多。

舉例：美團外賣App進入商家頁面，了解更多詳細介紹通過點擊展開可以查看。

1.1.3 進一步操作

一個操作流可以是一個單一操作，比如點擊首頁標籤欄跳到首頁頁面；也可以是多個單一操作構成的長流程，比如微信聊天選擇視頻通話後讓你選擇是視頻還是語音。

我們常碰到當我們進行某個操作時，會有新的操作反饋給我們，選擇其中一個操作後繼續進行下一步操作。

a 上拉菜單（動作面板）

上拉菜單包含多個操作，選擇某個操作後流程並未終止，進一步明確了操作。

舉例1：微信點擊視頻聊天，上拉菜單選擇語音或視頻。

舉例2：網易郵箱打開某個郵件後進行更多操作。

b 操作列表

操作列表和上拉菜單的作用是一樣的，表現形式不同。

舉例：企業微信點擊上傳文件，進一步讓用戶選擇從本地上傳還是微盤上傳。

c 彈窗

需要二次確認可以使用彈窗。

舉例：企業微信選擇要上傳的文件後，彈窗讓用戶確認是否發送，同時彈窗上有輸入框可以添加附加留言。

d 浮層菜單

將更多操作合併到浮層菜單中，浮層菜單緊貼著觸發按鈕，浮層菜單無遮罩背景。

舉例1：微信點擊右上角的「+」圖標。

舉例2：美外賣App點擊更多頁籤欄。

e 編輯菜單

通常通過長按（Android系統常應用的交互動作）呼出編輯菜單，編輯菜單可以水平方向排布操作也可以垂直方向。

舉例1：微信長按某聊天（Android系統），呼出編輯菜單。

舉例2：微信公眾號文章（Android系統），長按一段文字彈出水平編輯菜單，可以進行複製或搜索。

f 左滑菜單

通過向左滑動觸發更多操作。

舉例：網易郵箱App郵件列表向左滑動。

g 工具欄

工具欄一般位於頁面底部。

舉例：企業微信App聊天窗口多選記錄，底部出現工具欄進行更多操作。

1.1.4 中斷操作流

用戶在操作過程，比如因為自身因素主動中斷流程；比如填寫表單覺得太繁瑣用戶自己選擇關閉。

不管因為哪種因素中斷，反饋的要點是告知用戶中斷風險或解決方案。

a 彈窗

舉例1：美團App取消訂單進行了二次確認並提供訂單信息修改入口。

舉例2：微博輸入一大段文字後取消發布會有危險操作提醒。

1.2 操作過渡

在我們提交操作，新的界面或最終結果呈現之前，若存在數據加載或更新需要用戶等待，需要給予「加載反饋」，減緩用戶因等待而產生的焦慮感。

「加載反饋」有頁面進度條、頁面加載、模態加載、骨架屏、狀態切換等。

a 頁面進度條

進入一個新的頁面，比如從列表頁面進入詳情頁，以頁面進度條的形式告知頁面加載進度，進度條完成百分百進度，頁面也完全加載完成。

常應用於h5頁面。

舉例：去哪兒點擊頁面頭部的Banner，頁面進度條告知頁面加載情況。

b 頁面加載

進入一個新的頁面，該頁面結構單一，可以用空白頁面加載動畫的形式加載，加載動畫位於頁面的中心，可以是常規傳統的轉菊花、轉圈圈，也可以結合App品牌形象設計有趣的加載動畫。

舉例：去哪兒的加載動畫結合品牌形象駱駝，從悠閒散步到加快小跑再到加速快跑，文案分別映射為：努力加載中、瘋狂加載中、玩命加載中。

c 模態加載

頁面加載和模態加載這2種反饋模式是近親，不同的就是頁面加載將加載動畫嵌在空白頁面上，而模態加載則是將加載動畫嵌在置於頁面上層的模態框上，什麼場景用頁面加載，什麼場景用模態加載，具體情況具體分析，下面的案例就是一種情況。

舉例：以下案例的前置操作是在『降價提醒頁面』點擊「新增降價提醒按鈕」，進入『新增降價提醒頁面』後返回上個頁面，這裡進入『新增降價提醒頁面』用的是「頁面加載」方式，在『新增降價提醒頁面』還未加載完成就返回上個頁面，此時還是用「頁面加載」的方式，從一個空白加載頁面到另外一個空(yi)白(mo)加(yi)載(yang)的頁面，會讓用戶以為自己沒點到返回按鈕，是不是返回失敗了。所以這裡返回上個頁面採用「緩存結果+模態加載」的形式。

d 骨架屏

進入一個新頁面，該頁面內容結構而有規律，可以用骨架屏的形式加載頁面。

骨架屏根據頁面結構設計一個骨架圖，用灰色塊代替文字和圖片，看起來像骨架支撐了頁面，因此這種加載形式可以叫骨架屏。

在頁面完全加載完之前，都展示骨架屏，加載完後顯示內容。

舉例：查看去哪兒的低價機票，新頁面是較為規整的頁面（可以結構化），採用的便是骨架屏的加載方式。

我們看到加載完成後的頁面如下：

e 狀態切換

除了以上4種過渡加載方式，還有一種「狀態切換」方式，前文提到過，「狀態切換」多為組件的狀態切換，操作過渡最常應用的組件就是按鈕，參看案例。

舉例1：在支付寶支付付款環節，校驗指紋會加載等待一會，校驗前「待校驗狀態」，指紋按下後是「校驗中狀態」。

指紋校驗狀態切換如下：

舉例2：指紋校驗成功後要請求藉口完成扣款請求，在請求的過程中發生等待，這裡支付按鈕便從「默認可點擊狀態」切換為「支付中狀態」進行請求過渡，完成無縫銜接。

支付按鈕狀態切換如下：

1.3 操作結果

不管是單一操作，還是複雜、流程較長的操作，操作結果的反饋主要覆蓋「結果校驗」、「結果審核」、「結果成功」、「結果失敗」這4個場景。

1.3.1 結果校驗

當我們在填寫表單時、提交重要資料時、在商城發表自己的購買評論時… …凡是涉及到用戶輸入和選擇的操作，都存在對信息的校驗。

校驗會有事先擬定好的校驗規則，比如必填項不能漏填、上傳的文件大小不能超過XM、評論的字數不能超過XXX字等等。

此部分只討論通過對結果的校驗告知用戶錯誤來源，讓用戶知道為什麼出錯並進行修正。用戶操作成功的反饋將在「3.3結果成功」中討論。

這裡不討論校驗的過程（因校驗而產生的等待在「2、操作過渡」中有分析，這裡只討論檢驗的錯誤結果）。

a Toast

Toast是常用的信息校驗提示方式，因為它打擾程度較低，對出現的時間可以進行調整，一般設定為2～3秒。

舉例：在美團外賣App新增收穫地址，不填寫內容即提交，Toast提醒錯誤信息。

b 狀態切換

在一些頁面中，最終提交按鈕默認置灰處理，待用戶表單填寫完畢或上傳完資料後，按鈕變為可點擊狀態，點擊按鈕提交後再對填寫的信息或資料進行校驗，組件的狀態切換也是對用戶的一種反饋提醒。

舉例：滴滴金融App，註冊流程設置登錄密碼，提交按鈕默認是置灰的，只有輸入的內容符合規則了，「確定」按鈕才可點擊提交。

c 實時校驗

實時校驗就是對用戶輸入或選擇的內容進行實時校驗，輸入不符合規則即給出反饋。

舉例：參看「3.1、結果校驗 – b.狀態切換」案例。

1.3.2 結果等待

這種場景並不常見，但實際確實會碰上用戶提交操作後需要用戶等待一定的時間（短則幾個小時，長則幾天）才能最終獲得最終結果的場景，比如申請商城申請退換貨後需要系統審核。

「1.3.2 結果等待」和「1.2 操作過渡」的設計目標均是減緩用戶因等待而產生的焦慮，但本質不同，其差異性如下：

• 「操作過渡」是短暫的過渡，用戶只需等待短短幾秒或幾十秒；「結果等待」時間較長，無法採用「操作過渡」的加載方案
• 「操作過渡」等待完成後可以馬上進入到下個流程；「結果等待」常出現在流程較長、信息量較大的操作中，「結果等待」出現後即表示現階段流程的完成

在用戶提交資料審核後才能正常使用App的場景中，能避免結果審核儘量避免，因為讓用戶長時間的等待意味著流失的可能性越大，對於一定要經過審核的流程，一方面要縮短審核的時間，另一方面優化審核的算法，爭取能夠在最短的時間內容給出結果（失敗or成功）。

常見的設計模式為：

a 結果頁

舉例：在某App中，用戶提交還款申請後，需要等待銀行處理後再返回還款成功的結果。

1.3.3 結果成功

我們這裡討論的成功的操作反饋是「有形」的反饋體現，比如你在購物支付訂單完成後，有一個專門的支付成功結果頁展示。

「無形」的反饋這裡不進行討論，比如你搜索內容，搜索成功後即自動將搜索結果展示出來，而不用再給你一個「有形」的專門提示（比如Toast）告知你搜索成功了。

a Toast

單一操作或整個流程的操作成功結果告知，2～3秒後消失，不幹擾用戶當前行為。

舉例：微信複製一段文字，複製完畢後提示「已複製」（Android系統）。

b Snackbar

Snackbar和Toast差異之一是Snackbar上可以進行其他操作。

根據需要選擇使用Toast或Snackbar。

舉例：用安卓手機錄屏完成後彈出Snackbar提示，在Snackbar上我可以進行分享或刪除操作，若不進行操作幾秒後(大概4s?)就自動消失。（不得不說比IOS的錄屏好用，錄屏的時候經常錄廢，IOS刪除錄屏我要到相冊裡面刪除，Andorid我直接在Snackbar上刪除就行了，方便多了）

c 結果頁

對於包含重要信息、多步驟的長流程，最終操作成功用一個結果頁較為合適，結果頁的優點是可以最大面積的呈現其他內容或其他操作。

舉例：支付寶轉帳成功。

d 彈窗

彈窗的打擾較強，當有重要信息需要用戶停留查看時可用彈窗。

舉例：美團App支付成功後彈窗告知支付成功，同時彈窗附加了贈券信息。

e 狀態切換

能在當前頁面通過狀態切換告知用戶操作成功，那就最好不過了。

舉例：在企業微信傳輸文件給對方，點擊發送後，狀態從「發送中…」切換為「發送成功」。

f 動畫

以動畫的形式表示操作成功。

舉例1：豆瓣App文章點讚成功。

舉例2：荔枝App音頻點讚成功。

1.3.4 結果失敗

在3.1我們討論了若用戶提交的信息有誤，需要對錯誤結果進行反饋提示。

3.1描述的場景針對校驗的場景，3.4結果失敗我們討論一些因為異常場景或其他原因所導致的失敗場景，異常狀態包含網絡異常、流量告警、伺服器異常、加載失敗、空狀態、內容重建等。

更多閱讀：《關於異常狀態的設計總結》

結果失敗的反饋模式常見的有以下幾種：

a 預設頁

當用戶操作進入App新的頁面時，常以預設頁的形式提醒用戶當前網絡異常、伺服器異常或狀態為空。

舉例：比如網易雲音樂在無網絡連接下，進入新頁面時，預設頁以簡單的文案告知當前無網絡，通過點擊查看詳情告知用戶解決方案以及引導如何解決問題。

b 彈窗

用戶在當前頁面進行點擊操作時，比如上拉加載頁面、下拉刷新頁面，點讚、關注等操作時，操作失敗時常以彈窗或Toast的形式提示用戶，同時告知原因並給出解決方案。

舉例：網易雲音樂，網絡異常情況下下拉刷新或上拉加載頁面均進行對話框提示，並引導用戶檢查網絡權限設置。

c  Toast

舉例：無網絡連接環境下，在我的訂單頁面進行評價操作，會進行Toast提示。

d 結果頁

對於包含重要信息、多步驟的長流程，最終操作成功用一個結果頁較為合適，對應失敗結果也是設計為結果頁（一致性原則）。

舉例：在某App中，用戶因扣款帳戶餘額不足導致還款失敗，還款列表記錄了還款失敗的記錄，進入詳情頁可看到還款失敗結果頁。

e 狀態切換

能在當前頁面通過狀態切換告知用戶操作失敗，那就選擇該種方式。

舉例：微信消息發送失敗，發送內容的左邊有一個「紅色感嘆號」的實心圖標，意味著該消息發送失敗。

f Snackbar

前面介紹過，Snackbar除了信息告知還可以附帶操作入口。

舉例：同上案例，（Android系統）微信聊天消息發送失敗的同時收到Snackbar反饋，在Snackbar上可以忽略也可以進行重新發送操作。

2. 被動接收反饋信息

用戶被動接收反饋信息主要由他人或系統觸發，場景有：

• 他人發送消息給我，比如微信有人給我發文字、語音、紅包或文件等，社交App常有的場景
• 系統主動給用戶推送消息，比如功能更新、功能重建、系統公告、條款更新、消息動態更新等，一般App中都會出現該場景

常見的反饋模式有通告欄、紅點、標籤等：

舉例：去哪兒的機票退款進度更新、系統通知更新採用紅點的形式告知我，要實名認證則以通告欄的形式提醒我。

如下用箭頭標出的地方：

三、反饋設計原則

通過以上實際案例的分析，我們對App中反饋場景對應的設計目標和設計模式更加瞭然於心，當然，以上反饋模式包含但不限於，相應的反饋場景不除外有更好的反饋模式。

這不是一份標準答案，反饋模式只是一種外在表現形式，只要能夠達到反饋目標，也可以選擇更優方案。

案例中提到的反饋模式都是基於App內部的，除了App內部的反饋模式，還應該考慮到App外部的反饋模式，比如：簡訊、手機通知、郵件、微信公眾號等，這裡不詳細展開。

最後，一起看下我們在進行反饋設計時需要遵循一些設計原則。

1. 反饋響應及時

反饋結果應及時告知用戶，試想用戶付完款後沒有付款成功的反饋，用戶心裡該多著急。

2. 反饋避免打擾

採用的反饋模式儘可能將對用戶當前操作的打擾程度降到最低，比如對於用戶容易頻繁填錯信息的界面，一方面要考慮如何降低用戶的出錯率，另一方面用戶出錯後不採用打擾程度最高的彈窗而是採用輕量提示Toast。

3. 反饋模式合理

雖然我們在設計反饋時會考慮避免打擾用戶，但在對應的場景應選擇最合理的反饋模式，比如用戶的危險操作用打擾程度較高的彈窗，因為彈窗對用戶的警示性會更強，用Toast的話用戶反而會不重視。

End

通過對反饋場景和設計原則的梳理，結合實際案例，我對反饋模式的應用有了更深的理解。

你呢？

---

作者：辛小仲；一名正在成長的互動設計師，公眾號：辛小仲。

本文由 @辛小仲 原創發布於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議