关于表单校验中用户体验和交互设计的一些思考

前言

在开发 Cool Stack（一个工具类软件） 产品的过程中，某个功能的表单设计上，着实花了我不少时间。最难的部分在于如何设计表单校验的错误提示，才能让用户拥有更好的视觉体验和交互体验。

设计这个表单时，我尝试了很多种提示方式，例如输入框下方的红色字体提示、顶部弹出错误消息提示框、在表单的最后添加一行红色字体提示等，但这些方式都不能让我满意。

我的设计初衷是最小化限制用户的填写，用户只需要填入一个正确的服务器地址，就能直接点击提交按钮，提交表单。对于其他的表单项，则是选填项，用户可以选择不填，并贴心的为用户准备了默认值。

将表单校验的错误提示融入到按钮状态中，让用户在提交表单时，减少视线移动的次数，避免了错误信息出现在表单项之间，降低了表单的信息密度，减少了用户的理解成本。 伴随着按钮状态的变化，用户对于表单提交的失败和成功有了更直观的感受，相比视线转移的方式用户能在第一时间获得反馈，大大降低了面对提交失败的焦虑感。

当然，这种设计方式并不是适用于所有场景，例如在表单项很多的情况下，应该将错误信息提示放在表单项的下方，让用户在填写表单时，就能看到错误信息，而不是让用户每次提交表单时，才知道哪一项校验不通过。

接下来，我会分享一下个人对于表单校验的思考。

表单校验的历史

表单校验最早可以追溯到 Web 1.0 时代（1990-2004），当时的表单提交需要完整刷新页面才能获得校验反馈。这种「静态表单」的校验方式存在明显缺陷：

• 服务端校验主导：所有校验逻辑都在服务端完成，用户需要等待完整的 HTTP 请求响应周期
• 体验割裂：错误提示通常以红色文字直接显示在表单顶部，缺乏视觉引导
• 容错率低：表单提交失败后经常清空已填内容，用户需要重新输入

2005 年 Ajax 技术的出现带来了转折点，JavaScript 开始承担客户端校验职责。这个时期的进步包括：

• 即时校验（oninput 事件）
• 局部刷新错误提示
• 错误焦点自动定位
• 保留已填数据

2014 年 HTML5 标准发布，带来了原生表单验证属性：

<input type="email" required minlength="5" pattern="[a-z]{3,10}">

现代前端框架（React/Vue）进一步推动了校验体验的革新：

• 可视化错误状态管理
• 异步校验支持
• 动态错误提示动画
• 多字段关联校验
• 与 UI 库深度整合的校验组件

表单校验的意义

对于用户的意义

表单校验对于用户来说，起到了简化操作和提升体验的关键作用。它通过即时反馈帮助用户快速识别和纠正输入错误，减少了记忆和信息处理的负担，使得填写过程更加顺畅。 这种便利不仅提高了表单的完成率，还让用户对产品产生更好的印象，增强了对品牌的信任和忠诚度。对于涉及商业价值的表单，良好的校验机制更是确保用户顺利完成操作的保障。

对于服务器的意义

表单校验对服务器来说，就像是一个守门员，确保只有合格的数据才能进入系统。首先，它能防止恶意攻击，比如有人试图通过输入恶意代码来破坏系统。 其次，校验能减少服务器的工作量，因为它在前端就能发现错误，避免服务器处理无效请求。这样，服务器就能更高效地运行。校验还保证了数据的准确性，确保存储的数据是正确的，减少了后续处理的麻烦。 此外，它能防止系统因错误数据而崩溃，保持系统稳定。对于遵循法律法规，校验也很重要，因为它帮助企业合法地处理用户数据，并提供审计记录。 最后，校验逻辑的独立性使得系统更灵活，易于维护和更新。因此，表单校验不仅保护服务器，还提升了系统的效率和安全性。

表单校验有哪些方式？

实时校验

实时校验是在用户输入的过程中不断进行校验。这种方式可以在用户输入错误时立即给予反馈，帮助用户快速纠正错误。常见的实现方式是监听输入框的 input 事件。

优点：

• 即时反馈：用户输入时立即显示错误信息，减少等待时间。
• 交互友好：错误信息与输入框紧密结合，便于用户理解。
• 减少错误：实时校验有助于用户在早期发现并纠正错误。

缺点：

• 频繁校验可能导致性能问题。
• 错误信息可能过于频繁，影响用户体验。

失去焦点校验

失去焦点校验是在用户完成输入并离开输入框时进行校验。这种方式可以减少不必要的校验次数，适合对输入要求不高的场景。

优点：

• 减少校验次数：只在用户完成输入并离开输入框时校验，减少不必要的校验。
• 减少干扰：错误信息只在用户完成输入后显示，不会频繁打扰用户。

缺点：

• 延迟反馈：用户需要离开输入框才能看到错误信息，可能延迟了反馈时间。
• 需要额外操作：用户需要手动离开输入框才能校验，不如实时校验方便。

提交时校验

提交时校验是在用户提交表单时进行的全面校验。这种方式可以确保所有字段都经过验证，适合需要严格校验的场景。

优点：

• 全面校验：确保所有字段都经过验证，减少错误。
• 减少干扰：错误信息只在提交时显示，不会频繁打扰用户。

缺点：

• 延迟反馈：用户需要提交表单才能看到错误信息，可能延迟了反馈时间。
• 需要额外操作：用户需要手动提交表单才能校验，不如实时校验方便。

服务端校验

服务端校验是在数据提交到服务器后进行的校验。这种方式可以确保数据在传输过程中没有被篡改，并且可以进行更复杂的校验逻辑。

优点：

• 全面校验：确保所有字段都经过验证，减少错误。
• 减少干扰：错误信息只在提交时显示，不会频繁打扰用户。

缺点：

• 延迟反馈：用户需要提交表单才能看到错误信息，可能延迟了反馈时间。
• 需要额外操作：用户需要手动提交表单才能校验，不如实时校验方便。

实际开发中，通常会组合多种校验方式，例如输入密码时，采用实时校验；输入邮箱时，采用失去焦点校验；通常本地校验和服务端会同时存在，这样做的好处是： 本地校验可以减少服务器的压力，提高用户体验；服务端校验可以确保数据的准确性，防止数据被篡改；两者结合，才有双重保障。

表单校验的错误提示有哪些方式？

表单项提示

校验不通过时，错误信息通常会直接展示在表单的上方、下方或右方，这样做的好处是增强了错误信息提示的及时性，缺点是表单项较多时，校验提示会显得杂乱。 通常用于表单项过多的管理后台表单中，提高表单填写和校验效率。

Toast/Message 提示

Toast/Message 提示通常用于移动端表单，由于屏幕空间有限，无法将错误信息展示在表单项下方，因此通常采用 Toast/Message 提示。

Model/Dialog 提示

Model/Dialog 的使用场景就比较多，而且比较灵活，可以自定义错误信息提示的样式，并且可以附加更多的提示信息，解决了表单项提示内容有限的问题。

按钮状态反馈

这是本文开头提到的表单校验方式，通过按钮状态的变化，让用户在提交表单时，减少视线移动的次数，避免了错误信息出现在表单项之间，降低了表单的信息密度，减少了用户的理解成本。 这种方式适用于表单项较少，校验规则简单且较少的情况下，将用户体验考虑在第一位。

深度思考

表单校验不仅仅是一个技术实现问题，更是一个用户体验设计问题。从用户体验的角度来看，表单校验的意义在于：

引导用户正确输入

良好的表单校验设计应该像一个耐心的向导，而不是一个严厉的法官。它不仅要告诉用户"哪里错了"，更要告诉用户"怎么做对"。 例如，密码输入时，与其等用户输入完成后才提示"密码格式不正确"，不如在输入框下方预先展示密码规则，帮助用户在输入过程中就能够了解正确的格式要求。

减少用户挫败感

每当用户填写完表单点击提交，结果发现有错误需要重新填写时，都会产生一定程度的挫败感。好的表单校验设计应该尽可能减少这种情况的发生。 实时校验就是一个很好的例子，它能够在用户输入过程中就及时提供反馈，避免用户在提交时才发现错误。

建立用户信任

表单校验某种程度上也是在向用户传达"我们很重视你的数据质量"这一信息。例如，在用户注册时进行严格的密码强度校验，虽然可能会给用户带来一些输入负担， 但也向用户传达了"我们重视账号安全"的信息，有助于建立用户信任。

优化交互流程

表单校验的最终目的是帮助用户顺利完成任务。因此，校验的时机、提示的方式都应该服务于这个目标。例如：

• 对于简单的格式校验（如电话号码格式），可以采用实时校验。
• 对于需要查询数据库的校验（如用户名是否已存在），可以采用失焦校验。
• 对于复杂的业务规则校验，可以采用提交时校验。

平衡体验与效率

在设计表单校验时，需要在用户体验和操作效率之间找到平衡点：

• 校验规则太少，可能导致数据质量问题
• 校验规则太多，可能影响用户操作效率
• 提示太频繁，可能让用户感到烦躁
• 提示太少，可能让用户感到迷茫

因此，设计表单校验时应该根据具体场景和用户需求，选择合适的校验方式和提示策略。

参考文章

• 后台产品设计：表单验证的几种方式以及错误提示
• 有哪些常见的验证表单方式，他们各自的优缺点是什么？