提交功能的状态选择

有朋友公众号留言，主要讨论类似上篇[禁用按钮展示逻辑]中最后一个案例，表单未完全填充情况下提交按钮的状态，是高亮还是置灰？相关问题讨论的也比较多，简单整理随笔回答一下。

提出这个问题的背后，无非隐藏着对两种状况的权衡：选择置灰，表单填写场景，一旦出现模块漏填或控件漏选的状况，无法准确定位，用户完全处于无能为力的处境，特别对于长表单，只能将填写信息上下不停扫视来找出提交按钮不能用的原因。选择高亮，积极的隐喻暗示可随时提交的动作，但对于空表单或未完全填充的长表单，一旦触发，全局校验带来的报错则显得冗余。

表面看是按钮状态的选择，本质上还是信息输入过程中的节奏控制以及如何给予恰当的提示避免操作迷失。表单的场景差异很大，文无定法，我们不能追求用同样的原理去解释所有的现象，沿着这个思路，尝试回答这个问题。

先说观点：对于输入为主的表单场景，提交功能以提升操作效率为目标；对于验证为主的表单场景，提交的正向积极的引导优先级更高。

信息输入为主的表单，效率是目标

通常意义来讲，移动场景中这类表单一般都处于信息层级中的第2级或者更次级，用户从功能入口[举例如：补充信息/填写地址/信息验证等]点击进来都有较为明确的操作预期。围绕效率来说，减少干扰&准确反馈应该是着重关注点。梳理交互路径，操作之前，优先级应是引导用户关注任务本身，而非提交，所以底部按钮无需高亮，高亮了反而会带来无效的冗余报错。

启动输入意味着任务开始，过程可能出现的问题主要有两种：错填或漏填。错填主要指内容不符合前端校验规则，比如格式、数量、字符、乱码等问题，输入框本身失去焦点后，具备实时反馈能力，能够提示错问题，所以不依赖提交按钮的触发。但漏填确实是个非常依赖按钮反馈给予定位才能解决的问题，但从趋势来看，多余两屏信息项的长表单不太常见，是个小概率事件，我们稍后再讨论。围绕效率优先，两项权衡，所以这个环节提交按钮依然无需高亮。

当用户还差一项即将完成，不管是否符合顺序上的最后一项，都意味着整个任务即将结束，尽管此时键盘还未退出，仍可告知下一步的承接动作，提交按钮高亮。

接上说下漏填的问题，如果表单过于复杂，比如融合了选择控件或文本输入，比如多余两屏的信息项，比如夹杂着必选和可选的差异等等，按钮的置灰确实无法帮助用户快速定位问题。此时可以思考调整设计策略，比如下图也可以解决一部分问题，但从移动终端呈现要求及信息减负这个趋势上，这种类型的存在会越来越少。

遇到这类情况，我想最先需要思考的是如何降低表单的复杂度，是否可以重新设计信息归类，是否可以流程分拆等，是否可以设定默认选项等等，核心还是回归到操作效率上来。

校验为主的短表单，积极的引导更为重要

通常意义来讲，这类表单经常会出现在产品的宣传/登陆/授权/验证等启动应用后的首个环节，以身份验证为目标，信息量很少，但是位置感很强，会第一时间产生影响。用户在填写或授权信息前，更多的不是考虑操作难度，而是意向问题，多和品牌和场景感受有关。以悦跑圈为例，动态背景、第三方渠道、手机号作为登陆/注册的标配功能，从理性的逻辑和操作路径来看，默认置灰毫无问题[左侧方案A为线上方案]，但从打开APP的第一眼感受上，高亮可能有更为积极的引导意义。即使有点击，也无妨，不会造成批量化的冗余报错。

另一类情况更为典型，随着「用户服务授权」及「个人隐私政策」的合规落地，典型的校验环节的运营商手机号需要用户主动授权才能被使用，这个场景下，为避免提示协议的忘记勾选，选择高亮的提交是当前最合适的方案；

如上，类似同一产品体系内的账号一键登录授权也是同样的道理。

用户的输入场景多样且差异很大，很难用统一的答案去满足所有的要求。输入和验证的边界也有模糊地带，所谓的「长」和「短」更是无法直接通过输入项的数量来定义。上述讨论更多是对两类典型场景的定向讨论，概念意义上的中间地带或者垂类方向的特殊表单还是需要具体问题具体分析。毕竟，体验问题就是要依赖目标、场景、用户特点综合来权衡，不必追求唯一的正确答案。

最后留个问题供大家思考：空表单提交按钮的不可用状态，是置灰合适？还是带有一定颜色透明度的合适呢？为什么？

以上，谢谢

------------------------------------------

图片授权基于CC0协议