本文作者通過一個例子來思考設計背後邏輯，與你分享~enjoy~
當用戶點擊某個操作時，由於某種原因會導致此操作失敗，這時候就需要出現反饋提示來告知用戶原因。反饋提示通常會有多種表現樣式。
有時候多種樣式都可以使用，那麼到底應該使用哪種樣式呢？我們應該怎麼去理解這些樣式，以及它背後的設計邏輯？
微信中，給對方發送圖片時，微信限制只能發送九張。當用戶選擇了九張時，用戶再次選擇時，會提示用戶最多隻能選擇九張。對此iOS版使用的是警示框，Android版使用的是toast。
至於微信為什麼限定只能最多選擇九張，我猜測是為了遵從朋友圈動態九張圖。因為朋友圈如果不限定的話，用戶惡意平鋪很多張，對別人瀏覽朋友圈的話是一種信息噪音。同時，九宮格是一種和諧的視圖模式。
同理，微信對話發圖片也統一了規則，這樣也同時避免對方惡意大批量的發圖片。
關於為什麼iOS 版本用警示框，Android 版本用toast的背後設計邏輯？
這裡有我的一個猜測：
微信iOS版，當用戶選擇了9張時，再次選擇第10張，給出強阻斷的警示框，用戶需要點擊警示框中的按鈕操作。這個過程加強了用戶的記憶和操作成本，有了之前的強提示，用戶下次選擇超過9張有印象，避免用戶再次犯錯。
微信Android版，當用戶選擇了9張時，再次選擇第10張，給出較輕量的toast。這個過程是在減輕用戶犯錯的成本。用戶只需要等1-2s後再次輸入賬號或密碼就可以。方便了用戶當前操作，卻沒有防止用戶以後犯錯。
針對iOS 和Android版微信的選擇圖片場景，打一個不恰當的比方：
有一個家長針對自己的小孩（用戶）犯錯。iOS版的家長選擇在犯錯的時，進行比較重的教育，讓孩子記憶和影響加深，使其改正行為，防止以後再次犯錯誤。而Android版的家長進行比較輕的教育僅僅提供提示，用戶的犯錯成本較低，感知比較好，但未起到以後的防錯的作用。
以登錄賬號密碼不匹配為例，來全面淺析設計背後的邏輯
用戶使用App進行登錄時，當賬號密碼不匹配，會出現錯誤提示。目前市面上的提示有三種。分別為警示框、toast和對象內嵌。
首先說下使用場景，登錄賬號屬於超低頻的操作。現在app都將退出賬號的路徑做的比較深，以此減少用戶退出賬號。這樣的好處是可以讓用戶更方便的體驗產品，增加產品的使用時長和使用深度。
1. 警示框
警示框為阻斷式操作，屬於強提示。告知用戶賬號密碼不匹配，用戶需要點擊警示框上的按鈕才能重新輸入賬號或密碼。
微信、QQ、Instagram在登錄賬號密碼不匹配時，使用的都是警示框。需要用戶點擊警示框按鈕才可以再次輸入。輸入強制性操作。
我之前想過這樣做的作用是否為了安全，通過點擊警示框按鈕，提高操作門檻使得盜號者大規模破解運算猜密碼。再仔細一想這個猜測不合理。設計者可以通過限制登錄來保證安全性。例如用戶輸入密碼錯誤五次開始限制五分鐘後再輸入。
2. toast
toast為短暫的提示性組件，當用戶點擊登錄時，提交給系統，系統發現賬號密碼不匹配，通過toast提示告知用戶，一般停留1-2s，之後消失。屬於輕量級提示。
京東、UC瀏覽器、貓眼在登錄賬號密碼不匹配時，使用的都是toast提示。通過一個輕量的反饋讓用戶知道登錄失敗的原因。用戶不需要任何操作，可以繼續在輸入框裡填寫。方便用戶當前操作。
3. 對象內嵌
當用戶點擊登錄時，提交給系統，發現賬號密碼不匹配，系統通過在界面中內嵌文字提示告知用戶，此提示一般提示為帶顏色的醒目文字。一般一直停留不會消失，屬於更輕量級提示。
用戶輸入賬號密碼時，點擊登錄，數據返回到服務器。服務器可以做以下兩種判斷：
- 賬號不存在存在，賬號不存在的話，給出對應賬號不存在提示。
- 賬號存在的話，賬號是否和密碼匹配。如果不匹配的話，給出對應提示。
Chrome瀏覽器、百度網盤在登錄賬號密碼不匹配時，使用的都是對象內嵌的方式。通過界面中的文字反饋讓用戶知道登錄失敗的原因。用戶不需要任何操作，可以繼續在輸入框裡填寫，方便用戶當前操作。
分析與總結
以上三個提示類型強烈程度分別為：警示框 > toast > 對象內嵌
那麼作為設計師，讓你設計一些錯誤的提示，你會選擇哪種呢？
無論選擇哪種提示，首先說明這裡沒有對與錯，只有適不適合，這裡的適不適合是指是否適合你的自我產品的定位和產品的設計理念。
如果你整個產品考慮的是更深的產品邏輯與防錯，可以選擇強制性的警示框。
有的設計者/產品經理覺得警示框太強制了。為什麼還要用戶去點擊一下，才能再輸入呢？就喜歡採取toast導致整個產品很多都是toast，但過多的toast，用戶習慣之後很容易忽略掉toast的提示，未起到真正的防錯和提示。
而對象內嵌，則更為輕量。而且擴展性強，可以承載更多的信息。對於需要考慮拓展性和免打擾用戶來說是不錯的設計選擇。
#專欄作家#
UX，微信公眾號：UEDC，人人都是產品經理專欄作家。華為ITUX交互組組長。
本文原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels，基於 CC0 協議