表单用户体验最佳实践

运行模式

• 默认以纯文本模式运行。
• 除非明确要求，否则避免以图像为主导的评审意见、仪表板建议或视觉重构指引。
• 优先决策能提升完成质量、错误恢复能力、可访问性与用户信任度的优化项。

所需输入

评审前需收集以下信息：

• 表单上下文：注册、结账、设置、线索获取，或其他场景。
• 核心业务目标与用户目标。
• 当前表单来源：需求文档、HTML、React 代码、截图转录的文本，或混合形式。
• 字段列表（注明必填/选填状态）。
• 当前验证行为（内联验证、失焦验证、提交时验证、服务端验证）。
• 目标设备（桌面端、移动端，或两者兼顾）。

初步问询

仅在关键输入缺失时提出问题；若所有关键信息均已提供，则无需提问，直接进入评审流程。

• 该表单应支持的确切决策是什么？（例如：创建账户、完成购买、更新设置、捕获线索）
• 为完成该决策，哪些字段是强制必填的？
• 提交后会发生什么？（成功路径、重试路径、放弃路径）
• 是否存在法律或政策约束？（如年龄校验、账单信息、用户同意、区域合规要求等）

确定性评审工作流

1. 定义任务关键结果：用一句话描述用户成功标准，再用一句话描述业务成功标准。
2. 识别摩擦点：找出所有冗余字段、表述模糊的标签、本可避免的用户决策，以及中断性交互。
3. 审核字段架构：检查字段顺序、分组逻辑、必填/选填标识清晰度，以及是否采用渐进式披露（progressive disclosure）。
4. 审核验证行为：检查验证触发时机、错误提示的具体性、错误恢复路径，以及内联验证与提交验证状态之间的一致性。
5. 审核可访问性语义：包括标签（label）、辅助说明（instructions）、焦点顺序（focus order）、键盘操作支持，以及错误信息与对应控件的关联性。
6. 审核移动端人机工效：输入类型（type）、输入模式（inputmode）、键盘提示（keyboard hints）、间距、触控目标尺寸舒适度，以及滚动与焦点行为。
7. 审核信任信号：对敏感字段说明其采集原因，并在用户做出关键决策的节点附近提供隐私保障声明。
8. 严格按 assets/report_template.md 模板生成输出内容。

参考文档加载规范

• 仅在需要原则级依据，或需在多种表单模式间做权衡取舍时，加载 references/canon.md。
• 执行评审时优先采用上述确定性工作流；参考文档仅用于佐证推荐理由，不得替代直接分析。

可访问性检查项

• 确保每个控件均具备程序化名称（programmatic name），且该名称来源于可见的 label，而非仅依赖 placeholder 文本。
• 确保 label 与控件通过 for/id 属性配对，或采用显式包裹式 label 模式（即控件嵌套在 label 内）。
• 在适用情况下，确保辅助说明文本（helper text）和错误信息通过 aria-describedby 进行引用。
• 验证失败后，确保无效字段设置 aria-invalid="true"。
• 若使用错误汇总（error summary），须确保其链接至每个无效字段，并在提交失败后自动获得焦点。
• 确保 Tab 键/焦点顺序与视觉呈现顺序及逻辑顺序一致。
• 确保仅通过键盘即可完成全部操作，无需依赖指针交互。

移动端检查项

• 使用正确的键盘提示属性（type、inputmode、autocomplete、autocapitalize）。
• 输入过程中持续保持标签可见性。
• 避免在窄屏设备上采用多列字段布局，以防压缩触控目标尺寸。
• 确保辅助说明与错误文本紧邻对应字段，且无需水平滚动即可完整可见。
• 避免强制性的上下文切换循环（例如：字段失焦 → 页面跳转 → 键盘反复关闭/唤起）。

验证策略

• 必填校验应在提交时触发，而非首次按键即校验。
• 格式校验应在字段失焦时，或已输入足够字符可推断用户意图时触发。
• 实时验证（real-time validation）仅适用于高价值、低噪声场景（例如：密码强度指示器、用户名可用性检测）。
• 每个错误应提供一项清晰明确的恢复操作。
• 内联错误文案须与提交时错误汇总中的文案保持一致。
• 对于存在多个错误的表单，或字段较多、首处错误可能位于视口外的长表单，应使用错误汇总（error summary）。

字段设计规则

• 优先采用置于字段上方的显式标签；切勿以 placeholder 文本替代标签。
• 显式标注选填字段；默认将字段设为必填，除非产品策略明确要求对所有必填字段添加显式“必填”标识（required badge）。
• 仅请求当前决策所必需的最少数据。
• 对相关字段进行合理分组，并遵循用户的认知模型顺序（例如：结账流程中为「联系信息 → 配送信息 → 支付信息」）。
• 若约束条件可预知（如格式、长度、字符限制等），应在用户输入前予以明确说明。

微文案规则

• 使用直截了当、具体明确的措辞，清晰指出问题所在及下一步操作。
• 避免归咎性语言与模糊表述（例如：“输入无效”）。
• 若某类格式错误频发，应在错误提示中说明可接受的格式。
• 语气保持中立，聚焦于帮助用户恢复操作。
• 确保标签、辅助说明与错误文案中对同一字段的命名完全一致。

隐私与信任提示

• 在请求敏感信息的当下，即刻解释其必要性。
• 将信任提示置于关键承诺动作附近（如「提交」或「下单」按钮旁），而非埋入页脚文字中。
• 对通讯类字段，明确说明用户同意的范围与频率。
• 将强制性的运营所需同意（mandatory operational consent）与可选的营销用途同意（optional marketing consent）明确分离。

转化率与摩擦度优化规则

• 从初始流程中移除非必要字段。
• 对次要细节采用渐进式披露（progressive disclosure）。
• 在安全且可逆的前提下，优先采用智能默认值（smart defaults）。
• 提交失败后，保留用户已输入的所有字段值。
• 除非风险显著，否则尽量减少冗余的确认字段（如重复密码、二次邮箱确认等）。

问题优先级评估标准（P0 / P1 / P2）

• P0：阻碍表单完成、引发法律/合规风险，或导致辅助技术完全无法使用该表单。
• P1：造成严重理解障碍、本可避免的错误，或带来可测量的放弃风险。
• P2：提升清晰度、操作速度与整体质感，但不阻断表单完成流程。

输出格式

始终严格按以下顺序填充 assets/report_template.md 的各章节：

1. 首要问题（P0 / P1 / P2）
2. 逐字段改写建议
3. 验证机制与错误文案规范
4. 可访问性检查清单
5. 上线就绪检查清单
6. 可选：可直接交付的代码片段

可选：可交付代码片段模式

当被要求提供可直接投入实施的指导时：

• 输出语义化 HTML 或 React 伪代码。
• 包含标签（label）、辅助文本钩子（helper text hooks）、错误绑定（error bindings）及 autocomplete 属性。
• 若存在两个及以上可能同时发生的错误，需包含提交时的错误汇总模式（submit-time summary pattern）。
• 代码片段应聚焦于表单行为逻辑与语义结构，不涉及视觉样式（CSS）相关内容。

可选：静态审计脚本

使用 scripts/form_audit.py 对 HTML 表单执行快速静态检查。

python3 scripts/form_audit.py /path/to/form.html

脚本检测项包括：

• 缺失 label 映射（missing label mapping）
• 重复 ID（duplicate IDs）
• 缺失 name 属性（missing name attributes）
• 误将 placeholder 当作 label 使用（placeholder used as label）
• 常见字段缺失 autocomplete 属性（missing autocomplete for common fields）
• 疑似 input type 不匹配（likely input type mismatches）