如何設計一個(gè)好的提醒

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

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

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

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

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

　　iOS設計規范

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

　　Material Design設計規范

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

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

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

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

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

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

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

　　重要程度(從高往低)：

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

　　適用場(chǎng)景：

　　需要重大決定的場(chǎng)景

　　容易引起誤操作的場(chǎng)景

　　需要確認的場(chǎng)景

　　引導到其他流程的場(chǎng)景

　　運營(yíng)方案

　　樣式說(shuō)明：

　　對話(huà)框在界面整體居中顯示

　　對話(huà)框文案應盡量簡(jiǎn)短，結尾不使用標點(diǎn)符號

　　對話(huà)框可以針對運營(yíng)活動(dòng)或不同場(chǎng)景下進(jìn)行樣式設計

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

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

　　*輕操作在A(yíng)ndroid里是Snackbar，在iOS里沒(méi)有相關(guān)定義

　　適用場(chǎng)景：

　　用于撤銷(xiāo)場(chǎng)景：①刪除操作(簡(jiǎn)化刪除流程里彈出對話(huà)框的流程);②用于做出重大決定后的撤銷(xiāo)操作，如清空全部數據和取消綁卡;

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

　　樣式說(shuō)明：

　　Android Snackbar顯示時(shí)長(cháng)為3秒;iOS為自定義

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

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

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

　　適用場(chǎng)景：

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

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

　　樣式說(shuō)明：

　　浮層結構為icon+文案或占整個(gè)頁(yè)面

　　若干秒后自動(dòng)消失

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

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

　　(4)Toast(適用于如引起其他頁(yè)面和系統數據發(fā)生變化、失敗操作的輕量提示，不影響現流程。)

　　適用場(chǎng)景：

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

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

　　無(wú)法操作時(shí)的輕量提示

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

　　樣式說(shuō)明：

　　Android Toast使用系統默認樣式;，iOS Toast使用自定義樣式

　　Android Toast顯示時(shí)長(cháng)為3秒;iOS為自定義

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

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

　　(5)無(wú)提示(操作后頁(yè)面有明顯的變化且不會(huì )對用戶(hù)其他方面造成影響，不影響現流程。)

　　適用場(chǎng)景：頁(yè)面內數據添加，刪除成功

　　哪個(gè)場(chǎng)景下給提示?

　　哪個(gè)場(chǎng)景下不給提示?

　　這也是一個(gè)很好的問(wèn)題。

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

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

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

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