表单设计最佳实践：Web 与移动端的 10 条规则

糟糕表单的代价

糟糕的表单，是你花每一分钱把用户带到页面后征收的策略税。存在摩擦时，注册、结账和引导流程表单的完成率平均约为 12%。消除摩擦后，这个数字可以超过 50%。

这个差距几乎从来不是文案或品牌的问题，而在于这十条规则是否得到了一贯执行。

在 notion.so 查看实例

Salesforce 式的 30 字段线索表单之所以存在，是因为有人把数据库结构直接映射到页面上，然后管它叫表单。用户来这里不是为了填这个的。他们是冲着产品来的，而你的筛选逻辑让你失去了这条线索。

规则 1：单列布局，每屏一个任务

始终坚持单列。多列布局在 Figma 网格里看起来很高效，但在屏幕上会直接拉低完成率。

眼睛从左到右阅读，期待连贯性。当字段分成两列时，用户需要决定先走哪条路，这个微小决策在他们输入第一个字符之前就已经制造了摩擦。

Notion 的注册流程在移动端是单列居中，每次只突出一个字段。表单感觉很流畅，因为它只问一件事。这就是规则。

规则 2：标签位置比标签样式更重要

标签放在字段上方。不是放在字段内部，不是放在旁边，而是在上方，始终可见。

把占位符文字用作标签，在用户开始输入的那一刻就会消失。到那时他们必须清空字段才能想起自己在填什么。Mercury 的引导流程在每个输入框上方都使用持久标签，确保填写过程中上下文永远不会丢失。

在 mercury.com 查看实例

浮动标签（在聚焦时从占位符位置向上动画）是可接受的折中方案，但需要精准的对比度和细心的时机控制才能满足无障碍要求。拿不准时，就把标签放在上面，固定在那里。

标签位置背后的 UX 研究在我们的 UX 研究方法指南中有深入讲解。

规则 3：字段顺序遵循用户逻辑，而非数据库结构

字段的顺序应该与用户思考任务的方式相匹配，而不是工程师构建数据模型的方式。

一个在确认购物车之前就询问收货地址的结账表单，把上下文负担压在了用户身上。Stripe Checkout 是托管结账表单 UX 的权威参考，它将表单分为三个步骤：

1. 邮箱（你是谁）
2. 付款（你怎么付）
3. 地址（东西寄哪里）

这是一个正常人在现实中会采用的顺序。当数据库主导字段顺序时，你就会得到那种在填国家之前先问邮编、在填公司名称之前先问职位的表单。

规则 4：实时内联验证，绝不等到提交时

用户离开字段的那一刻就验证，不要等到他们点击提交。

提交时验证意味着用户填完十个字段，点击按钮，然后迎面而来的是一堵红色错误。每一个错误都是一项修正任务，每一项修正任务都有可能让他们彻底放弃。失焦触发的内联验证，在用户继续前进之前就会将错误呈现出来。

Apple ID 登录在失焦时验证邮箱格式，并在提交按钮激活之前确认账号是否存在。这种顺序安排同时防止了两类错误。其背后的交互模式在我们的微交互设计指南中有详细介绍。

规则 5：移动优先意味着移动键盘优先

每种字段类型都应该唤起正确的键盘。这就是移动端表单设计的 80%。

如果一个字段要求输入电话号码，却弹出默认文字键盘，那么表单在用户输入任何东西之前就已经坏了。对数字字段使用 inputmode="numeric"，用 type="email" 显示 @ 键，价格字段用 inputmode="decimal"。iOS 和 Android 都支持完整的输入模式范围。

键盘是移动端的主要输入设备。指定错误的键盘会把一个视觉上设计正确的表单变成令人抓狂的东西。

这些模式所依托的更广泛的移动优先基础，请参阅响应式网页设计基础。

规则 6：进度、微文案与长表单问题

如果表单超过五个字段，就告诉用户他们在流程中的位置。

Airbnb 的多步骤预订流程全程显示带有命名步骤的进度指示器。能看到自己完成了 60% 的用户，比没有参考点的用户更有可能坚持完成，这一点有数据支撑。

在 tally.so 查看实例

Tally 的嵌入式表单采用了不同的方式：每次一个问题，顶部有持久进度条，在其有据可查的用户测试中，这种方式始终优于单页长表单。

微文案起着同样的作用。"第 2 步，共 4 步"比一条裸进度条更诚实。"我们需要这些信息来验证您的身份"比一个没有标签的敏感字段更有用。

规则 7：错误提示是指令，不是指控

用祈使句写错误提示，而不是用指控式的语气。

"此字段为必填项"是一种指控。"请输入您的邮箱地址以继续"是一条指令。用户已经知道出了什么问题，他们需要的是解决方案。

最好的错误文案会指出确切的条件和确切的操作："密码必须至少 8 个字符，并包含一个数字。"Stripe Checkout 正是这样做的。提示在失焦时出现，指明问题，一旦条件满足就消失。

没有挥之不去的红色状态，一切运转流畅。

规则 8：自动填充是功能，不是事后想起来加的东西

autocomplete 属性告诉浏览器确切要填什么。在每个字段上都使用它。

一个带有正确 autocomplete 属性的结账表单，在有保存数据的手机上大约 12 秒就能完成。没有这些属性，同一个表单需要两分钟，因为用户必须手动输入所有内容。这 108 秒的差距是大多数移动端结账流失的所在，而弥合它的成本为零。UI 组件库指南介绍了如何将这些属性内置到设计系统的表单组件中，确保它们永远不会缺失。

规则 9：提交按钮决定一切

提交按钮是合约。它的文案、状态和位置，传递着用户能否信任接下来发生之事的信号。

一个没有任何说明的灰色按钮告诉用户表单出了问题，却不说为什么。那是死路一条。一个写着"提交"的按钮对用户同意了什么只字未提。

"创建我的账户""获取免费试用""开始构建"都更诚实。只有在 UI 中能说明原因时才禁用按钮。Tally 在其表单构建器的每一步都使用具体动作的按钮文案，这直接贡献了他们在嵌入式 B2B 流程中高于平均水平的完成率。

规则 10：用真实的拇指、真实的数据、真实的延迟测试

在快速 Wi-Fi 下用桌面浏览器测试表单，对于它是否真的好用毫无参考价值。

在中档 Android 设备上通过 4G 连接测试，每个字段填入真实长度的数据：

• 包含重音字符的姓名
• 第二行有公寓号的地址
• 22 个字符的邮箱
• 1 个字符的名字

真实的边界情况会破坏那些在 Figma 里看起来无懈可击的表单。真实的延迟会揭示验证请求是否阻塞了输入，还是异步运行的。这种区别在浏览器模拟器里看不出来，在只有两格信号的手机上却可能是灾难性的。

需要对你的注册、结账或引导流程进行表单审计？Brainy 在真实屏幕、真实数据和真实转化数据上执行完整的十规则审计。

设计师仍在生产的最糟糕表单

当前生产环境中最糟糕的表单有三个共同模式：

• 企业销售线索表单： Salesforce 式的 30 字段资质筛选页面，带有强制性的"年营业额"选择器，没有内联验证
• 不保存进度的多步骤引导流程： 在第 9 步中的第 7 步接了个电话，用户回来就得从第 1 步重新开始
• 在移动端成为主流之前搭建、从未重建的结账流程： 每个数字字段还在用 type="text"，因为"在桌面端好用"

这三种情况下的错误状态选择往往也无法满足对比度要求；无障碍色彩对比模式能解决这个具体问题。

三者的共同点：表单是为系统设计的，不是为填写它的人设计的。解决方法是一样的。

执行这十条规则。从移动端开始。让数据库自己解决它的结构问题。

---

常见问题

表单应该有多少个字段？

尽可能少，以满足结果为准。正确的数量是：再删掉一个就会破坏产品功能的那个数量。每增加一个字段都会降低完成率。从零开始，只添加必要的字段。

应该使用多步骤表单还是单页表单？

超过五个字段时，多步骤表单几乎总是优于单页表单。前提是要有可见的进度。没有进度显示，多步骤表单的表现会比单页表单更差，因为用户不知道流程还有多长。给步骤命名，并显示用户在流程中的位置。

标记必填字段的最佳方式是什么？

标记可选字段，而不是必填字段。如果大多数字段都是必填的（根据上面的规则，应该如此），在每个字段上加红色星号只会制造视觉噪音。

标记例外情况。字段旁边的"可选"是有意义的信息。每个字段旁边的星号则不然。

如何在不惩罚用户的情况下处理密码要求？

在用户开始输入之前显示要求，而不是在他们失败之后。随着每个条件满足而激活的小型核查清单，表现优于提交后的错误墙。Apple ID 和大多数当前的认证流程都使用这种模式。反馈是实时的、积极的，从不是惩罚性的。

字段宽度能传递什么信息吗？

可以，用户会读取这个信号。字段宽度传递期望输入长度的信息。短字段表示短答案，全宽字段表示较长的内容。

在布局允许的情况下，使字段宽度与预期输入长度匹配。全宽的邮政编码字段看起来像个错误。街道地址用大型文本区域看起来又过头了。让容器与预期内容相匹配。

导致移动端表单流失最多的原因是什么？

错误的键盘类型排第一。自动填充不起作用排第二。两者都是无声的失败：表单看起来没问题，用户就是无法高效完成它。

每个字段两个属性就能修复这两个问题。投入 15 分钟，回报在同一个冲刺周期内就能在结账转化率上体现出来。