A10.06.4Input-time constraints over post-submission validation设计研究

输入端约束优于提交后校验

别名: 输入掩码 · 实时校验 · inline validation

概念解释

输入端约束指在用户输入的过程中就把非法值排除掉——限制输入框只能接受数字、按格式自动分段、超出范围的字符直接输不进去——而不是等用户填完整张表单、点了提交之后,才用一条错误提示告诉他哪里错了。这两者达到的"最终数据合法"的效果可能相同,但用户的经历完全不同:前者让错误在发生的当下就不存在,后者让错误先发生、被记录、再要求用户回头去找、去改。

机制

提交后校验之所以代价更高,是因为它把纠错这件事从"当下"推到了"之后":用户填写第三个字段时的心智状态、对这个字段该填什么的记忆,到填完第十个字段、点击提交才被打断时,已经消散了大半,他需要重新定位到出错的字段、重新调出当时的意图,才能理解错误提示在说什么。输入端约束把这个过程完全消除——非法字符根本打不进输入框,格式错误在输入的瞬间就被自动修正或提示,用户永远不会带着一个已经错了的值走到下一步,纠错发生在意图仍然鲜活的那一刻。

怎么研究

比较两种表单设计下的完成时间与错误恢复行为,是这类研究的常见做法:一组表单采用输入过程中的实时约束与即时反馈,另一组采用传统的填完提交后统一报错,测量的因变量包括总完成时间、单个字段的重复填写次数、以及用户在遇到错误提示后是否能不经多次尝试就定位并修正。这类比较稳定地显示实时约束能缩短完成时间并降低重复出错率,但方法论上要注意区分"约束"与"打扰":如果实时校验在用户还没打完一个词、值尚未成型时就频繁弹出错误提示,反而会打断输入节奏、造成新的困惑,这类研究因此通常需要同时记录用户对实时反馈本身的主观烦躁程度,而不只看客观错误率。

边界

输入端约束依赖于"合法值的范围可以在输入时就被明确判断"这个前提,对于那些合法性取决于跨字段关系(比如两个日期的先后顺序)或依赖外部系统才能确认(比如用户名是否已被占用、库存是否还够)的情况,单个输入框层面的约束做不到,仍然需要在提交或某个中间节点做校验,只是这类校验应该尽量靠近产生依赖关系的那个动作,而不是拖到整张表单提交之后。对语音输入、手写识别等无法逐字符拦截的输入方式,这条原则也不适用,只能退回到识别完成后的即时反馈。

怎么落地

对每个输入字段,先问它的合法值范围是否在字符或片段层面就能判断——如果能,直接在输入控件层面做约束:限制字符集、自动格式化、超范围值直接拒绝写入,而不是等提交后報告"格式错误"。对无法在单字段层面判断合法性的情况,把校验点尽量前移到依赖关系产生的那一步(比如切换到第二个日期时就检查是否早于第一个),而不是统一堆到最后。验证办法:统计用户从进入表单到成功提交之间,每个字段被回头修改的次数与位置,回头修改集中在某几个字段,说明这些字段的约束没有前移到位,需要优先改造。

延伸

  • 同组A10.06.1 物理形状与接口的防呆约束 · A10.06.2 降低危险操作的可达性 · A10.06.3 默认值作为最廉价的防错手段
  • 相邻A10.03 遗漏型错误与执行型错误 · A10.15 错误的检测与自我发现
  • 站内检索inline validation · input masking · real-time constraint

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/A10.06.4