帮助文字的作用，是在旁边轻声提醒，告诉人们应该怎么把一张表单填“对”。它会解释字段含义，给出格式示例，帮用户少走弯路。但对大多数人来说，这些提示并不是体验中最关键的部分。真正被记住的，往往不是那些静静躺在输入框下方的说明文字，而是填写过程的结果，也就是错误消息和成功消息。

错误消息在表单里的角色，有点像一位当场指出问题的老师。它告诉人们当前哪里出了问题，哪一项不符合要求，为什么不行，以及还有没有补救的空间。如果只说“有误，请重试”，却不解释原因和改法，用户很快就会在懵圈和烦躁中放弃。而一条讲清楚“错在何处、为什么错、怎么改”的错误提示，则有机会把一次挫败，转成一次可控、可修复的小波折。

成功消息则承担着另一种期待。用户从开始填写的那一刻起，心里一直在等一件事，那就是系统干脆利落地告诉他，所有信息已经接收完毕，提交成功，接下来将会发生什么。一个设计得当的成功反馈，不只是轻飘飘一句“成功了”，它还会确认结果，安抚不安，顺手把用户带向下一步。对表单来说，错误消息和成功消息，就是这段旅程的句点和感叹号，也决定了用户最后离开时的心情。

一、错误从哪里来

无论设计者在前期多么用心地梳理表单内容、安排输入框位置、补充帮助文字，人们在真正填写时，仍然难免出错，而这些错误往往源自几类常见原因。

1.输入错误

这是设计师最熟悉的一类错误，也是校验规则直接关注的对象。最常见的几种情况包括，格式不符合要求，字数超出限制，必填字段被遗漏，数据类型不匹配。很多看似“用户粗心”的错误，其实可以追溯到字段规则和控件选型本身。比如明明只允许输入数字，却仍然提供了自由文本框；比如手机号码是固定的位数，用户确输入了更多的位数。这些，都可以归入设计型错误。

2. 业务错误

它不一定发生在字段本身，而是出现在“业务与数据”的关系上。库存已经不足，但前端页面还显示可下单；名额已经报满，但继续允许填写报名信息；优惠券看上去可以使用，提交时才告诉用户“不适用”；地区限制，有些产品只针对固定地区开放

多个规则之间彼此冲突，用户完全无法预判哪一条才是起作用的那条。业务错误通常和时效性、并发行为、隐含规则有关，背后是业务设计与状态同步的问题。

3. 系统错误

这一类错误往往不在用户控制范围之内。网络中断，接口超时，服务器异常，第三方支付通道瞬时故障，都可能让一次原本无可指摘的填写以失败告终。对用户来说，“系统出错了”只是一个模糊感受。他无法判断是自己的操作有问题，还是系统真的出了故障，也不知道自己需要做什么，才能让事情继续向前。这里的责任，只能由产品和系统承担，通过合理的预案与清晰的兜底来挽回信任。

以上三类错误交织在一起，就构成了真实环境中的错误图谱。设计时如果只盯着输入本身，很容易忽略后两类，从而在真正的业务场景里显得力不从心。