forms

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Build forms that users complete without confusion, anxiety, or abandonment. The goal is not to collect every possible field; it is to remove every unnecessary obstacle between the user and their goal.

Consult the form validation patterns reference for validation timing, error placement, multi-field dependencies, async validation, and recovery design. Consult the live validation UX reference for blur-vs-real-time timing, reward-early/punish-late behavior, and copy-paste-friendly validation. Consult the error recovery reference for what happens after validation or submission fails. Consult the disabled buttons UX reference when deciding whether to block submit buttons or keep them enabled with error explanation. Consult the component anatomy reference for button, input, checkbox, radio, toggle, dropdown, and textarea anatomy guidance.

构建用户能够无困惑、无焦虑、不放弃地完成的表单。目标不是收集每一个可能的字段；而是移除用户与目标之间的每一个不必要的障碍。

请参阅表单验证模式参考文档，了解验证时机、错误位置、多字段依赖、异步验证和恢复设计。请参阅实时验证UX 参考文档，了解失焦与实时验证的时机、奖励提前/惩罚滞后的行为以及便于复制粘贴的验证方式。请参阅错误恢复参考文档，了解验证或提交失败后会发生什么。请参阅禁用按钮UX 参考文档，决定是阻止提交按钮还是保持启用并显示错误说明。请参阅组件解剖参考文档，获取按钮、输入框、复选框、单选按钮、开关、下拉框和文本域的解剖指南。

MANDATORY PREPARATION

强制准备

Users start this workflow with

/forms

. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first. Additionally gather: what goal the user is trying to achieve, which fields are truly required, and what causes abandonment in the current flow.

用户以

/forms

开始此工作流程。一旦此skill激活，加载 $frontend-design —— 它包含设计原则、反模式和上下文收集协议。在继续之前遵循该协议 —— 如果尚无设计上下文，则必须先加载 $setup。此外，还要收集：用户试图实现什么目标，哪些字段是真正必填的，以及当前流程中导致用户放弃的原因。

Assess Form Needs

评估表单需求

Understand the form's purpose and context:

User goal: What does the user get by completing this form? The clearer the payoff, the higher the completion rate.
Field necessity: Every field you add drops completion rates. Challenge each field: is it required now, or can it be collected later?
Context of use: Is the user rushed, distracted, on mobile, or in a stressful situation? Stressful contexts need simpler forms.
Failure points: Where do users currently drop off? Long forms, unclear labels, and unexpected validation are common culprits.

理解表单的目的和上下文：

用户目标：用户完成此表单能获得什么？回报越清晰，完成率越高。
字段必要性：每增加一个字段都会降低完成率。质疑每个字段：它是现在必需的，还是可以稍后收集？
使用情境：用户是匆忙、分心、在移动设备上，还是处于压力情境？压力情境需要更简单的表单。
失败点：用户当前在哪里流失？长表单、不清晰的标签和意外的验证是常见原因。

Form Structure

表单结构

Field order

字段顺序

Ask easy questions first to build momentum
Group related fields visually (name fields together, address fields together)
Place optional fields at the end or mark them clearly
Separate billing and shipping only when they are genuinely different

先问简单的问题以建立动力
视觉上分组相关字段（姓名字段在一起，地址字段在一起）
将可选字段放在末尾或明确标记
仅在账单和收货地址确实不同时才分开

Label design

标签设计

Use clear, scannable labels above the input (not inside as placeholder text)
Sentence case is easier to read than Title Case
Be specific: "Card number" not "Payment info"
Helper text should explain format requirements, not repeat the label

在输入框上方使用清晰、可扫描的标签（而不是作为占位符文本放在内部）
句子式大小写比标题式大小写更易读
要具体：“卡号”而非“支付信息”
帮助文本应解释格式要求，而不是重复标签

Input design

输入设计

Match input width to expected content (postal code fields should not be full-width)
Use the appropriate input type (
```
type="email"
```
,
```
type="tel"
```
,
```
type="date"
```
) for mobile keyboard optimization
Show formatting hints as the user types (credit card spacing, phone number grouping)
Autofill-friendly: use standard
```
name
```
and
```
autocomplete
```
attributes

使输入框宽度与预期内容匹配（邮政编码字段不应是全宽的）
使用适当的输入类型（
```
type="email"
```
、
```
type="tel"
```
、
```
type="date"
```
）以优化移动键盘
在用户输入时显示格式提示（信用卡空格、电话号码分组）
便于自动填充：使用标准的
```
name
```
和
```
autocomplete
```
属性

Multi-step forms

多步骤表单

Break long forms into steps when:

There are more than 6-8 fields
The form covers distinct topics (account info, payment, confirmation)
Users need to review before final submission

Step design:

Show progress ("Step 2 of 4") so users know what remains
Allow navigation back to previous steps
Preserve entered data if the user leaves and returns
Validate each step before allowing progression, but do not block navigation backward

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

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

步骤设计：

显示进度（“第2步，共4步”）以便用户知道还剩下什么
允许导航回之前的步骤
如果用户离开并返回，保留已输入的数据
在允许进入下一步之前验证每个步骤，但不要阻止向后导航

Validation Strategy

验证策略

Timing

时机

Validate on blur for clearly completed fields (email, phone, format-required fields)
Validate on input only for immediate feedback that helps (password strength, character count)
Validate on submit for everything else, especially cross-field dependencies
Never validate a pristine field; it creates anxiety

对明显已完成的字段在失焦时验证（邮箱、电话、需要格式的字段）
仅在有助于即时反馈时在输入时验证（密码强度、字符计数）
对其他所有情况在提交时验证，特别是跨字段依赖
永远不要验证未触碰的字段；这会造成焦虑

Error design

错误设计

Place error messages directly below the field
Explain what went wrong and how to fix it
Use
```
aria-invalid
```
and
```
aria-describedby
```
for screen reader association
Preserve all user input when validation fails
Move focus to the first error after failed submission

将错误消息直接放在字段下方
解释出了什么问题以及如何修复
使用
```
aria-invalid
```
和
```
aria-describedby
```
进行屏幕阅读器关联
验证失败时保留所有用户输入
提交失败后将焦点移动到第一个错误

Success states

成功状态

Subtly confirm valid fields with a checkmark or green border
Remove success indicators when the user edits the field again
Do not celebrate every valid field; it becomes noise

用对勾或绿色边框轻微确认有效字段
当用户再次编辑该字段时移除成功指示
不要庆祝每个有效字段；这会成为噪音

Mobile Form UX

移动端表单UX

Ensure touch targets are at least 44×44px
Use appropriate input types for optimized keyboards
Minimize scrolling by breaking into steps or using progressive disclosure
Show the numeric keyboard for number fields, email keyboard for email fields
Avoid dropdowns for short lists; use radio buttons or segmented controls instead

确保触摸目标至少为44×44px
使用适当的输入类型以优化键盘
通过拆分为步骤或使用渐进式披露来最小化滚动
数字字段显示数字键盘，邮箱字段显示邮箱键盘
对于短列表避免下拉框；改用单选按钮或分段控件

Accessibility

无障碍性

Associate every input with a label using
```
for
```
/
```
id
```
Use
```
fieldset
```
and
```
legend
```
for grouped fields
Announce form-level errors with
```
role="alert"
```
or
```
aria-live="polite"
```
Ensure error messages are programmatically associated with fields
Test keyboard navigation through the entire form
Do not rely on color alone for error indication

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

Anti-Patterns

反模式

Too many fields: Every additional field reduces completion rates
Placeholder as label: Disappears when the user types; bad for memory and accessibility
Validate on load: Pristine fields showing errors feel accusatory
Vague errors: "Invalid input" without explanation leaves users guessing
Clearing fields on error: Losing typed data is deeply frustrating
Disabled submit without guidance: A grayed-out button with no visible errors is a dead end
Multi-step without progress indicator: Users do not know how much remains
Inconsistent validation timing: Some on blur, some on submit, with no clear logic
Ignoring mobile keyboards: Using
```
type="text"
```
for phone numbers forces users to switch keyboards
No save-and-resume: Long forms that cannot be saved mid-progress punish interruptions

字段过多：每增加一个额外字段都会降低完成率
占位符作为标签：用户输入时消失；不利于记忆和无障碍性
加载时验证：未触碰的字段显示错误会让人感觉被指责
模糊错误：没有解释的“无效输入”让用户猜测
出错时清除字段：丢失已输入的数据非常令人沮丧
无指导的禁用提交：灰色按钮且没有可见错误是死胡同
无进度指示的多步骤：用户不知道还剩下多少
不一致的验证时机：有些在失焦时，有些在提交时，没有清晰的逻辑
忽略移动键盘：对电话号码使用
```
type="text"
```
迫使用户切换键盘
无保存和恢复：无法中途保存的长表单会惩罚中断的用户