本文作者將結(jié)合設(shè)計規(guī)范及自身的項目經(jīng)歷，將提示方式的使用場景及界限給總結(jié)出來，希望對大家以后處理提示方式時有些參考和幫助。enjoy~

　　如何減少打擾用戶的次數(shù)甚至不打擾用戶，是每一個用戶體驗設(shè)計師應該考慮的事。相信很多設(shè)計師都曾糾結(jié)于何時用對話框和Toast來做提示。兩者大的區(qū)別是對話框是一種帶有操作的提示，需要用戶操作后才會消失，這會直接打斷用戶的流程;Toast屬于輕量提示，不帶操作，顯示幾秒后自動消失，不會打斷用戶操作。

　　除了以上兩種形式，還衍生出Toast+操作的提示，如：

　　以及用Toast+圖標或浮層的提示，如：

　　以上設(shè)計都有亮點及合理的地方，但如何合適使用不打擾用戶才是關(guān)鍵。怎么才算合理是一個問題，因為每個設(shè)計師的看法都有自己的主觀評判標準，但這些標準在用戶身上往往只有兩個結(jié)果，良好的體驗和差勁的體驗。在這里我結(jié)合設(shè)計規(guī)范及自身的項目經(jīng)歷，將提示方式的使用場景及界限給總結(jié)出來，希望對大家以后處理提示方式時有些參考和幫助。

　　iOS設(shè)計規(guī)范

　　先從iOS設(shè)計規(guī)范開始，iOS推薦設(shè)計師使用橫幅，對話框和小氣泡的形式來提示用戶，但不推薦設(shè)計師經(jīng)常使用對話框的提示形式。只有這三種提示方式是明顯不夠的，但規(guī)范里允許設(shè)計師將提示功能與APP自身結(jié)合，建立更符合場景的提示機制。有很多設(shè)計師會將Android的Toast概念直接引入iOS設(shè)計中，以及衍生出Toast+操作，浮層等提醒方式。由于iOS對此沒有明確的設(shè)計規(guī)范，只要是設(shè)計合理的，怎么提示都行。

　　Material Design設(shè)計規(guī)范

　　相對于iOS設(shè)計規(guī)范，Material Design以更謹慎的態(tài)度設(shè)計了提示用戶的規(guī)范，并歸納出兩個非常棒的概念：確認(Confirm)及確知(Acknowledge)。

　　確認是要求用戶確認自己確實希望執(zhí)行剛才所調(diào)用的操作。在某些情況下，確認隨需要用戶考慮的操作所相關(guān)的警告或關(guān)鍵信息一起顯示。

　　確知就是顯示一段文字信息，讓用戶知道自己剛才調(diào)用的操作已經(jīng)完成。這將消除系統(tǒng)正在執(zhí)行的隱式操作的不確定性。在某些情況下，確知隨撤消操作的選項一起顯示。

　　在Material Design規(guī)范里，提示只有對話框(確認)及Toast(確知)和Snackbar(確知)，同理對話框也是一種非常強的提示方式，會直接打斷用戶操作，所以設(shè)計時要謹慎對待。

　　這里要闡述一下Toast，在規(guī)范里是規(guī)定只有文字，是不能配圖標的，所以配圖的就不應該叫Toast了，這種樣式可以直接理解為一種浮層。同時，Toast也是不能帶操作的，如果配操作的，在Material Design里被稱為Snackbar，這是Android 5.0新出的控件。Snackbar 是一種針對操作的輕量級反饋機制，常以一個小的彈出框的形式，出現(xiàn)在手機屏幕下方或者桌面左下方。它們出現(xiàn)在屏幕所有層的上方，包括浮動操作按鈕，它同Toast一樣3秒后消失。三種樣式比較：

　　Google也給出了何時需要確認或確知用戶操作。以下為我的翻譯：

　　如果每次做設(shè)計時都走一遍上述的流程估計大家都會懵逼吧，我以提示的重要性將提示的界限及場景舉例出來。為了更好區(qū)分專業(yè)術(shù)語及iOS和Android的差異，提出了一些新詞語，如果有誤請指正。

　　重要程度(從高往低)：

　　1、對話框(需要突出提示或存在兩個操作按鈕以上的提示，影響現(xiàn)流程。)

　　適用場景：

　　需要重大決定的場景

　　容易引起誤操作的場景

　　需要確認的場景

　　引導到其他流程的場景

　　運營方案

　　樣式說明：

　　對話框在界面整體居中顯示

　　對話框文案應盡量簡短，結(jié)尾不使用標點符號

　　對話框可以針對運營活動或不同場景下進行樣式設(shè)計

　　必須提供關(guān)閉、取消等回到原流程的按鈕

　　(2)輕操作(適用于輕量提示時帶有操作，如撤銷、查看、增添、修改數(shù)據(jù)，不影響現(xiàn)流程。)

　　*輕操作在Android里是Snackbar，在iOS里沒有相關(guān)定義

　　適用場景：

　　用于撤銷場景：①刪除操作(簡化刪除流程里彈出對話框的流程);②用于做出重大決定后的撤銷操作，如清空全部數(shù)據(jù)和取消綁卡;

　　用于查看，添加，修改等打斷現(xiàn)流程的操作，如①收藏后查看落地頁;②收藏后修改存放的文件夾。

　　樣式說明：

　　Android Snackbar顯示時長為3秒;iOS為自定義

　　Android Snackbar顯示在頁面底部;iOS為自定義，左右居中顯示

　　輕操作文案應為陳述句且盡量簡短，結(jié)尾不使用標點符號

　　(3)浮層(適用于如日夜間模式，隱私模式等帶有功能性質(zhì)的輕量提示，不影響現(xiàn)流程。)

　　適用場景：

　　功能(模式)：日夜間模式;隱私模式;無圖模式;xxx模式

　　重要提示：支付成功/失敗;支付loading(顯示時長由自身決定)

　　樣式說明：

　　浮層結(jié)構(gòu)為icon+文案或占整個頁面

　　若干秒后自動消失

　　浮層顯示在界面整體居中顯示

　　浮層文案應盡量簡短，結(jié)尾不使用標點符號

　　(4)Toast(適用于如引起其他頁面和系統(tǒng)數(shù)據(jù)發(fā)生變化、失敗操作的輕量提示，不影響現(xiàn)流程。)

　　適用場景：

　　操作失敗(網(wǎng)絡(luò)異常)

　　頁面內(nèi)數(shù)據(jù)添、刪除加成功導致其他頁面數(shù)據(jù)發(fā)生變化，如推薦新聞

　　無法操作時的輕量提示

　　其他頁面數(shù)據(jù)發(fā)生變化，如下載完成、失敗

　　樣式說明：

　　Android Toast使用系統(tǒng)默認樣式;，iOS Toast使用自定義樣式

　　Android Toast顯示時長為3秒;iOS為自定義

　　Android Toast顯示在頁面底部且左右居中，iOS Toast為自定義

　　Toast文案應為陳述句且盡量簡短，結(jié)尾不使用標點符號;

　　(5)無提示(操作后頁面有明顯的變化且不會對用戶其他方面造成影響，不影響現(xiàn)流程。)

　　適用場景：頁面內(nèi)數(shù)據(jù)添加，刪除成功

　　哪個場景下給提示?

　　哪個場景下不給提示?

　　這也是一個很好的問題。

　　舉個刪除單條歷史記錄的例子，如果歷史記錄與用戶其他信息無耦合，在刪除一條時，頁面里明顯消失了該條記錄，這已經(jīng)是一個很明顯的提示了，這時候就不需要再彈Toast告知了。

　　舉個個性化推薦的例子，由于每條數(shù)據(jù)都和其他數(shù)據(jù)耦合在一起，如果用戶刪除一條數(shù)據(jù)時，他的目的不僅僅是刪除這條數(shù)據(jù)，還有對于這類數(shù)據(jù)不感興趣，雖然頁面里明顯消失了該條數(shù)據(jù)，但也需要告知用戶再也不推薦類似消息了。

　　舉個取消關(guān)注的例子，用戶是對該內(nèi)容源不感興趣才確認取消關(guān)注的，但很多應用都覺得用戶好像不知道取消關(guān)注后再也收不到相關(guān)內(nèi)容源了，一定要用對話框告訴用戶“取消關(guān)注后就再也收不到相關(guān)內(nèi)容”，簡直加大了用戶取消關(guān)注的阻力(這就是產(chǎn)品經(jīng)理希望的)?？梢試L試用snackbar的形式，當用戶取消關(guān)注后，彈出一條snackbar，告訴用戶“再也不關(guān)注該內(nèi)容源”，后面增加一個撤銷。當用戶真的是誤操作時，他可以選取撤銷重新添加該內(nèi)容源，不是的話，也減少了用戶再次確認的步驟，體驗上比對話框形式好很多。

　　提示很簡單，但如何使用和設(shè)計起來還真的有點難度，希望看完后對大家以后使用提示時有所幫助。