如何写好表单校验错误提示

一个人填完电子邮箱地址，移到下一栏时，看到了一条有用的修改提示。另一个人还在输入，就看到了几乎相同的句子，开始疑惑自己究竟做错了什么。两条提示的文字可能完全一样，带来的体验却不同。

这正是表单校验错误提示比想象中更难设计的原因。措辞再温和，也弥补不了过早出现的打断；解释再精确，如果指向了错误的填写内容，也帮不上忙。真正需要决定的是：系统掌握了什么信息，什么时候应该反馈，以及用户接下来能够怎么做。

有不少值得借鉴的证据，但它们并不全都指向某一种通用模式。电商研究、政府服务指南和注册表单实验，对“避免打断”与“尽早反馈”的侧重点有所不同。理解这些差异，比收集一份所谓完美错误提示的清单更有用。

真实用户告诉了我们什么

Edward Scott 在 2024 年 1 月的 Baymard 行内校验测试报告中记录了几个案例。一位参与者在 L.L.Bean 结账时，漏输了电子邮箱地址中的 @ 符号。她移到下一栏后看到了反馈，并在几秒内完成修正。在 Etsy，另一位参与者刚进入尚未填写的地址栏，就遇到了错误提示，感觉自己还没回答就受到了责备。REI 的案例则展示了另一种恢复过程：参与者补上银行卡安全码缺少的第三位数字后，错误提示随即消失。

这些历史观察说明，只说“使用了行内校验”，还不足以描述体验。提示在什么时候出现、又在什么时候消失，可能与它具体怎么写同样重要。

评审自己的表单时，我会把这些观察转化为一个问题：这条提示回应的，是否是用户自己认为已经完成的动作？点击“继续”，明确表达了完成的意图；离开某个字段，有时也能表达这种意图；但只是把光标放进一个空字段，通常并不意味着已经答完。界面需要有理由才去打断用户，而不能仅仅因为当前值还不符合某条规则就报错。

Luke Wroblewski 与 Etre 的 2009 年注册表单研究提供了一个有用的对照。22 名参与者试用了六种表单版本。研究报告称，与对照版本相比，效果最好的行内校验版本使成功率提高了 22%，完成时间减少了 42%。一位参与者表示，更希望在填写过程中就知道自己的错误。不过，在用户熟悉的答案旁显示绿色对勾，也曾让人困惑：系统究竟核验了什么？

这项研究最有价值的启示，在于如何处理不确定性。选择一个可用用户名时，用户需要系统才掌握的信息；输入自己的姓名时，则未必需要系统表示认可。我会优先在能够消除未知的地方提供反馈，而不是在整张表单里平均分配表示通过的图标。

为什么 GOV.UK 选择不同的时机

GOV.UK 的校验模式建议等用户尝试继续或提交后再校验，而不是在他们离开字段时就校验。它还建议保留已输入的答案，在页面顶部放置错误摘要，将焦点移至摘要，并在相关字段旁指出错误。如果要更早校验，需要有用户研究支持。

应当明确保留这套建议与电商案例之间的差别。如果每个步骤只有一个问题，提交后再修改通常只涉及眼前这一个局部，答案仍然就在用户面前。但在很长的结账页面中，等用户提交时，填错的字段可能早已被滚动到很远的上方。

如果评审一个工作坊预约流程，我会先看任务的组织方式。在只问日期的页面上，把点击“继续”作为解释所选日期不可用的时机，是一个合理起点。但如果一页里同时包含联系信息、无障碍需求、席位数量和账单信息，等到用户抵达底部才报错，就可能让他们沿着长表单回头查找。这并不自动证明所有字段都该实时校验，而是说明有选择地提前反馈值得测试。

此外，填写指导和错误提示也应区分开。密码要求清单可以在用户输入时说明规则，而不把每项尚未满足的要求都当作失败。日期提示可以在用户填写之前，先解释允许预约的时间范围。有用的帮助不必等到提交以后才出现，提前提供帮助也不必呈现为红色警告。

把每个字段使用哪种触发方式写清楚。否则，一句“我们采用行内校验”，可能掩盖了三位实现者分别做出的三种不同行为。

只提出系统有依据要求的修改

“请输入有效的电子邮箱地址”常常在对话本该开始解释的地方，就结束了解释。这里的“有效”究竟指什么？没有填写、格式错误、不可用，以及尚未验证，是不同的状态。把它们当作同义词，会让提示听起来很确定，却没有告诉用户下一步应该怎么做。

在一个虚构的工作坊表单中，如果联系邮箱为空，可以写：“请输入用于接收预约确认的电子邮箱地址。”如果用户输入的文字中没有 @ 符号，“请输入包含 @ 符号的电子邮箱地址”就描述了一个可以观察到的问题。但这两种说法都不能证明邮箱确实存在，或属于当前用户。要确认这些事实，还需要独立的验证步骤。

很容易让人想为每一种可能的输入错误都写一条极其具体的提示。但除非校验逻辑能够可靠地区分这些情况，否则我会克制这样做。如果用户使用的是不常见但合法的域名，直接告诉他们“域名拼错了”，并没有帮助。系统不能确定时，提供可选建议可能比强制拒绝更合适。团队应当在批准文案之前，先就这两种处理的区别达成一致。

下面是为这个工作坊示例整理的一份简短提示清单。每一行都先写明已知条件，因为同一个字段在不同情况下可能需要不同提示。

最后一行有意向产品提出了超出一句文案的要求：只有服务确实提供了可用的状态查询方式，才适合让用户去查看预约状态。如果没有，就需要与工程和支持团队共同确定另一条恢复路径。文案应当让这个尚未作出的决定显露出来，而不是用“请重试”把它掩盖过去。

提交失败后，让用户能找到长表单里的错误

设想用户在预约页面接近底部的位置点击“继续”。顶部有两个字段出现了错误，但当前视口仍然停留在按钮附近。仅在屏幕之外给字段加红框，并不足够。用户需要知道这次操作没有成功，并且能够回到需要处理的答案处。

在这个工作坊示例中，可以用错误摘要列出席位数量和日期的问题，每一项都链接到对应字段。用户修改时，字段旁的提示仍留在答案附近。这样的重复各有用途：摘要帮助用户到达问题位置，局部提示帮助用户修改答案。如果两处使用不同措辞，就会额外要求用户理解它们之间的对应关系。

摘要也应该有所选择。已经通过相关检查的联系邮箱，不应列入错误清单；也不应为了得到一个整齐的重置状态，就把整张表单清空。让用户看见之前的答案，可以帮助他们理解发生了什么，并且只修改有必要的部分。对于敏感信息是否保留，需要单独作出产品和安全决策，不要承诺每个字段都会始终保存。

到了这里，静态设计评审就需要转为交互评审。用键盘打开错误摘要中的链接，检查焦点落在哪里、字段标签是否仍能在固定页头下方看见，以及到达字段时能否获取相应说明。然后修改答案，再提交一次。截图能展示一个红框，却不能证明这条在页面中定位并修正错误的路径确实可用。

在手机上打开键盘后，再检查同样的操作过程。一条提示在桌面画布里可能排得很好，到了手机上却可能被键盘遮住。较长的错误提示应当换行，而不是把字体缩小到难以阅读。我宁愿多给修改说明一行空间，也不希望用户必须放大页面，才能看清完成任务所必需的指引。

事实改变时，提示也必须随之更新

一个常见的评审失误，是只批准“正常”和“错误”两个画面。最难处理的情况往往在两者之间：用户修改了答案，原来的问题已经消失，红色提示却还留着。从用户的角度看，这可能意味着刚才的修改并没有成功。

回到工作坊表单：假设用户申请了四个席位，而当前只剩两个。把数量改成二之后，应当重新检查适用的规则。修改日期则不同，因为它改变了规则所依赖的场次库存。不能把针对前一场次的警告，直接保留在新场次上。这种依赖关系，比红框长什么样更重要。

交接时，我会要求再补充三种状态：正在检查、本步骤已通过检查，以及无法检查。“正在查询可用席位……”不同于“有两个席位可用”，而这两者都不等于预约已确认。明确这些区别，才能在请求耗时超出预期，或某场次在两次检查之间售罄时，仍然如实表达系统状态。

还有一种不太显眼的边界情况：用户连续修改了两次日期，第一次发出的席位查询却比第二次更晚完成。如果旧响应覆盖了新响应，界面就可能把一个与当前问题不符的答案显示得清清楚楚。设计备注应当要求，显示结果必须对应当前选择；至于如何保证这一点，可以由工程团队决定。

评审动效或加载表现时，也要始终保留这些状态差异。目标不是让过渡过程显得忙碌，而是防止用户把旧结果误认为新结果。如果系统眼下无法检查，用中性文字解释原因，比把用户的答案标为无效更准确。

服务失败不是用户回答错了

在预约流程中，代价最大的文案错误，可能是让用户修改一个原本没有问题的答案。一次请求失败，可能意味着输入被拒绝、服务器不可用，也可能意味着结果尚无法确定。这几种情况需要不同的后续步骤。

例如，用户点击“预约”后遇到超时。请求可能根本没有到达服务，也可能已经处理完成，只是返回的响应丢失了。在没有弄清属于哪种情况时，直接说“预约失败”就过于确定。立即再次提交，可能没有问题，也可能产生重复预约。产品需要对如何处理这种不确定性作出明确决定。

在这个例子中，我会先与工程师一起评审恢复路径，再打磨提示文字。服务能否通过请求编号查回处理结果？重复请求能否安全地返回原来的结果？支持团队能否找到这次尝试？哪些已填答案会留在页面上？这些问题决定了合适的下一步究竟是查询状态、安全重试，还是带着编号联系支持团队。

这并不意味着要把内部技术细节写进错误提示。读者不需要听一堂网络故障课，他们需要的是如实说明目前知道什么，并给出真正可行的下一步。如果支持团队能够使用请求编号，它就有帮助；如果只是一个没有解释的错误码，就又给用户增加了一道需要自行理解的难题。

表单校验的最佳实践也包括恢复路径

在 OpenDesign 支持的 HTML 预览中，团队可以比较字段正常、出错和修正后的状态。使用贴近实际的值和较长的提示，检查窄视口，并对具体需要修改的元素发表评论。然后在实际运行的后端、键盘操作流程和屏幕阅读器播报中，测试同一段操作过程。

一次简短的评审，可能比再调整一轮形容词更能揭示问题。给用户一个具体任务，例如预约工作坊的四个席位，让他们实际遇到席位不足，再问他们认为发生了什么、接下来会怎么做。不要事先解释提示想表达的意思，否则就消除了你原本想发现的歧义。

观察用户修正之后的行为，应当与听取他们对提示的评价一样仔细。如果他们反复重读警告，可能是提示没有及时清除。如果服务超时后，他们去修改一个本来正确的邮箱，界面可能把问题错误地归到了输入上。如果他们从头重新填写整张表单，恢复路径可能比原来的任务还难找到。

对于线上服务，反复提交和来回修改的过程，可以帮助团队确定值得调查的位置，但不能自动解释原因。错误数量很高，可能源于指引不清楚、规则过于严格、库存不足，或实现缺陷。应把事件发生顺序与实际观察到的行为结合起来分析，避免仅仅为了诊断表单，就采集用户填写的原始个人信息。

在批准这个示例之前，我会走完下面这段简短流程：

1. 输入一个尚未完成的答案，观察反馈在什么时候出现。
2. 带着两个错误提交，并从错误摘要分别到达对应字段。
3. 修正一个答案，确认其他不相关的输入仍然保留。
4. 修改一个会影响其他结果的答案，例如工作坊日期，再检查新的结果。
5. 遇到服务不可用的情况，并按界面提供的恢复路径继续操作。

最后还要检查成功结果。确认页面有没有显示修改后的日期和数量？用户能不能判断预约是否已经存在？仅仅让红色文字消失，并不代表表单已经成功恢复。

好的表单校验错误提示，应减少用户自行解释和猜测的负担。这些行业案例之所以有用，是因为它们揭示了用户在什么地方难以理解界面：答案还没填完时、已经修改之后，或者界面声称知道的比实际更多时。借鉴这些案例背后的判断方法，在自己的具体任务中测试，再根据真正能实现的行为决定提示怎么写。