生活中處處是反饋，而這種普遍性更是延伸到了移動(dòng)端與app上。同時(shí)，因?yàn)椴煌瑘?chǎng)景適用的反饋模式有所不同，那么我們需要認(rèn)識(shí)不同場(chǎng)景的特性，并針對(duì)場(chǎng)景特性做出對(duì)應(yīng)的反饋設(shè)計(jì)。那么具體如何做呢？本文將告訴你答案。

一、前言

現(xiàn)實(shí)生活中反饋無(wú)處不在，你和他人溝通（問(wèn)答反饋），使用物品（比如現(xiàn)在我在敲打鍵盤，顯示屏顯示了這段文字）等。及時(shí)且合理的反饋，讓我們的體驗(yàn)更加順暢，反饋設(shè)計(jì)是用戶體驗(yàn)設(shè)計(jì)中至關(guān)重要的一環(huán)。

1. 反饋場(chǎng)景

我們?cè)诂F(xiàn)實(shí)中會(huì)碰到哪些反饋場(chǎng)景呢？剛好我在今年1月底去大使館辦理俄羅斯簽證，就從辦理過(guò)程中碰到的場(chǎng)景展開(kāi)，聽(tīng)我娓娓道來(lái)。

2. 方式選擇

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

3. 資料準(zhǔn)備

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

4. 提交資料

在申請(qǐng)表貼照片時(shí)，同伴提醒我照片要貼在申請(qǐng)表上規(guī)定的范圍內(nèi)（在操作時(shí)獲得反饋）

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

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

5. 等待審核

過(guò)了幾天，補(bǔ)全資料再次提交審核（信息提交終審進(jìn)行資料校驗(yàn)）

需要等待5個(gè)工作日才有結(jié)果（等待結(jié)果）

6. 接收結(jié)果

在規(guī)定日期取護(hù)照，拿到護(hù)照即知道辦理結(jié)果（最終結(jié)果獲知，結(jié)果可能成功也可能失?。?/p>

因新冠肺炎較為嚴(yán)重，新聞報(bào)道俄羅斯關(guān)閉邊境入口（獲得外界信息反饋，近期無(wú)法出行）

實(shí)際App設(shè)計(jì)中，我們也同樣會(huì)碰到以上類似的場(chǎng)景，通過(guò)拓展，可以總結(jié)為以下10種場(chǎng)景。

以上每個(gè)場(chǎng)景中都有一個(gè)核心要點(diǎn)，我們的反饋設(shè)計(jì)便是針對(duì)這些關(guān)鍵要點(diǎn)確定設(shè)計(jì)目標(biāo)，應(yīng)用合適的反饋模式，讓用戶不迷茫，讓體驗(yàn)順利執(zhí)行。

下圖為App反饋設(shè)計(jì)的10個(gè)場(chǎng)景以及對(duì)應(yīng)的設(shè)計(jì)目標(biāo)。

下面通過(guò)實(shí)例來(lái)解析這些反饋場(chǎng)景。

二、實(shí)例解析App反饋場(chǎng)景

在App中操作中，從交互方式來(lái)說(shuō)，有點(diǎn)擊、滑動(dòng)、長(zhǎng)按等；從服務(wù)器數(shù)據(jù)接收來(lái)說(shuō)，用戶輸入和選擇都是數(shù)據(jù)傳輸行為，我們所進(jìn)行的這一些操作，都是在App界面上實(shí)現(xiàn)的。

我將反饋場(chǎng)景分成了2個(gè)一級(jí)分類，4個(gè)二級(jí)分類，10個(gè)反饋場(chǎng)景，一級(jí)分類分為“自主操作獲得反饋”和“被動(dòng)接收反饋信息”。

• 自主操作獲得反饋：指用戶自己在App上操作而獲得的反饋，這里用戶流是“自己操作->獲得反饋”
• 被動(dòng)接收反饋信息：指因其他用戶或系統(tǒng)操作需要傳輸反饋給“你”，從而“你”被動(dòng)接收到了反饋，這里用戶流是“他人操作->獲得反饋”

下面結(jié)合案例就不同反饋場(chǎng)景適用的反饋模式應(yīng)用具體展開(kāi)說(shuō)明。

1. 自主操作獲得反饋

用戶自主操作獲得反饋，可以拆分成3個(gè)部分，按操作流程來(lái)分類，從“操作過(guò)程”，到“操作過(guò)渡”，再到“操作結(jié)果”。

“操作過(guò)程”、“操作過(guò)渡”、“操作結(jié)果”覆蓋用戶操作的時(shí)時(shí)刻刻，當(dāng)你點(diǎn)擊某個(gè)按鈕、當(dāng)你進(jìn)入詳情頁(yè)時(shí)、當(dāng)你提交個(gè)人信息時(shí)、當(dāng)你完成支付訂單時(shí)…。

1.1 操作過(guò)程

1.1.1 操作即變化

當(dāng)我們?cè)诮缑嫔线M(jìn)行操作時(shí)，App界面呈現(xiàn)視覺(jué)、聽(tīng)覺(jué)或觸覺(jué)方面的變化告知我們操作有效。

從反饋模式來(lái)看，主要有操作組件的狀態(tài)切換（視覺(jué)層面）、和物理反饋（聽(tīng)覺(jué)和觸覺(jué)層面）。

a 狀態(tài)切換

我們點(diǎn)擊按鈕時(shí)，按鈕的狀態(tài)從“正常狀態(tài)”切換為“按下時(shí)狀態(tài)”；我們選擇某個(gè)頁(yè)簽時(shí)，被選中的頁(yè)簽從“未選中狀態(tài)”切換為“選中狀態(tài)”；點(diǎn)擊輸入框，輸入框即獲取焦點(diǎn)等等，這些都是狀態(tài)切換反饋告訴用戶App在正常有效執(zhí)行著。

在App中，所有組件在用戶操作時(shí)即立馬給出反饋，單一組件的操作是“起點(diǎn)”也是“終點(diǎn)”，這里分類劃分到“操作過(guò)程”而不是“操作結(jié)果”，是因?yàn)閷?duì)于流程較長(zhǎng)、重要級(jí)別較高、信息量較大的操作流來(lái)說(shuō)，眾多單一組件的操作構(gòu)成了長(zhǎng)流程的整個(gè)操作，所以這里將操作即發(fā)生的狀態(tài)切換歸并到“操作過(guò)程”中，不用過(guò)多細(xì)究和糾結(jié)。（題外話：在場(chǎng)景劃分的時(shí)候，「操作即反饋」場(chǎng)景的劃分讓我有點(diǎn)糾結(jié)，這里給出我的劃分解釋，你也可以根據(jù)你的理解自行劃分）

舉例：在美團(tuán)外賣App編輯收貨地址，進(jìn)行選擇性別、點(diǎn)擊手機(jī)號(hào)輸入框、選擇標(biāo)簽、點(diǎn)擊保存地址按鈕這些操作時(shí)，組件的狀態(tài)都在跟著操作在進(jìn)行切換。

b 物理反饋

操作即反饋除了視覺(jué)層面的反饋，還有聽(tīng)覺(jué)和觸覺(jué)層面的，通過(guò)聲音和手指在手機(jī)上感受到的震動(dòng)來(lái)傳達(dá)。

舉例：安卓自帶的鬧鐘工具，通過(guò)滑動(dòng)時(shí)針或分針來(lái)確定小時(shí)和分鐘，滑動(dòng)過(guò)程中伴有聲音和震動(dòng)。

1.1.2? 任務(wù)不明確

用戶在操作過(guò)程中，需要周全地考慮用戶是否會(huì)存在對(duì)當(dāng)前界面內(nèi)容或當(dāng)前操作存在疑惑的場(chǎng)景，若有需要給予用戶更多的信息解決用戶的困惑，否則用戶可能會(huì)錯(cuò)過(guò)重要信息，也可能會(huì)自主中斷整個(gè)操作流程從而流失。

a 本頁(yè)面

說(shuō)明內(nèi)容較少則在本頁(yè)面進(jìn)行描述或點(diǎn)擊氣泡展開(kāi)描述。

舉例：去哪兒App實(shí)名認(rèn)證選擇“港澳臺(tái)及外籍人士認(rèn)證”方式，需要上傳手持身份證照片，用戶可能會(huì)手持的方式產(chǎn)生疑惑，當(dāng)前頁(yè)有卡通形象示意手持的位置，同時(shí)點(diǎn)擊“照片實(shí)例”按鈕在新頁(yè)面也可以看到真實(shí)人物范本。

b 新頁(yè)面

說(shuō)明內(nèi)容超級(jí)多則在新啟頁(yè)面描述。

舉例：美團(tuán)外賣App某商品詳情頁(yè)點(diǎn)擊“價(jià)格說(shuō)明?”按鈕跳到新頁(yè)面。

c 氣泡

氣泡上可以加上關(guān)閉按鈕也可不加，有的話，用戶點(diǎn)擊關(guān)閉按鈕后氣泡消失。

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

舉例2：訂閱號(hào)App中“近15天數(shù)據(jù)”右側(cè)有個(gè)解釋圖標(biāo)，點(diǎn)擊后通過(guò)氣泡告知數(shù)據(jù)在每天上午9時(shí)更新，再次點(diǎn)擊關(guān)閉氣泡。

d 彈窗

說(shuō)明內(nèi)容稍多可通過(guò)彈窗描述。

舉例：唯品會(huì)App我的訂單列表中，支持退換商品有“7天退換”的標(biāo)簽，而不支持的則有“不支持換貨?”文字按鈕，點(diǎn)擊按鈕會(huì)有彈窗說(shuō)明。

e 點(diǎn)擊展開(kāi)

默認(rèn)展示摘要內(nèi)容，將重要信息收起，可展開(kāi)查看更多。

舉例：美團(tuán)外賣App進(jìn)入商家頁(yè)面，了解更多詳細(xì)介紹通過(guò)點(diǎn)擊展開(kāi)可以查看。

1.1.3 進(jìn)一步操作

一個(gè)操作流可以是一個(gè)單一操作，比如點(diǎn)擊首頁(yè)標(biāo)簽欄跳到首頁(yè)頁(yè)面；也可以是多個(gè)單一操作構(gòu)成的長(zhǎng)流程，比如微信聊天選擇視頻通話后讓你選擇是視頻還是語(yǔ)音。

我們常碰到當(dāng)我們進(jìn)行某個(gè)操作時(shí)，會(huì)有新的操作反饋給我們，選擇其中一個(gè)操作后繼續(xù)進(jìn)行下一步操作。

a 上拉菜單（動(dòng)作面板）

上拉菜單包含多個(gè)操作，選擇某個(gè)操作后流程并未終止，進(jìn)一步明確了操作。

舉例1：微信點(diǎn)擊視頻聊天，上拉菜單選擇語(yǔ)音或視頻。

舉例2：網(wǎng)易郵箱打開(kāi)某個(gè)郵件后進(jìn)行更多操作。

b 操作列表

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

舉例：企業(yè)微信點(diǎn)擊上傳文件，進(jìn)一步讓用戶選擇從本地上傳還是微盤上傳。

c 彈窗

需要二次確認(rèn)可以使用彈窗。

舉例：企業(yè)微信選擇要上傳的文件后，彈窗讓用戶確認(rèn)是否發(fā)送，同時(shí)彈窗上有輸入框可以添加附加留言。

d 浮層菜單

將更多操作合并到浮層菜單中，浮層菜單緊貼著觸發(fā)按鈕，浮層菜單無(wú)遮罩背景。

舉例1：微信點(diǎn)擊右上角的“+”圖標(biāo)。

舉例2：美外賣App點(diǎn)擊更多頁(yè)簽欄。

e 編輯菜單

通常通過(guò)長(zhǎng)按（Android系統(tǒng)常應(yīng)用的交互動(dòng)作）呼出編輯菜單，編輯菜單可以水平方向排布操作也可以垂直方向。

舉例1：微信長(zhǎng)按某聊天（Android系統(tǒng)），呼出編輯菜單。

舉例2：微信公眾號(hào)文章（Android系統(tǒng)），長(zhǎng)按一段文字彈出水平編輯菜單，可以進(jìn)行復(fù)制或搜索。

f 左滑菜單

通過(guò)向左滑動(dòng)觸發(fā)更多操作。

舉例：網(wǎng)易郵箱App郵件列表向左滑動(dòng)。

g 工具欄

工具欄一般位于頁(yè)面底部。

舉例：企業(yè)微信App聊天窗口多選記錄，底部出現(xiàn)工具欄進(jìn)行更多操作。

1.1.4 中斷操作流

用戶在操作過(guò)程，比如因?yàn)樽陨硪蛩刂鲃?dòng)中斷流程；比如填寫(xiě)表單覺(jué)得太繁瑣用戶自己選擇關(guān)閉。

不管因?yàn)槟姆N因素中斷，反饋的要點(diǎn)是告知用戶中斷風(fēng)險(xiǎn)或解決方案。

a 彈窗

舉例1：美團(tuán)App取消訂單進(jìn)行了二次確認(rèn)并提供訂單信息修改入口。

舉例2：微博輸入一大段文字后取消發(fā)布會(huì)有危險(xiǎn)操作提醒。

1.2 操作過(guò)渡

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

「加載反饋」有頁(yè)面進(jìn)度條、頁(yè)面加載、模態(tài)加載、骨架屏、狀態(tài)切換等。

a 頁(yè)面進(jìn)度條

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

常應(yīng)用于h5頁(yè)面。

舉例：去哪兒點(diǎn)擊頁(yè)面頭部的Banner，頁(yè)面進(jìn)度條告知頁(yè)面加載情況。

b 頁(yè)面加載

進(jìn)入一個(gè)新的頁(yè)面，該頁(yè)面結(jié)構(gòu)單一，可以用空白頁(yè)面加載動(dòng)畫(huà)的形式加載，加載動(dòng)畫(huà)位于頁(yè)面的中心，可以是常規(guī)傳統(tǒng)的轉(zhuǎn)菊花、轉(zhuǎn)圈圈，也可以結(jié)合App品牌形象設(shè)計(jì)有趣的加載動(dòng)畫(huà)。

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

c 模態(tài)加載

頁(yè)面加載和模態(tài)加載這2種反饋模式是近親，不同的就是頁(yè)面加載將加載動(dòng)畫(huà)嵌在空白頁(yè)面上，而模態(tài)加載則是將加載動(dòng)畫(huà)嵌在置于頁(yè)面上層的模態(tài)框上，什么場(chǎng)景用頁(yè)面加載，什么場(chǎng)景用模態(tài)加載，具體情況具體分析，下面的案例就是一種情況。

舉例：以下案例的前置操作是在『降價(jià)提醒頁(yè)面』點(diǎn)擊「新增降價(jià)提醒按鈕」，進(jìn)入『新增降價(jià)提醒頁(yè)面』后返回上個(gè)頁(yè)面，這里進(jìn)入『新增降價(jià)提醒頁(yè)面』用的是“頁(yè)面加載”方式，在『新增降價(jià)提醒頁(yè)面』還未加載完成就返回上個(gè)頁(yè)面，此時(shí)還是用“頁(yè)面加載”的方式，從一個(gè)空白加載頁(yè)面到另外一個(gè)空(yi)白(mo)加(yi)載(yang)的頁(yè)面，會(huì)讓用戶以為自己沒(méi)點(diǎn)到返回按鈕，是不是返回失敗了。所以這里返回上個(gè)頁(yè)面采用“緩存結(jié)果+模態(tài)加載”的形式。

d 骨架屏

進(jìn)入一個(gè)新頁(yè)面，該頁(yè)面內(nèi)容結(jié)構(gòu)而有規(guī)律，可以用骨架屏的形式加載頁(yè)面。

骨架屏根據(jù)頁(yè)面結(jié)構(gòu)設(shè)計(jì)一個(gè)骨架圖，用灰色塊代替文字和圖片，看起來(lái)像骨架支撐了頁(yè)面，因此這種加載形式可以叫骨架屏。

在頁(yè)面完全加載完之前，都展示骨架屏，加載完后顯示內(nèi)容。

舉例：查看去哪兒的低價(jià)機(jī)票，新頁(yè)面是較為規(guī)整的頁(yè)面（可以結(jié)構(gòu)化），采用的便是骨架屏的加載方式。

我們看到加載完成后的頁(yè)面如下：

e 狀態(tài)切換

除了以上4種過(guò)渡加載方式，還有一種“狀態(tài)切換”方式，前文提到過(guò)，“狀態(tài)切換”多為組件的狀態(tài)切換，操作過(guò)渡最常應(yīng)用的組件就是按鈕，參看案例。

舉例1：在支付寶支付付款環(huán)節(jié)，校驗(yàn)指紋會(huì)加載等待一會(huì)，校驗(yàn)前“待校驗(yàn)狀態(tài)”，指紋按下后是“校驗(yàn)中狀態(tài)”。

指紋校驗(yàn)狀態(tài)切換如下：

舉例2：指紋校驗(yàn)成功后要請(qǐng)求借口完成扣款請(qǐng)求，在請(qǐng)求的過(guò)程中發(fā)生等待，這里支付按鈕便從“默認(rèn)可點(diǎn)擊狀態(tài)”切換為“支付中狀態(tài)”進(jìn)行請(qǐng)求過(guò)渡，完成無(wú)縫銜接。

支付按鈕狀態(tài)切換如下：

1.3 操作結(jié)果

不管是單一操作，還是復(fù)雜、流程較長(zhǎng)的操作，操作結(jié)果的反饋主要覆蓋“結(jié)果校驗(yàn)”、“結(jié)果審核”、“結(jié)果成功”、“結(jié)果失敗”這4個(gè)場(chǎng)景。

1.3.1 結(jié)果校驗(yàn)

當(dāng)我們?cè)谔顚?xiě)表單時(shí)、提交重要資料時(shí)、在商城發(fā)表自己的購(gòu)買評(píng)論時(shí)… …凡是涉及到用戶輸入和選擇的操作，都存在對(duì)信息的校驗(yàn)。

校驗(yàn)會(huì)有事先擬定好的校驗(yàn)規(guī)則，比如必填項(xiàng)不能漏填、上傳的文件大小不能超過(guò)XM、評(píng)論的字?jǐn)?shù)不能超過(guò)XXX字等等。

此部分只討論通過(guò)對(duì)結(jié)果的校驗(yàn)告知用戶錯(cuò)誤來(lái)源，讓用戶知道為什么出錯(cuò)并進(jìn)行修正。用戶操作成功的反饋將在“3.3結(jié)果成功”中討論。

這里不討論校驗(yàn)的過(guò)程（因校驗(yàn)而產(chǎn)生的等待在“2、操作過(guò)渡”中有分析，這里只討論檢驗(yàn)的錯(cuò)誤結(jié)果）。

a Toast

Toast是常用的信息校驗(yàn)提示方式，因?yàn)樗驍_程度較低，對(duì)出現(xiàn)的時(shí)間可以進(jìn)行調(diào)整，一般設(shè)定為2～3秒。

舉例：在美團(tuán)外賣App新增收獲地址，不填寫(xiě)內(nèi)容即提交，Toast提醒錯(cuò)誤信息。

b 狀態(tài)切換

在一些頁(yè)面中，最終提交按鈕默認(rèn)置灰處理，待用戶表單填寫(xiě)完畢或上傳完資料后，按鈕變?yōu)榭牲c(diǎn)擊狀態(tài)，點(diǎn)擊按鈕提交后再對(duì)填寫(xiě)的信息或資料進(jìn)行校驗(yàn)，組件的狀態(tài)切換也是對(duì)用戶的一種反饋提醒。

舉例：滴滴金融App，注冊(cè)流程設(shè)置登錄密碼，提交按鈕默認(rèn)是置灰的，只有輸入的內(nèi)容符合規(guī)則了，“確定”按鈕才可點(diǎn)擊提交。

c 實(shí)時(shí)校驗(yàn)

實(shí)時(shí)校驗(yàn)就是對(duì)用戶輸入或選擇的內(nèi)容進(jìn)行實(shí)時(shí)校驗(yàn)，輸入不符合規(guī)則即給出反饋。

舉例：參看“3.1、結(jié)果校驗(yàn) – b.狀態(tài)切換”案例。

1.3.2 結(jié)果等待

這種場(chǎng)景并不常見(jiàn)，但實(shí)際確實(shí)會(huì)碰上用戶提交操作后需要用戶等待一定的時(shí)間（短則幾個(gè)小時(shí)，長(zhǎng)則幾天）才能最終獲得最終結(jié)果的場(chǎng)景，比如申請(qǐng)商城申請(qǐng)退換貨后需要系統(tǒng)審核。

“1.3.2 結(jié)果等待”和“1.2 操作過(guò)渡”的設(shè)計(jì)目標(biāo)均是減緩用戶因等待而產(chǎn)生的焦慮，但本質(zhì)不同，其差異性如下：

• 「操作過(guò)渡」是短暫的過(guò)渡，用戶只需等待短短幾秒或幾十秒；「結(jié)果等待」時(shí)間較長(zhǎng)，無(wú)法采用「操作過(guò)渡」的加載方案
• 「操作過(guò)渡」等待完成后可以馬上進(jìn)入到下個(gè)流程；「結(jié)果等待」常出現(xiàn)在流程較長(zhǎng)、信息量較大的操作中，「結(jié)果等待」出現(xiàn)后即表示現(xiàn)階段流程的完成

在用戶提交資料審核后才能正常使用App的場(chǎng)景中，能避免結(jié)果審核盡量避免，因?yàn)樽層脩糸L(zhǎng)時(shí)間的等待意味著流失的可能性越大，對(duì)于一定要經(jīng)過(guò)審核的流程，一方面要縮短審核的時(shí)間，另一方面優(yōu)化審核的算法，爭(zhēng)取能夠在最短的時(shí)間內(nèi)容給出結(jié)果（失敗or成功）。

常見(jiàn)的設(shè)計(jì)模式為：

a 結(jié)果頁(yè)

舉例：在某App中，用戶提交還款申請(qǐng)后，需要等待銀行處理后再返回還款成功的結(jié)果。

1.3.3 結(jié)果成功

我們這里討論的成功的操作反饋是「有形」的反饋體現(xiàn)，比如你在購(gòu)物支付訂單完成后，有一個(gè)專門的支付成功結(jié)果頁(yè)展示。

「無(wú)形」的反饋這里不進(jìn)行討論，比如你搜索內(nèi)容，搜索成功后即自動(dòng)將搜索結(jié)果展示出來(lái)，而不用再給你一個(gè)「有形」的專門提示（比如Toast）告知你搜索成功了。

a Toast

單一操作或整個(gè)流程的操作成功結(jié)果告知，2～3秒后消失，不干擾用戶當(dāng)前行為。

舉例：微信復(fù)制一段文字，復(fù)制完畢后提示“已復(fù)制”（Android系統(tǒng)）。

b Snackbar

Snackbar和Toast差異之一是Snackbar上可以進(jìn)行其他操作。

根據(jù)需要選擇使用Toast或Snackbar。

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

c 結(jié)果頁(yè)

對(duì)于包含重要信息、多步驟的長(zhǎng)流程，最終操作成功用一個(gè)結(jié)果頁(yè)較為合適，結(jié)果頁(yè)的優(yōu)點(diǎn)是可以最大面積的呈現(xiàn)其他內(nèi)容或其他操作。

舉例：支付寶轉(zhuǎn)賬成功。

d 彈窗

彈窗的打擾較強(qiáng)，當(dāng)有重要信息需要用戶停留查看時(shí)可用彈窗。

舉例：美團(tuán)App支付成功后彈窗告知支付成功，同時(shí)彈窗附加了贈(zèng)券信息。

e 狀態(tài)切換

能在當(dāng)前頁(yè)面通過(guò)狀態(tài)切換告知用戶操作成功，那就最好不過(guò)了。

舉例：在企業(yè)微信傳輸文件給對(duì)方，點(diǎn)擊發(fā)送后，狀態(tài)從“發(fā)送中…”切換為“發(fā)送成功”。

f 動(dòng)畫(huà)

以動(dòng)畫(huà)的形式表示操作成功。

舉例1：豆瓣App文章點(diǎn)贊成功。

舉例2：荔枝App音頻點(diǎn)贊成功。

1.3.4 結(jié)果失敗

在3.1我們討論了若用戶提交的信息有誤，需要對(duì)錯(cuò)誤結(jié)果進(jìn)行反饋提示。

3.1描述的場(chǎng)景針對(duì)校驗(yàn)的場(chǎng)景，3.4結(jié)果失敗我們討論一些因?yàn)楫惓?chǎng)景或其他原因所導(dǎo)致的失敗場(chǎng)景，異常狀態(tài)包含網(wǎng)絡(luò)異常、流量告警、服務(wù)器異常、加載失敗、空狀態(tài)、內(nèi)容重建等。

更多閱讀：《關(guān)于異常狀態(tài)的設(shè)計(jì)總結(jié)》

結(jié)果失敗的反饋模式常見(jiàn)的有以下幾種：

a 缺省頁(yè)

當(dāng)用戶操作進(jìn)入App新的頁(yè)面時(shí)，常以缺省頁(yè)的形式提醒用戶當(dāng)前網(wǎng)絡(luò)異常、服務(wù)器異常或狀態(tài)為空。

舉例：比如網(wǎng)易云音樂(lè)在無(wú)網(wǎng)絡(luò)連接下，進(jìn)入新頁(yè)面時(shí)，缺省頁(yè)以簡(jiǎn)單的文案告知當(dāng)前無(wú)網(wǎng)絡(luò)，通過(guò)點(diǎn)擊查看詳情告知用戶解決方案以及引導(dǎo)如何解決問(wèn)題。

b 彈窗

用戶在當(dāng)前頁(yè)面進(jìn)行點(diǎn)擊操作時(shí)，比如上拉加載頁(yè)面、下拉刷新頁(yè)面，點(diǎn)贊、關(guān)注等操作時(shí)，操作失敗時(shí)常以彈窗或Toast的形式提示用戶，同時(shí)告知原因并給出解決方案。

舉例：網(wǎng)易云音樂(lè)，網(wǎng)絡(luò)異常情況下下拉刷新或上拉加載頁(yè)面均進(jìn)行對(duì)話框提示，并引導(dǎo)用戶檢查網(wǎng)絡(luò)權(quán)限設(shè)置。

c? Toast

舉例：無(wú)網(wǎng)絡(luò)連接環(huán)境下，在我的訂單頁(yè)面進(jìn)行評(píng)價(jià)操作，會(huì)進(jìn)行Toast提示。

d 結(jié)果頁(yè)

對(duì)于包含重要信息、多步驟的長(zhǎng)流程，最終操作成功用一個(gè)結(jié)果頁(yè)較為合適，對(duì)應(yīng)失敗結(jié)果也是設(shè)計(jì)為結(jié)果頁(yè)（一致性原則）。

舉例：在某App中，用戶因扣款賬戶余額不足導(dǎo)致還款失敗，還款列表記錄了還款失敗的記錄，進(jìn)入詳情頁(yè)可看到還款失敗結(jié)果頁(yè)。

e 狀態(tài)切換

能在當(dāng)前頁(yè)面通過(guò)狀態(tài)切換告知用戶操作失敗，那就選擇該種方式。

舉例：微信消息發(fā)送失敗，發(fā)送內(nèi)容的左邊有一個(gè)“紅色感嘆號(hào)”的實(shí)心圖標(biāo)，意味著該消息發(fā)送失敗。

f Snackbar

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

舉例：同上案例，（Android系統(tǒng)）微信聊天消息發(fā)送失敗的同時(shí)收到Snackbar反饋，在Snackbar上可以忽略也可以進(jìn)行重新發(fā)送操作。

2. 被動(dòng)接收反饋信息

用戶被動(dòng)接收反饋信息主要由他人或系統(tǒng)觸發(fā)，場(chǎng)景有：

• 他人發(fā)送消息給我，比如微信有人給我發(fā)文字、語(yǔ)音、紅包或文件等，社交App常有的場(chǎng)景
• 系統(tǒng)主動(dòng)給用戶推送消息，比如功能更新、功能重建、系統(tǒng)公告、條款更新、消息動(dòng)態(tài)更新等，一般App中都會(huì)出現(xiàn)該場(chǎng)景

常見(jiàn)的反饋模式有通告欄、紅點(diǎn)、標(biāo)簽等：

舉例：去哪兒的機(jī)票退款進(jìn)度更新、系統(tǒng)通知更新采用紅點(diǎn)的形式告知我，要實(shí)名認(rèn)證則以通告欄的形式提醒我。

如下用箭頭標(biāo)出的地方：

三、反饋設(shè)計(jì)原則

通過(guò)以上實(shí)際案例的分析，我們對(duì)App中反饋場(chǎng)景對(duì)應(yīng)的設(shè)計(jì)目標(biāo)和設(shè)計(jì)模式更加了然于心，當(dāng)然，以上反饋模式包含但不限于，相應(yīng)的反饋場(chǎng)景不除外有更好的反饋模式。

這不是一份標(biāo)準(zhǔn)答案，反饋模式只是一種外在表現(xiàn)形式，只要能夠達(dá)到反饋目標(biāo)，也可以選擇更優(yōu)方案。

案例中提到的反饋模式都是基于App內(nèi)部的，除了App內(nèi)部的反饋模式，還應(yīng)該考慮到App外部的反饋模式，比如：短信、手機(jī)通知、郵件、微信公眾號(hào)等，這里不詳細(xì)展開(kāi)。

最后，一起看下我們?cè)谶M(jìn)行反饋設(shè)計(jì)時(shí)需要遵循一些設(shè)計(jì)原則。

1. 反饋?lái)憫?yīng)及時(shí)

反饋結(jié)果應(yīng)及時(shí)告知用戶，試想用戶付完款后沒(méi)有付款成功的反饋，用戶心里該多著急。

2. 反饋避免打擾

采用的反饋模式盡可能將對(duì)用戶當(dāng)前操作的打擾程度降到最低，比如對(duì)于用戶容易頻繁填錯(cuò)信息的界面，一方面要考慮如何降低用戶的出錯(cuò)率，另一方面用戶出錯(cuò)后不采用打擾程度最高的彈窗而是采用輕量提示Toast。

3. 反饋模式合理

雖然我們?cè)谠O(shè)計(jì)反饋時(shí)會(huì)考慮避免打擾用戶，但在對(duì)應(yīng)的場(chǎng)景應(yīng)選擇最合理的反饋模式，比如用戶的危險(xiǎn)操作用打擾程度較高的彈窗，因?yàn)閺棿皩?duì)用戶的警示性會(huì)更強(qiáng)，用Toast的話用戶反而會(huì)不重視。

End

通過(guò)對(duì)反饋場(chǎng)景和設(shè)計(jì)原則的梳理，結(jié)合實(shí)際案例，我對(duì)反饋模式的應(yīng)用有了更深的理解。

你呢？

作者：辛小仲；一名正在成長(zhǎng)的交互設(shè)計(jì)師，公眾號(hào)：辛小仲。

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

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