Back to Details

forms-inputs-checkout

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Forms, Inputs, and Checkout

表单、输入框与结账流程

Purpose

用途

Help an agent design, critique, and implement clear, accessible, high-conversion forms, inputs, validation, and checkout flows.
Treat every form as a barrier between a person and a goal. The agent's job is to reduce that barrier without collecting bad data, hiding meaningful choices, or weakening accessibility, privacy, legal, or business requirements.
帮助Agent设计、评审并实现清晰、可访问、高转化率的表单、输入框、验证逻辑及结账流程。
将每个表单视为用户达成目标的阻碍，Agent的职责是在不收集无效数据、隐藏重要选项、降低可访问性、侵犯隐私、违反法规或业务要求的前提下，尽可能减少这种阻碍。

When to use this skill

何时使用本技能

Use this skill for:
  • Checkout, cart, payment, shipping, billing, promo-code, account, registration, sign-in, onboarding, subscription, lead-capture, support, survey, settings, profile, upload, and data-entry forms.
  • Critiquing screenshots, wireframes, Figma descriptions, HTML/CSS/React components, design-system components, or product flows involving forms.
  • Choosing labels, input controls, grouping, progress indicators, defaults, validation, error messages, help text, submit states, and success states.
  • Making frontend guidance for semantic HTML forms, accessible names, focus, keyboard flow, validation, and responsive behavior.
用于以下场景：
  • 结账、购物车、支付、配送、账单、优惠码、账户、注册、登录、新用户引导、订阅、线索收集、支持、调研、设置、个人资料、上传及数据录入表单。
  • 评审包含表单的截图、线框图、Figma描述、HTML/CSS/React组件、设计系统组件或产品流程。
  • 选择标签、输入控件、分组方式、进度指示器、默认值、验证规则、错误提示、帮助文本、提交状态及成功状态。
  • 为语义化HTML表单、可访问名称、焦点、键盘导航流程、验证逻辑及响应式行为提供前端指导。

When not to use this skill

何时不使用本技能

Do not use this skill for:
  • General page layout, landing pages, navigation, marketing content, or visual brand work unless the page contains a form or checkout decision.
  • Backend data modeling, fraud detection, tax, legal, PCI/security implementation, or payment processor integration details beyond UX/frontend implications.
  • General conversion-copy work outside form context.
  • Native platform-specific form controls when the user explicitly asks for a platform guideline not covered by the source material. In that case, ask or use the appropriate platform skill/source.
请勿用于：
  • 通用页面布局、着陆页、导航、营销内容或视觉品牌设计工作，除非页面包含表单或结账相关决策。
  • 后端数据建模、欺诈检测、税务、法规、PCI/安全实现或支付处理器集成的细节（除非涉及UX/前端影响）。
  • 表单场景之外的通用转化文案工作。
  • 用户明确要求未被现有资料覆盖的平台特定表单控件时，此时应询问用户或使用相应的平台技能/资料。

Core principles

核心原则

  1. Start outside-in. Begin with the user's goal and the moment in their journey, not with the database fields the organization wants.
  2. Remove, defer, infer, or default before designing another field. Every question creates effort and the possibility of error.
  3. Make the path to completion visually obvious. A form should have a clear scan line from title to first question to final action.
  4. Use controls that match the question. Prefer native, semantic form controls and visible options when the number of options is small.
  5. Use labels as durable context. Do not rely on placeholder-only labels for anything longer than a trivial, familiar, one-field interaction.
  6. Validate to help, not to scold. Validate after a person has finished an answer, prevent avoidable errors, and provide remedies in context.
  7. Design for mistakes. People will omit steps, choose the wrong action, mistype, misunderstand labels, and miss information under stress.
  8. Do not use color alone. Errors, success, required/optional status, disabled states, and payment/security cues need text and/or shape in addition to color.
  9. Keep checkout focused. Remove distractions, avoid forced account creation, show costs and consequences clearly, and keep the primary action aligned with the buyer's goal.
  10. Make progress honest. Use progress indicators only when the sequence and scope are stable enough that the indicator will not mislead.
See references/principle-cards.md for each principle as a reusable card.
  1. 从外到内思考：从用户的目标及其旅程中的当前节点出发，而非从企业需要的数据库字段开始。
  2. 先移除、延迟、推断或设置默认值，再设计新字段：每个问题都会增加用户的操作负担和出错概率。
  3. 让完成路径在视觉上清晰可见：表单应具备清晰的扫描路径，从标题到第一个问题再到最终操作。
  4. 使用与问题匹配的控件：当选项数量较少时，优先使用原生、语义化表单控件及可见选项。
  5. 将标签作为持久化上下文：除了简单、常见的单字段交互外，不要仅依赖占位符作为标签。
  6. 验证是为了提供帮助，而非指责：在用户完成输入后进行验证，避免可预防的错误，并在上下文环境中提供解决方案。
  7. 为错误场景设计：用户可能会跳过步骤、选择错误操作、输入错误、误解标签或在压力下遗漏信息。
  8. 不要仅依赖颜色传递信息：错误、成功、必填/选状态、禁用状态及支付/安全提示除了颜色外，还需要文本和/或形状辅助。
  9. 保持结账流程专注：移除干扰项，避免强制创建账户，清晰展示成本及后果，确保主要操作与买家目标一致。
  10. 如实展示进度：仅当流程顺序和范围足够稳定，不会误导用户时，才使用进度指示器。
查看references/principle-cards.md获取可复用的单条原则卡片。

Default recommendations

默认建议

Use these defaults unless the user provides a product-specific constraint or the skill's decision prompts indicate a question is needed.
除非用户提供产品特定约束或技能决策提示需要进一步询问，否则遵循以下默认规则。

Form purpose and scope

表单用途与范围

Default: optimize for successful completion of the user's current goal with the minimum trustworthy data required.
Override when: regulatory, security, fraud, identity, eligibility, support, or fulfillment requirements demand additional data. Ask for the requirement and consequence.
默认：以最少的可信数据，优化用户当前目标的完成成功率。
例外情况：当法规、安全、欺诈、身份验证、资格审核、支持或履约要求需要额外数据时，询问具体要求及后果。

Question set

问题集合

Default: remove nonessential questions; postpone optional or marketing questions until after the core submission; infer answers from known context when confidence is high.
Override when: optional answers are critical to personalization, eligibility, pricing, compliance, or operational routing.
默认：移除非必要问题；将可选或营销类问题推迟到核心提交完成后；当置信度较高时，从已知上下文推断答案。
例外情况：可选答案对个性化、资格审核、定价、合规或业务路由至关重要时。

Structure

结构

Default: use a single page for short forms with a few coherent topics; use multiple pages or one-thing-per-page for long forms, branching flows, mobile-first flows, or high-focus tasks.
Override when: users need to review many related answers together, compare choices, or complete a dense expert workflow.
默认：简短且主题连贯的表单使用单页布局；长表单、分支流程、移动端优先流程或高专注度任务使用多页或单问题单页布局。
例外情况：用户需要同时查看多个相关答案、对比选项或完成密集的专家工作流时。

Labels

标签

Default: use visible, concise, natural-language labels above fields. Top labels usually minimize completion time, handle localization better, and work well on mobile.
Override when: a dense desktop form has severe vertical constraints, or when a complex settings form needs label scanning more than speed.
默认：使用可见、简洁、自然语言的标签，置于字段上方。顶部标签通常能减少完成时间，更好地支持本地化，且在移动端表现良好。
例外情况：密集的桌面表单存在严格的垂直空间限制，或复杂设置表单更需要标签扫描而非操作速度时。

Required and optional fields

必填与可选字段

Default: avoid optional fields. When most fields are required, mark the few optional fields with text such as "Optional." When most fields are optional, mark the few required fields with text such as "Required." Do not mark every field required.
Override when: organizational standards require asterisks; still provide a legend and associate the indicator with the label.
默认：避免设置可选字段。当大多数字段为必填时，仅标记少数可选字段（如标注“可选”）；当大多数字段为可选时，仅标记少数必填字段（如标注“必填”）。不要为所有字段标记必填。
例外情况：企业标准要求使用星号时，仍需提供说明图例并将标记与标签关联。

Input controls

输入控件

Default: use native controls and semantic HTML. Use radio buttons for one choice among a small set, checkboxes for yes/no or multiple choices, text inputs for free-form answers, and select/combobox patterns only when they reduce effort for long option sets.
Override when: the design system has tested accessible custom controls that preserve keyboard, screen reader, focus, and error behavior.
默认：使用原生控件和语义化HTML。选项数量较少时使用单选按钮；用于是/否或多选场景时使用复选框；自由输入场景使用文本框；仅当长选项集能减少操作负担时，才使用选择框/组合框模式。
例外情况：设计系统中已测试过的可访问自定义控件，且保留了键盘、屏幕阅读器、焦点及错误处理行为时。

Select boxes

选择框

Default: use select boxes as a last resort. Prefer visible radio options for a short list, autocomplete/combobox for long searchable lists, or sensible defaults when the likely answer is known.
Override when: platform conventions or limited space make a select control the simplest accessible solution.
默认：仅在万不得已时使用选择框。短列表优先使用可见的单选选项；长可搜索列表优先使用自动完成/组合框；已知大概率答案时使用合理的默认值。
例外情况：平台惯例或空间限制使选择框成为最简单的可访问解决方案时。

Input width

输入框宽度

Default: make field width communicate expected answer length when the answer has a known size, such as postal code or security code. Use consistent practical widths when length does not carry meaning.
Override when: responsive constraints, localization, or auto-formatting make exact width misleading.
默认：当答案长度已知时（如邮政编码或安全码），用字段宽度传达预期输入长度；长度无意义时，使用统一的实用宽度。
例外情况：响应式约束、本地化或自动格式化使精确宽度产生误导时。

Help text

帮助文本

Default: provide short, adjacent help only for unfamiliar data, privacy/security concerns, unusual formats, sensitive questions, optional/required exceptions, or recommended answer formats.
Override when: expert, repeated-use, or complex workflows require a persistent contextual help panel.
默认：仅针对陌生数据、隐私/安全顾虑、特殊格式、敏感问题、必填/选例外情况或推荐答案格式，提供简短的就近帮助文本。
例外情况：专家级、重复使用或复杂工作流需要持久的上下文帮助面板时。

Validation

验证

Default: validate after the user finishes a field, usually on blur or after selection, not while they are still typing. Use inline validation for fields with high error rates, strict formats, uniqueness checks, limits, or large valid answer sets.
Override when: a live counter or meter directly supports answer construction, such as character limits or password strength; make the feedback nonblocking while typing.
默认：在用户完成字段输入后进行验证，通常在失去焦点或选择后，而非输入过程中。错误率高、格式严格、唯一性检查、有输入限制或有效答案集较大的字段，使用内联验证。
例外情况：实时计数器或进度条直接辅助输入构建时（如字符限制或密码强度），输入过程中提供非阻塞反馈。

Error messages

错误提示

Default: provide a top-level error summary for long forms or multiple errors and inline field-level remedies for each problematic field. Mark error fields with text plus visual emphasis, not color alone.
Override when: a very short form has only one obvious error and the inline message is in view.
默认：长表单或多错误场景提供顶部错误摘要，每个问题字段提供内联解决方案。用文本加视觉强调标记错误字段，不要仅依赖颜色。
例外情况：极短表单仅有一个明显错误且内联提示在视野内时。

Submit button and submission state

提交按钮与提交状态

Default: keep the primary action visible and enabled; when clicked, clearly show processing and prevent duplicate submission. Avoid hiding or disabling the submit button before submission unless the reason is communicated and the next fix is obvious.
Override when: a destructive, irreversible, or legally sensitive action requires explicit prerequisites; explain what is missing and move focus to the first blocker.
默认：保持主要操作可见且可用；点击后清晰展示处理状态并防止重复提交。除非原因明确且修复方法显而易见，否则不要在提交前隐藏或禁用提交按钮。
例外情况：破坏性、不可逆或法律敏感操作需要明确前置条件时，说明缺失内容并将焦点移至第一个阻碍项。

Checkout

结账流程

Default: support guest checkout or account-after-purchase, keep order summary and total visible, minimize offramps, ask for delivery/payment information in a sensible order, and postpone account/profile questions.
Override when: the product cannot fulfill the transaction without an account, identity verification, eligibility, or saved relationship.
默认：支持访客结账或购买后创建账户，保持订单摘要和总价可见，最小化跳转，按合理顺序询问配送/支付信息，推迟账户/个人资料相关问题。
例外情况：产品无法在无账户、身份验证、资格审核或已有关系的情况下完成交易时。

Progress indicators

进度指示器

Default: omit progress bars for short, uncertain, or dynamically branching forms. Show scope, position, and save/status only for stable multi-step flows.
Override when: long forms need reassurance but steps are dynamic; use general progress language such as "Almost done" or section completion rather than precise step counts.
默认：短表单、不确定流程或动态分支表单不使用进度条。仅在稳定的多步骤流程中展示范围、位置及保存/状态信息。
例外情况：长表单需要安心提示但步骤动态时，使用通用进度表述（如“即将完成”）或章节完成状态，而非精确步骤计数。

Accessibility level

可访问性标准

Default: design to WCAG-style expectations: semantic controls, visible labels, keyboard access, meaningful focus, sufficient contrast, text alternatives, no color-only cues, scalable text, and error messaging announced to assistive technology.
Override: do not lower accessibility. For high-risk domains, ask whether additional accessibility, testing, or legal conformance is required.
默认：按照WCAG级别的期望设计：语义化控件、可见标签、键盘访问、有意义的焦点、足够的对比度、文本替代方案、不依赖颜色的提示、可缩放文本，以及向辅助技术播报错误提示。
例外情况：不要降低可访问性要求。高风险领域需询问是否需要额外的可访问性、测试或法规合规要求。

Frontend implementation

前端实现

Default: use semantic HTML first; style the native controls when possible; prefer design-system components that preserve native semantics; build form state around field value, touched/dirty status, validation status, submission status, and server error status.
Override when: a custom interaction is necessary; require keyboard, focus, screen reader, and mobile input behavior before recommending it.
默认：优先使用语义化HTML；尽可能对原生控件进行样式定制；优先选择保留原生语义的设计系统组件；围绕字段值、已触摸/已修改状态、验证状态、提交状态及服务器错误状态构建表单状态。
例外情况：需要自定义交互时，需确保键盘、焦点、屏幕阅读器及移动端输入行为符合要求后再推荐。

Required user questions

需向用户询问的问题

Ask a focused question only when the answer changes the recommended form design. Do not ask routine best-practice questions.
Ask when any of the following are unknown and materially affect the work:
  • The form's business/user goal is ambiguous.
  • The flow involves checkout, payment, identity, legal consent, healthcare, finance, government, minors, accessibility compliance, or irreversible consequences.
  • The form has many fields and it is unclear which are required, optional, inferable, or deferrable.
  • The audience, locale, language, device mix, or assistive technology needs are likely to change label length, input formats, keyboard behavior, or trust messaging.
  • A tradeoff exists between one-page versus multi-page, speed versus careful review, visible options versus compact controls, or guest checkout versus account creation.
  • Existing analytics/research are needed to diagnose drop-off, error rates, or conversion problems.
Use the question-tool-ready prompts in references/decision-prompts.md.
仅当答案会改变表单设计建议时，才提出针对性问题。不要询问常规最佳实践问题。
当以下信息未知且对工作有实质性影响时，进行询问：
  • 表单的业务/用户目标不明确。
  • 流程涉及结账、支付、身份验证、法律同意、医疗、金融、政府、未成年人、可访问性合规或不可逆后果。
  • 表单包含多个字段，且无法明确哪些是必填、可选、可推断或可延迟的。
  • 受众、地区、语言、设备组合或辅助技术需求可能改变标签长度、输入格式、键盘行为或信任相关文案。
  • 存在单页与多页、速度与仔细审核、可见选项与紧凑控件、访客结账与账户创建之间的权衡。
  • 需要现有分析/研究来诊断流失率、错误率或转化问题。
使用references/decision-prompts.md中的问题工具就绪提示。

Workflow for critiquing existing forms

现有表单评审工作流

Inspect in this order:
  1. Goal fit: What is the user trying to accomplish, and does the form delay or block it unnecessarily?
  2. Question necessity: Which fields can be removed, inferred, defaulted, made optional, or postponed?
  3. Flow and sequence: Does the order match how people think about the task? Are sensitive or high-effort questions delayed until trust/context exists?
  4. Structure and grouping: Are related questions grouped with the least visual noise necessary? Is branching handled without disorientation?
  5. Scan line and layout: Can a person move steadily from label to input to action without zigzagging, jumping columns, or missing important information?
  6. Labels and controls: Are labels visible, succinct, durable, and associated with the right semantic controls?
  7. Help and microcopy: Is help contextual and minimal? Does it explain only what design cannot make obvious?
  8. Validation and errors: Are errors prevented where possible, shown at the right time, and written as actionable remedies?
  9. Submission and success: Is the primary action clear? Are loading, duplicate-submit prevention, success, and next steps handled?
  10. Accessibility and implementation: Does the form work by keyboard, screen reader, touch, mobile keyboard, zoom, and without color-only cues?
  11. Measurement: Recommend testing or analytics for completion rate, drop-off, error locations, time to complete, support contacts, and qualitative frustration.
When presenting critique, group findings by severity: blockers, high-friction issues, accessibility issues, conversion opportunities, polish.
按以下顺序检查：
  1. 目标匹配度：用户试图完成什么目标？表单是否不必要地延迟或阻碍了目标达成？
  2. 问题必要性：哪些字段可以移除、推断、设置默认值、设为可选或推迟？
  3. 流程与顺序：问题顺序是否符合用户对任务的认知？敏感或高操作负担的问题是否推迟到建立信任/上下文之后？
  4. 结构与分组：相关问题是否以最少的视觉干扰进行分组？分支流程是否不会使用户迷失方向？
  5. 扫描路径与布局：用户能否从标签到输入框再到操作平稳移动，无需来回跳转、跨列或遗漏重要信息？
  6. 标签与控件：标签是否可见、简洁、持久，并与正确的语义化控件关联？
  7. 帮助文本与微文案：帮助文本是否上下文相关且简洁？是否仅解释设计无法直观呈现的内容？
  8. 验证与错误处理：是否尽可能预防错误？错误是否在合适的时机展示？是否以可操作的解决方案形式呈现？
  9. 提交与成功状态：主要操作是否清晰？加载状态、防重复提交、成功状态及后续步骤是否处理得当？
  10. 可访问性与实现：表单是否支持键盘、屏幕阅读器、触摸、移动端键盘、缩放，且不依赖颜色作为唯一提示？
  11. 度量建议：建议测试或分析完成率、流失率、错误位置、完成时间、支持联系量及用户定性反馈的挫败感。
呈现评审结果时，按严重程度分组：阻碍项、高摩擦问题、可访问性问题、转化机会、优化细节。

Workflow for creating or improving a form

表单创建或优化工作流

  1. Clarify the task. Identify the user's goal, business goal, required output, audience, device mix, and constraints.
  2. Define the minimum successful submission. List fields as required, optional, inferable, defaultable, and deferrable.
  3. Choose the flow shape. Single page, multi-step, one-question-per-page, progressive disclosure, or gradual engagement.
  4. Order the questions. Start with low-friction/context-setting questions; delay account, sensitive, legal, or high-effort questions until they are justified.
  5. Group fields by user topic. Use headings, whitespace, fieldsets, and legends; avoid decorative dividers that add visual noise.
  6. Select controls and labels. Choose the simplest native control that matches the question; use visible labels and expected input attributes.
  7. Add defaults and help. Default only when likely correct; keep help adjacent, brief, and specific.
  8. Design validation and errors. Prevent errors, validate at humane timing, summarize when needed, and provide field-level remedies.
  9. Design submission states. Make primary, secondary, loading, duplicate-submit prevention, success, and next steps explicit.
  10. Check accessibility and frontend feasibility. Verify semantic HTML, focus, keyboard order, ARIA where needed, responsive behavior, and design-system fit.
  11. Explain tradeoffs. State the chosen default, why it is appropriate, and what would change under different constraints.
  1. 明确任务：确定用户目标、业务目标、所需输出、受众、设备组合及约束条件。
  2. 定义最小成功提交项：将字段列为必填、可选、可推断、可设置默认值及可延迟。
  3. 选择流程形态：单页、多步骤、单问题单页、渐进式披露或逐步引导。
  4. 排序问题：从低操作负担/上下文设置类问题开始；将账户、敏感、法律或高操作负担的问题推迟到必要时。
  5. 按用户主题分组字段：使用标题、空白区域、字段集和图例；避免添加视觉噪音的装饰性分隔符。
  6. 选择控件与标签：选择与问题匹配的最简单原生控件；使用可见标签及预期输入属性。
  7. 添加默认值与帮助文本：仅在大概率正确时设置默认值；保持帮助文本就近、简洁且具体。
  8. 设计验证与错误处理：预防错误，在人性化时机进行验证，必要时提供摘要，并提供字段级解决方案。
  9. 设计提交状态：明确主要操作、次要操作、加载状态、防重复提交、成功状态及后续步骤。
  10. 检查可访问性与前端可行性：验证语义化HTML、焦点、键盘顺序、必要的ARIA属性、响应式行为及设计系统适配性。
  11. 解释权衡：说明所选默认方案及其合理性，以及不同约束条件下的变化。

Decision framework

决策框架

Use this order of preference before adding complexity:
  1. Remove the question.
  2. Infer the answer from known context or system data.
  3. Default the answer when the default aligns with most users' goals and is easy to change.
  4. Defer the question until after the core task or until the answer becomes relevant.
  5. Ask the question in the simplest possible way.
  6. Explain why the question is needed when people may wonder, worry, or lack context.
  7. Validate at the least disruptive time.
  8. Recover gracefully when the answer is missing, wrong, or rejected by the server.
添加复杂度前，按以下优先级操作：
  1. 移除该问题。
  2. 从已知上下文或系统数据中推断答案。
  3. 设置默认值，当默认值符合大多数用户目标且易于修改时。
  4. 推迟该问题，直到核心任务完成或答案变得相关时。
  5. 以最简单的方式询问该问题。
  6. 解释为什么需要该问题，当用户可能产生疑惑、担忧或缺乏上下文时。
  7. 在最少干扰的时机进行验证。
  8. 当答案缺失、错误或被服务器拒绝时，优雅地恢复。

Practical rules

实用规则

Structure and flow

结构与流程

  • Name the form with a title that matches the user's expected task, not the internal database object.
  • For checkout, avoid sign-in walls. Let people proceed as guests or create an account after purchase whenever feasible.
  • Break long forms into meaningful topics; do not split a short form into many pages just to simulate engagement.
  • Use one thing per page when focus, branching, mobile ergonomics, or comprehension matter more than visible overview.
  • Use progress indicators only when they honestly communicate scope, current position, and status.
  • Provide save/resume for long, high-effort forms.
  • 表单标题应匹配用户预期任务，而非内部数据库对象名称。
  • 结账流程避免登录墙，尽可能允许用户以访客身份继续，或在购买后创建账户。
  • 将长表单拆分为有意义的主题；不要为了模拟互动而将短表单拆分为多个页面。
  • 当焦点、分支流程、移动端人体工程学或理解度比可见概览更重要时，使用单问题单页布局。
  • 仅当进度指示器能如实传达范围、当前位置及状态时才使用。
  • 为长且高操作负担的表单提供保存/恢复功能。

Labels and questions

标签与问题

  • Write labels as short, concrete questions or noun phrases in the user's language.
  • Use consistent capitalization. Avoid all caps except for narrow warning contexts.
  • Keep labels visible after the user types. Placeholder text can supplement, not replace, labels.
  • Do not mix label alignments within the same form.
  • Prefer top-aligned labels for familiar data and mobile-first work.
  • Prefer left-aligned labels only when scanning unfamiliar or many optional fields matters more than speed.
  • 标签以简短、具体的问题或用户语言中的名词短语编写。
  • 使用一致的大小写规则，除了狭窄的警告场景外，避免全大写。
  • 用户输入后标签仍保持可见，占位符文本可作为补充，但不能替代标签。
  • 同一表单内不要混合标签对齐方式。
  • 熟悉的数据及移动端优先工作优先使用顶部对齐标签。
  • 仅当扫描陌生或大量可选字段比速度更重要时，优先使用左侧对齐标签。

Grouping and visual hierarchy

分组与视觉层级

  • Use proximity and whitespace before lines, panels, or alternating backgrounds.
  • Use fieldsets and legends for groups of radio buttons, checkboxes, and related controls.
  • Give the primary action a clear visual relationship to the fields it submits.
  • Avoid two-column layouts unless tab order, responsive collapse, and scanning remain obvious.
  • 优先使用邻近性和空白区域，而非线条、面板或交替背景。
  • 对单选按钮、复选框及相关控件组使用字段集和图例。
  • 主要操作与提交的字段保持清晰的视觉关联。
  • 除非制表符顺序、响应式折叠及扫描仍清晰可见，否则避免双列布局。

Controls

控件

  • Use radio buttons when one option among a small set must be selected and all options should be visible.
  • Use checkboxes for independent choices or a single yes/no consent/option.
  • Avoid select boxes for small option sets; they hide choices and add interaction cost.
  • For long lists, consider autocomplete/combobox with accessible keyboard behavior and clear valid suggestions.
  • Make option labels clickable; ensure the input and its label share the same activation target.
  • Use mobile-appropriate input types and attributes: 
    email
    , 
    tel
    , 
    url
    , 
    number
    only when numeric behavior is truly appropriate, 
    autocomplete
    , 
    inputmode
    , 
    autocapitalize
    , 
    spellcheck
    , and 
    aria-describedby
    as needed.
  • 当必须从少量选项中选择一个且所有选项应可见时，使用单选按钮。
  • 独立选择或单一的是/否同意/选项使用复选框。
  • 小选项集避免使用选择框，因为它会隐藏选项并增加交互成本。
  • 长列表考虑使用具备可访问键盘行为及清晰有效建议的自动完成/组合框。
  • 选项标签可点击；确保输入框及其标签共享同一激活目标。
  • 使用适合移动端的输入类型和属性：
    email
    、
    tel
    、
    url
    、仅当确实需要数字行为时使用
    number
    ，以及
    autocomplete
    、
    inputmode
    、
    autocapitalize
    、
    spellcheck
    和
    aria-describedby
    （按需使用）。

Required, optional, and deferrable inputs

必填、可选与可延迟输入项

  • Remove optional fields unless they serve a clear user or business purpose.
  • Mark the minority case: optional when most are required, required when most are optional.
  • Use text over symbols for clarity. If using an asterisk, provide a legend and accessible label.
  • Ask for promo codes, account creation, marketing preferences, and profile enrichment only when contextually useful; otherwise defer.
  • 除非服务于明确的用户或业务目的，否则移除可选字段。
  • 标记少数情况：大多数字段必填时标记可选，大多数字段可选时标记必填。
  • 为清晰起见，使用文本而非符号。如果使用星号，提供图例及可访问标签。
  • 仅在上下文有用时询问优惠码、账户创建、营销偏好及个人资料完善；否则推迟询问。

Defaults and personalization

默认值与个性化

  • Use defaults to reduce work only when the default is likely correct, reversible, and aligned with user interests.
  • Do not default to hidden costs, marketing opt-ins, premium plans, or risky permissions.
  • Personalize defaults for returning users when the information is likely stable and easy to change.
  • Be careful with country, delivery, and payment defaults: wrong defaults can cause costly errors.
  • 仅当默认值大概率正确、可撤销且符合用户利益时，使用默认值减少操作。
  • 不要默认设置隐藏成本、营销订阅、高级计划或风险权限。
  • 为回头用户个性化默认值，当信息大概率稳定且易于修改时。
  • 谨慎设置国家、配送及支付默认值：错误的默认值可能导致高昂的错误成本。

Help text

帮助文本

  • Use help for unfamiliar terms, sensitive data, privacy/security reassurance, unusual formatting, answer limits, or why a field is needed.
  • Place help adjacent to the relevant label/input or in a consistent help area for complex repeated-use forms.
  • Avoid long instruction blocks before the form; people often jump directly into fields.
  • Do not use help text to compensate for bad labels, wrong controls, arbitrary formats, or unnecessary questions.
  • 帮助文本用于陌生术语、敏感数据、隐私/安全保障、特殊格式、输入限制或字段必要性说明。
  • 帮助文本置于相关标签/输入框附近，或复杂重复使用表单的统一帮助区域。
  • 避免在表单前添加长说明块，用户通常会直接跳至字段输入。
  • 不要使用帮助文本弥补糟糕的标签、错误的控件、任意的格式或不必要的问题。

Validation, errors, and success

验证、错误与成功状态

  • Accept flexible human input where possible, such as varied phone/credit card spacing, then normalize after entry.
  • Validate uniqueness, availability, strict formats, and limits at the point they are useful.
  • Do not show errors while the user is still typing a normal answer.
  • Explain the problem, the location, and the remedy.
  • On long forms, provide an error summary and link/focus to each field error.
  • Use text, icon/shape, and styling for errors; reserve red/warning icons for errors so they retain meaning.
  • After successful submission, confirm what happened and provide the next logical action. Avoid dead-end success screens.
  • 尽可能接受灵活的人工输入，如不同格式的电话/信用卡间距，输入后再标准化。
  • 在有用的时机验证唯一性、可用性、严格格式及限制。
  • 用户输入正常答案时不要显示错误。
  • 说明问题、位置及解决方案。
  • 长表单提供错误摘要并链接/聚焦到每个错误字段。
  • 使用文本、图标/形状及样式标记错误；将红色/警告图标保留给错误，以保持其含义。
  • 成功提交后，确认操作结果并提供下一个合理操作，避免无后续的成功页面。

Checkout-specific rules

结账流程特定规则

  • Keep checkout visually calmer than browsing. Remove unrelated navigation, offers, and links that lead away from completion.
  • Preserve cart context: item count, editable order summary, shipping/billing/payment totals, taxes/fees when known, and delivery expectations.
  • Ask questions in a sequence people expect: contact/email, delivery/location, delivery method, payment, review/confirm. Adjust when the product context requires another order.
  • Defer account creation, password, preferences, and marketing until after purchase whenever possible.
  • Make payment/security reassurance specific and verifiable, not generic decoration.
  • Keep promo-code entry available but visually secondary unless discounts are central to the business model.
  • Ensure the final action communicates consequence: place order, pay, subscribe, submit application, save changes.
  • 结账流程视觉上比浏览更简洁，移除无关导航、优惠信息及偏离完成路径的链接。
  • 保留购物车上下文：商品数量、可编辑订单摘要、配送/账单/支付总额、已知税费及配送预期。
  • 按用户预期顺序询问问题：联系方式/邮箱、配送/位置、配送方式、支付、审核/确认。根据产品上下文调整顺序。
  • 尽可能将账户创建、密码设置、偏好及营销订阅推迟到购买后。
  • 支付/安全保障文案应具体且可验证，而非通用装饰。
  • 优惠码输入保持可用，但视觉上处于次要位置，除非折扣是业务核心。
  • 最终操作应明确传达后果：下单、支付、订阅、提交申请、保存更改。

Accessibility and inclusion requirements

可访问性与包容性要求

Always check:
  • Every field has an accessible name, preferably a visible 
    <label>
    associated with 
    for
    /
    id
    or a wrapping label.
  • Related controls use semantic grouping: 
    <fieldset>
    and 
    <legend>
    for radio/checkbox groups.
  • Error and help text are programmatically associated with fields via 
    aria-describedby
    or equivalent.
  • Error summaries are focusable, announced, and provide links to invalid fields.
  • Focus order follows visual/task order; no keyboard traps; all controls and help triggers work without a mouse.
  • Focus states are visible and not removed by CSS.
  • The form works at zoom and with larger text; mobile layouts do not hide labels or error messages.
  • Color is never the only signal. Add text, icon/shape, and programmatic state.
  • Motion, flashing, and automatic changes are minimized; dynamic validation is polite and not disruptive.
  • Timeouts provide warning, extension, and no loss of work when possible.
  • Copy avoids references that depend only on physical location, color, or visual shape, such as "the green button on the right."
  • Test with intended users, including users with disabilities, when the flow is critical.
始终检查：
  • 每个字段都有可访问名称，优先使用与
    for
    /
    id
    关联的可见
    <label>
    或包裹式标签。
  • 相关控件使用语义化分组：单选/复选框组使用
    <fieldset>
    和
    <legend>
    。
  • 错误及帮助文本通过
    aria-describedby
    或等效方式与字段关联。
  • 错误摘要可聚焦、可播报，并提供指向无效字段的链接。
  • 焦点顺序遵循视觉/任务顺序；无键盘陷阱；所有控件及帮助触发器无需鼠标即可操作。
  • 焦点状态可见，未被CSS移除。
  • 表单在缩放和大文本模式下可用；移动端布局不会隐藏标签或错误提示。
  • 颜色永远不是唯一的信号，添加文本、图标/形状及程序状态。
  • 最小化动画、闪烁及自动变化；动态验证应友好且无干扰。
  • 超时提供警告、延长时间，尽可能不丢失已输入内容。
  • 文案避免仅依赖物理位置、颜色或视觉形状的表述，如“右侧的绿色按钮”。
  • 当流程至关重要时，与目标用户（包括残障用户）一起测试。

Frontend implementation guidance

前端实现指导

Use semantic HTML before adding JavaScript complexity.
html
<form novalidate>
  <fieldset>
    <legend>Delivery method</legend>
    <label><input type="radio" name="delivery" value="ship"> Ship to address</label>
    <label><input type="radio" name="delivery" value="pickup"> Pick up in store</label>
  </fieldset>

  <label for="email">Email address</label>
  <input id="email" name="email" type="email" autocomplete="email" autocapitalize="none" spellcheck="false" aria-describedby="email-help email-error">
  <p id="email-help">We will send your receipt and delivery updates here.</p>
  <p id="email-error" role="alert" hidden>Enter an email address, like name@example.com.</p>

  <button type="submit">Continue to payment</button>
</form>
Implementation rules:
  • Do not replace native controls with custom controls unless the custom version preserves keyboard and assistive technology behavior.
  • Keep DOM order aligned with the visual order, especially in multi-column layouts.
  • Avoid positive 
    tabindex
    ; fix DOM order instead. Use 
    tabindex="-1"
    only to programmatically focus summaries or headings.
  • Model form state explicitly: value, dirty/touched, client validity, server validity, loading/submitting, success, and recoverable failure.
  • For server validation, preserve user-entered values and return field-level errors keyed to stable field names.
  • Disable or guard against duplicate submission after click; communicate processing state and keep the label/consequence understandable.
  • Do not hide the only submit path because a validation condition is unmet unless the UI also explains the blocker and how to fix it.
  • Use 
    autocomplete
    tokens for common checkout fields: name, email, tel, street-address, address-line1, address-level2, postal-code, country, cc-name, cc-number, cc-exp, cc-csc where appropriate.
  • Use 
    inputmode
    for numeric-looking text values that should not be number inputs, such as postal codes, phone numbers, and card numbers.
  • Format after input when possible rather than rejecting common human formats.
  • Component APIs should accept visible label, help text, error text, required/optional text, described-by IDs, and design tokens for spacing/state.
添加JavaScript复杂度前优先使用语义化HTML。
html
<form novalidate>
  <fieldset>
    <legend>Delivery method</legend>
    <label><input type="radio" name="delivery" value="ship"> Ship to address</label>
    <label><input type="radio" name="delivery" value="pickup"> Pick up in store</label>
  </fieldset>

  <label for="email">Email address</label>
  <input id="email" name="email" type="email" autocomplete="email" autocapitalize="none" spellcheck="false" aria-describedby="email-help email-error">
  <p id="email-help">We will send your receipt and delivery updates here.</p>
  <p id="email-error" role="alert" hidden>Enter an email address, like name@example.com.</p>

  <button type="submit">Continue to payment</button>
</form>
实现规则：
  • 不要用自定义控件替换原生控件，除非自定义版本保留了键盘和辅助技术行为。
  • DOM顺序与视觉顺序保持一致，尤其是在多列布局中。
  • 避免使用正的
    tabindex
    ；改为修复DOM顺序。仅在以编程方式聚焦摘要或标题时使用
    tabindex="-1"
    。
  • 显式建模表单状态：值、已修改/已触摸、客户端有效性、服务器有效性、加载/提交中、成功及可恢复失败。
  • 服务器验证时，保留用户输入的值，并返回与稳定字段名关联的字段级错误。
  • 点击后禁用或防止重复提交；传达处理状态并保持标签/后果清晰易懂。
  • 不要因验证条件未满足而隐藏唯一提交路径，除非UI同时解释阻碍项及修复方法。
  • 常见结账字段使用
    autocomplete
    令牌：name、email、tel、street-address、address-line1、address-level2、postal-code、country、cc-name、cc-number、cc-exp、cc-csc（按需使用）。
  • 对于不应使用数字输入的类数字文本值（如邮政编码、电话号码及卡号），使用
    inputmode
    。
  • 尽可能在输入后格式化，而非拒绝常见的人工输入格式。
  • 组件API应接受可见标签、帮助文本、错误文本、必填/选文本、关联描述ID及用于间距/状态的设计令牌。

Quality checklist

质量检查清单

Before finalizing a recommendation, verify:
  • The form has a clear user goal and a clear primary action.
  • Every field has a reason to exist now.
  • Optional fields are removed, deferred, or marked as the minority case.
  • The question order matches the user's mental model of the task.
  • The layout provides a single readable path to completion.
  • The controls match the data type and decision type.
  • Labels remain visible and are programmatically associated.
  • Help is contextual, concise, and not compensating for poor design.
  • Validation timing is humane and field errors are actionable.
  • Error and success states are designed, not left to defaults.
  • Checkout avoids account walls and unnecessary offramps unless required.
  • Keyboard, focus, screen reader, color contrast, zoom, and mobile keyboards are covered.
  • The implementation is feasible within the design system and frontend stack.
Use the full checklists in references/checklists.md.
最终确定建议前，验证：
  • 表单有明确的用户目标和主要操作。
  • 每个字段都有当前存在的理由。
  • 可选字段已移除、推迟或标记为少数情况。
  • 问题顺序符合用户对任务的认知模型。
  • 布局提供单一可读的完成路径。
  • 控件与数据类型及决策类型匹配。
  • 标签保持可见并与程序关联。
  • 帮助文本上下文相关、简洁，且未弥补糟糕的设计。
  • 验证时机人性化，字段错误可操作。
  • 错误及成功状态经过设计，未使用默认样式。
  • 结账流程避免账户墙及不必要的跳转，除非有要求。
  • 键盘、焦点、屏幕阅读器、颜色对比度、缩放及移动端键盘均已覆盖。
  • 实现方案在设计系统及前端技术栈内可行。
查看references/checklists.md获取完整检查清单。

Common mistakes to avoid

需避免的常见错误

  • Designing from database fields instead of the user's task.
  • Asking optional/profile/marketing/account questions before the core task.
  • Using placeholders as labels.
  • Using select boxes for short lists.
  • Marking every field required.
  • Using red text for normal labels or help, weakening error meaning.
  • Validating while the user is still typing.
  • Hiding or disabling submit without an obvious remedy.
  • Using progress bars for dynamic or unknown steps.
  • Making secondary/destructive actions visually equal to the primary action.
  • Adding decorative grouping that interrupts scanning.
  • Showing all dependent fields at once and overwhelming the user.
  • Ending with a success page that offers no confirmation or next step.
See references/anti-patterns.md for the full anti-pattern list.
  • 从数据库字段而非用户任务出发进行设计。
  • 在核心任务完成前询问可选/个人资料/营销/账户相关问题。
  • 将占位符作为标签使用。
  • 短列表使用选择框。
  • 为所有字段标记必填。
  • 正常标签或帮助文本使用红色，削弱错误提示的含义。
  • 用户输入过程中进行验证。
  • 隐藏或禁用提交按钮且无明显修复方案。
  • 动态或未知步骤使用进度条。
  • 次要/破坏性操作与主要操作视觉权重相同。
  • 添加干扰扫描的装饰性分组。
  • 一次性显示所有依赖字段，使用户不知所措。
  • 成功页面无确认信息或后续操作。
查看references/anti-patterns.md获取完整反模式列表。

How to explain recommendations to the user

如何向用户解释建议

Explain in terms of completion, confidence, error prevention, and trust.
Use this pattern:
  1. State the recommendation. "Use visible top-aligned labels and keep help text under the field."
  2. Tie it to the user's goal. "This keeps the checkout path easy to scan on mobile and reduces the chance of people losing context while typing."
  3. Mention the tradeoff. "It uses more vertical space, but the form is short enough that clarity is more valuable than density."
  4. Name the exception. "For dense expert settings screens, left-aligned labels may be better because users scan labels before editing."
  5. Give implementation detail only when useful. "Use a real 
    <label>
    and associate help/error text with 
    aria-describedby
    ."
从完成率、置信度、错误预防及信任的角度进行解释。
使用以下模式：
  1. 说明建议：“使用可见的顶部对齐标签，帮助文本置于字段下方。”
  2. 关联用户目标：“这使移动端结账路径易于扫描，减少用户输入时丢失上下文的概率。”
  3. 提及权衡：“这会占用更多垂直空间，但表单足够短，清晰度比密度更重要。”
  4. 说明例外情况：“对于密集的专家设置屏幕，左侧对齐标签可能更合适，因为用户会先扫描标签再编辑。”
  5. 仅在有用时提供实现细节：“使用真实的
    <label>
    ，并通过
    aria-describedby
    关联帮助/错误文本。”