有朋友公眾號留言，主要討論類似上篇［禁用按鈕展示邏輯］中最後一個案例，表單未完全填充情況下提交按鈕的狀態，是高亮還是置灰？相關問題討論的也比較多，簡單整理隨筆回答一下。

提出這個問題的背後，無非隱藏著對兩種狀況的權衡：

選擇置灰，

表單填寫場景，一旦出現模組漏填或控制元件漏選的狀況，無法準確定位，使用者完全處於無能為力的處境，特別對於長表單，只能將填寫資訊上下不停掃視來找出提交按鈕不能用的原因。

選擇高亮

，積極的隱喻暗示可隨時提交的動作，但對於空表單或未完全填充的長表單，一旦觸發，全域性校驗帶來的報錯則顯得冗餘。

表面看是按鈕狀態的選擇，本質上還是資訊輸入過程中的節奏控制以及如何給予恰當的提示避免操作迷失。表單的場景差異很大，文無定法，我們不能追求用同樣的原理去解釋所有的現象，沿著這個思路，嘗試回答這個問題。

先說觀點：對於輸入為主的表單場景，提交功能以提升操作效率為目標；對於驗證為主的表單場景，提交的正向積極的引導優先順序更高。

資訊輸入為主的表單，效率是目標

通常意義來講，移動場景中這類表單一般都處於資訊層級中的第2級或者更次級，使用者從功能入口［舉例如：補充資訊/填寫地址/資訊驗證等］點選進來都有較為明確的操作預期。圍繞效率來說，減少干擾&準確反饋應該是著重關注點。梳理互動路徑，操作之前，優先順序應是引導使用者關注任務本身，而非提交，所以底部按鈕無需高亮，高亮了反而會帶來無效的冗餘報錯。

啟動輸入意味著任務開始，過程可能出現的問題主要有兩種：錯填或漏填。

錯填

主要指內容不符合前端校驗規則，比如格式、數量、字元、亂碼等問題，輸入框本身失去焦點後，具備實時反饋能力，能夠提示錯問題，所以不依賴提交按鈕的觸發。但

漏填

確實是個非常依賴按鈕反饋給予定位才能解決的問題，但從趨勢來看，多餘兩屏資訊項的長表單不太常見，是個小機率事件，我們稍後再討論。圍繞效率優先，兩項權衡，所以這個環節提交按鈕依然無需高亮。

當用戶還差一項即將完成，不管是否符合順序上的最後一項，都意味著整個任務即將結束，儘管此時鍵盤還未退出，仍可告知下一步的承接動作，提交按鈕高亮。

接上說下漏填的問題，如果表單過於複雜，比如融合了選擇控制元件或文字輸入，比如多餘兩屏的資訊項，比如夾雜著必選和可選的差異等等，按鈕的置灰確實無法幫助使用者快速定位問題。此時可以思考調整設計策略，比如下圖也可以解決一部分問題，但從移動終端呈現要求及資訊減負這個趨勢上，這種型別的存在會越來越少。

遇到這類情況，我想最先需要思考的是如何降低表單的複雜度，是否可以重新設計資訊歸類，是否可以流程分拆等，是否可以設定預設選項等等，核心還是迴歸到操作效率上來。

校驗為主的短表單，積極的引導更為重要

通常意義來講，這類表單經常會出現在產品的宣傳/登陸/授權/驗證等啟動應用後的首個環節，以身份驗證為目標，資訊量很少，但是位置感很強，會第一時間產生影響。使用者在填寫或授權資訊前，更多的不是考慮操作難度，而是意向問題，多和品牌和場景感受有關。以悅跑圈為例，動態背景、第三方渠道、手機號作為登陸/註冊的標配功能，從理性的邏輯和操作路徑來看，預設置灰毫無問題［左側方案A為線上方案］，但從開啟APP的第一眼感受上，高亮可能有更為積極的引導意義。即使有點選，也無妨，不會造成批次化的冗餘報錯。

另一類情況更為典型，隨著「使用者服務授權」及「個人隱私政策」的合規落地，典型的校驗環節的運營商手機號需要使用者主動授權才能被使用，這個場景下，為避擴音示協議的忘記勾選，選擇高亮的提交是當前最合適的方案；

如上，類似同一產品體系內的賬號一鍵登入授權也是同樣的道理。

使用者的輸入場景多樣且差異很大，很難用統一的答案去滿足所有的要求。輸入和驗證的邊界也有模糊地帶，所謂的「長」和「短」更是無法直接透過輸入項的數量來定義。上述討論更多是對兩類典型場景的定向討論，概念意義上的中間地帶或者垂類方向的特殊表單還是需要具體問題具體分析。畢竟，體驗問題就是要依賴目標、場景、使用者特點綜合來權衡，不必追求唯一的正確答案。

最後留個問題供大家思考：空表單提交按鈕的不可用狀態，是置灰合適？還是帶有一定顏色透明度的合適呢？為什麼？

以上，謝謝

——————————————————————

圖片授權基於CC0協議