forms

构建让用户能够轻松完成、不感到困惑或焦虑，也不会中途放弃的表单。目标不是收集所有可能的字段，而是消除用户实现目标路上的所有不必要障碍。

请参阅表单验证模式，了解验证时机、错误位置、多字段依赖、异步验证、恢复设计、转化率衡量、字段级流失分析以及逐字段优化指南。 请参阅实时验证 UX，了解失焦与实时验证的时机差异、尽早奖励／延迟惩罚行为，以及便于复制粘贴的验证方式。 请参阅错误恢复，了解验证或提交失败后会发生什么。 决定是否禁用提交按钮，或保持按钮启用并说明错误时，请参阅禁用按钮 UX。 请参阅组件结构，了解按钮、输入框、复选框、单选按钮、切换开关、下拉菜单和文本区域的结构指南。 如果表单依赖过多的辅助文本、说明或引导流程，请参阅直观易懂的界面设计；优先通过更清晰的分组、默认值、约束、示例和行内反馈来改善体验。

必须完成的准备工作

阅读 frontend-design，并遵循其中的上下文收集流程。复用现有上下文，只针对重要信息缺口提问。此外，还要了解：用户希望实现什么目标、哪些字段确实必填，以及当前流程中导致用户放弃的原因。

评估表单需求

了解表单的用途和使用场景：

1. 用户目标：用户完成此表单后能获得什么？收益越明确，完成率越高。
2. 字段必要性：每增加一个字段，完成率都会下降。逐一审视字段：现在就必须收集吗？还是可以稍后再收集？
3. 使用场景：用户是否很赶时间、容易分心、正在使用紧凑视口或粗略指针，或者处于紧张情境中？紧张情境需要更简单的表单。
4. 流失点：用户目前在哪些地方中途放弃？表单过长、标签不清晰和意料之外的验证都是常见原因。
5. 数据用途：提交后实际会用到哪些字段？如果销售、支持或入门引导流程不会使用某个字段，就将其删除、推断得出，或留到稍后收集。
6. 衡量方式：分析数据是否涵盖表单浏览、首次聚焦字段、字段填写完成、验证错误、提交尝试、成功提交，以及移动端与桌面端的完成情况？

表单结构

字段顺序

• 先询问简单的问题，帮助用户逐步进入状态
• 在视觉上将相关字段分组（将姓名字段放在一起，地址字段放在一起）
• 将可选字段放在最后，或清楚标明为可选
• 仅在账单地址和收货地址确实不同时，才将它们分开

标签设计

• 使用清晰易扫读的标签，并将其放在输入框上方（不要将标签作为占位文本放在输入框内）
• 使用句首字母大写比使用标题式大小写更易读
• 具体说明：使用“卡号”，而不是“付款信息”
• 辅助文本应说明格式要求，而不是重复标签
• 添加辅助文本前，先考虑输入类型、宽度、占位示例、前缀／后缀、默认值或分组是否能让字段一目了然

输入设计

• 根据预期内容调整输入框宽度（邮政编码字段不应占满整行）
• 使用适当的输入类型（type="email"、type="tel"、type="date"），以优化浏览器键盘、自动填充和验证提示
• 在用户输入时显示格式提示（信用卡号分组、电话号码分组）
• 便于自动填充：使用标准的 name 和 autocomplete 属性
• 使用适合字段的交互方式：电子邮件拼写建议、电话国家/地区处理、长选项列表使用可搜索选择框、少于 5 个选项时使用单选按钮，以及较长消息使用可扩展文本区域
• 当自定义输入界面采用深色、半透明或高度品牌化的样式时，统一浏览器自动填充的视觉效果。先使用 Tailwind 工具类设置常规字段状态，再添加一小段 CSS 来处理 Tailwind 无法简洁表达的浏览器伪类：

@import "tailwindcss";

@layer components {
  .input:-webkit-autofill,
  .input:-webkit-autofill:hover,
  .input:-webkit-autofill:focus,
  .input:-webkit-autofill:active {
    border-color: color-mix(in oklab, white 40%, transparent);
    caret-color: var(--color-white);
    -webkit-text-fill-color: var(--color-white);
    -webkit-box-shadow: 0 0 0 1000px color-mix(in oklab, white 20%, transparent) inset;
    transition: background-color 5000s ease-in-out 0s;
  }

  .input:autofill {
    border-color: color-mix(in oklab, white 40%, transparent);
    caret-color: var(--color-white);
  }
}

:-webkit-autofill 适用于 Chromium 和 Safari。:autofill 是面向标准的选择器，适用于兼容的浏览器。两者都要保留，并涵盖悬停、聚焦和激活状态；同时测试实际的已保存密码和已保存地址流程，不要只依赖静态截图。

多步表单

在以下情况下，将长表单拆分为多个步骤：

• 字段超过 6-8 个
• 表单涵盖不同主题（账户信息、付款、确认）
• 用户需要在最终提交前检查信息

步骤设计：

• 显示进度（“第 2 步，共 4 步”），让用户了解剩余步骤
• 允许用户返回之前的步骤
• 用户离开后再返回时，保留已输入的数据
• 允许继续下一步前验证当前步骤，但不要阻止用户向后导航

对转化率敏感的表单

当表单用于收集潜在客户、演示申请、报价申请、申请信息或结账意向时：

• 将价值主张放在表单正上方或旁边
• 说明提交后会发生什么，并在相关时注明响应时间
• 先从电子邮件或姓名等低门槛字段开始，再询问敏感信息
• 仅在电话号码、公司规模、预算或详细需求能实质性改善后续跟进时才询问
• 对回访用户采用渐进式信息收集，而不是一开始就询问所有信息
• 在敏感字段附近说明隐私保障，不要将其藏在页脚里
• 对意向较强的表单，提供其他联系途径，例如聊天、电子邮件、电话或预约日历

验证策略

时机

• 对已明显填写完成的字段（电子邮件、电话、格式有要求的字段），在失焦时验证
• 仅在能提供即时帮助时于输入过程中验证（密码强度、字符数）
• 其他情况均在提交时验证，尤其是涉及多个字段依赖关系时
• 不要验证尚未操作过的字段，否则会让用户感到焦虑

错误设计

• 将错误消息直接放在字段下方
• 说明出错原因以及如何修正
• 使用 aria-invalid 和 aria-describedby 将错误与屏幕阅读器关联起来
• 验证失败时保留用户的所有输入
• 提交失败后将焦点移至第一个错误

成功状态

• 使用勾号或绿色边框，低调地确认字段有效
• 用户再次编辑字段时，移除成功标记
• 不要为每个有效字段都显示庆祝提示，以免造成干扰

响应式表单体验

• 确保粗略指针的可点击目标至少为 44×44px
• 使用适当的输入类型以优化键盘
• 通过拆分步骤或渐进式披露来减少滚动
• 数字字段显示数字键盘，电子邮件字段显示电子邮件键盘
• 短选项列表避免使用下拉菜单；改用单选按钮或分段控件

无障碍设计

• 使用 for/id 将每个输入框与标签关联
• 对分组字段使用 fieldset 和 legend
• 使用 role="alert" 或 aria-live="polite" 播报表单级错误
• 确保错误消息以编程方式与字段关联
• 测试键盘在整个表单中的导航
• 不要仅依赖颜色来表示错误

反模式

• 字段过多：每增加一个字段，完成率都会降低
• 用占位符代替标签：用户输入后占位符会消失，不利于记忆和无障碍访问
• 页面加载时验证：尚未填写的字段就显示错误，会让人觉得受到了指责
• 错误信息含糊：只说“输入无效”却不解释原因，会让用户摸不着头脑
• 出错时清空字段：丢失已输入的数据会让人非常沮丧
• 禁用提交按钮却不给出指引：按钮呈灰色，且没有显示任何错误信息，会让用户无从继续
• 多步表单没有进度指示器：用户不知道还剩多少步骤
• 验证时机不一致：有的在失去焦点时验证，有的在提交时验证，却没有明确的逻辑
• 忽略输入语义：电话号码使用 type="text"，会导致浏览器无法显示最合适的键盘，也无法提供最佳的自动填充体验
• 不支持保存并继续填写：无法中途保存的长表单会让受到打断的用户处于不利境地

检查表单质量

发布前：

• 每个字段都有必要；明确标记可选字段
• 标签清晰、具体，并置于输入框上方
• 尚未填写的字段不会触发验证
• 错误信息说明出了什么问题以及如何修正
• 验证失败时保留已输入的内容
• 提交失败后，焦点移至第一个错误
• 多步表单显示进度，并允许返回上一步
• 针对每种字段类型优化浏览器键盘、自动填充和验证提示
• 整个表单都可通过键盘导航
• 颜色不是错误或成功状态的唯一提示