B端表单难用，常常不是因为控件不够好看，而是业务条件藏得太深：选择采购类型后才发现附件要求不同，修改供应商却保留了旧账户，提交失败后还要重新填写整页。优化这类表单，应围绕一个完整任务，把字段、规则、权限和异常处理连成一条清楚的路径。
本文以采购申请为例，说明复杂表单可以怎样整理。重点是业务规则与提交过程；输入框、选择器等基础样式可参考B端表单的常见样式，手机键盘和小屏输入则见移动表单设计。
先做字段字典，暂时别急着画整页
拿到需求后，把字段分成四类：完成任务必需、符合条件才必需、系统已有、可选补充。采购申请中的申请人可能来自账号资料，采购类型需要用户选择，特殊设备附件取决于类型，而内部备注可能只是可选项。字段越多，越需要说明存在理由，不能因为数据库有这一列就要求每个人填写。
每个字段至少记录名称、业务含义、数据来源、格式、必填条件、可编辑角色和依赖关系。例如供应商账户来自已核验资料时，界面应显示来源与核对方式；允许自行输入时，则要明确校验与审核规则。两种流程不能只靠输入框是否变灰来区分。
再为字段增加一列“缺失后果”。少填附件可能阻止审批，少填备注未必影响提交。这个判断帮助团队把真正的硬性要求与习惯性收集分开，也方便在评审时解释为何删掉某个字段。
按业务任务分组，而不是按控件类型分组
把所有下拉框放在一起、把所有文本框放在一起，看上去整齐，却可能打断思考。采购申请更适合按“基本信息—采购明细—审批材料”组织，让用户先说明要买什么，再填写数量和金额，最后补齐相应材料。
单页和分步没有通用优劣。如果用户经常对照上下文修改不同字段，单页分区更便于来回核对；如果任务包含明显阶段、权限或材料准备过程，分步可以减少同屏负担。分步后仍要提供返回修改的方式，并说明返回是否会保留后续内容。
长表单可在提交前提供摘要，展示关键金额、对象和附件数量。摘要应帮助核对风险信息，而不是机械重复每一行。需要修改时，提供能定位到对应分区的入口，避免让用户从第一步重新寻找。
把条件联动画成规则，再实现显隐
一个典型条件是“达到某项审批要求时，需要补充说明与附件”。阈值由业务确定，设计需要写清触发时机、受影响字段以及切换回原条件后的处理。仅在图上标注“动态展示”，无法覆盖这些情况。
- 首次满足条件：显示额外字段，在附近解释原因。不要突然把提交按钮变成不可用，却不指出缺什么。
- 条件不再满足：决定暂存、清除还是排除相关值，并告知用户重要内容的变化。隐藏字段不应悄悄带着过期数据进入提交结果。
- 上游数据改变：供应商切换后，账户、联系人等依赖信息需要重新确认，不能默认沿用上一个对象的数据。
- 规则互相影响：记录优先级，避免一个条件显示字段，另一个条件立即隐藏它。联动形成循环时，先修改业务规则，再优化动效。
条件区域出现后，保持阅读顺序稳定。用户用键盘继续操作时，应能按合理顺序进入新增字段；不要自动跳转到页面另一处，除非完成任务确实需要并已给出清楚提示。
把输入反馈和提交校验分成两层
输入时优先帮助用户正确填写：标签持续可见，格式说明放在需要的位置，必要时提供示例。不要只用占位文字解释复杂要求，因为输入后它会消失。W3C 的表单标签指南说明了字段标签与控件关联的重要性。
错误提示应尽量在合适时机出现。用户还没输完就显示错误，容易造成干扰；对于明确格式，可以在离开字段后检查，并在用户修正时及时更新。跨字段规则，例如结束日期早于开始日期、总金额与明细合计不一致，应清楚指出关联字段，而不是只给页面顶部一个“校验失败”。包含日期范围时，还应约定结束日是否包含、业务时区与快捷范围的边界。
提交时再进行完整检查，汇总未通过的项目，保留已填内容，并让错误条目能定位到对应字段。文案同时说明问题与改法：“请上传报价附件，支持PDF文件”比“附件异常”更有帮助；允许的格式、大小等条件必须与实际服务一致。
前端校验改善操作体验，但不能代替服务端对权限、业务规则和输入数据的检查。W3C 的表单校验说明也明确区分了两者。设计交付时应分别注明“立即提示”和“提交后可能返回”的错误。涉及远端检查时，还要明确异步校验的触发时机与旧请求处理。
权限、只读和不可编辑需要不同表达
申请人、审批人和财务看到的字段未必相同。涉及敏感信息的访问控制必须由服务端实现，界面隐藏并不构成权限保护。设计侧要明确哪些信息不可见、哪些可见但不可改、哪些只有在特定状态下能编辑。
只读字段通常仍有核对价值，可以允许阅读和复制必要内容；不满足条件的操作需要说明原因。若用户发现供应商资料有误却没有修改权限，应给出联系维护人或返回资料管理的路径，避免将一个死灰色控件当成完整解决方案。
审批状态变化时还要处理并发：用户打开表单后，记录可能已被他人修改或审批。提交前发现版本不同，应提供重新加载、对照变化或保留当前输入的合适方式，不能静默覆盖他人的结果。
草稿、重复提交和结果未知，决定了异常体验
长表单适合考虑草稿，但需要明确保存范围、时机、有效期限和权限。显示“已保存”前，应确认相应保存动作成功；本地暂存与服务端草稿也应有清晰区别。包含敏感信息的表单，不应默认无限期保存在共享设备上。
点击提交后，按钮可以进入处理中状态，并防止短时间内再次触发同一动作。前端限制只是体验层的保护，避免重复业务记录还需研发处理请求去重或幂等。网络超时不一定表示业务失败：申请可能已保存，只是结果没有返回，此时应先确认记录状态，再允许重新提交。
失败后保留能安全保留的内容，标明哪些附件需要重新上传、哪些可以继续恢复，以及哪些字段需要复核。成功后提供明确回执和可继续操作的入口，如申请编号、查看详情或返回列表。W3C 的表单通知指南可用于核对成功与失败反馈的完整性。
批量录入时，反馈要对应到具体行
采购明细可能包含多行物料。增加、复制、删除行时，应保持行与错误的对应关系；排序后仍然提示“第三行错误”，却没有稳定标识，容易让用户修改错对象。可以用物料名称、序号和字段一起定位，并区分整单不能提交与个别行待修正的情况。
多行合计需要说明单位、精度和计算方式。界面展示的金额与提交后的金额如果采用不同舍入方式，用户会反复核对却找不到原因。设计评审时用包含小数、空值、零值和删除行的样本走一遍，比只展示整齐的默认数据更容易发现规则遗漏。
用一组任务，验收一张复杂表单
- 普通申请：只填必要字段即可完成；标签、单位和必填条件没有歧义。
- 条件变化：采购类型、金额和对象变更后，相关字段正确更新，没有提交过期隐藏值。
- 多处错误：页面提供可定位的错误汇总，用户修正一处不会丢失其他内容。
- 角色切换：权限与编辑状态符合业务约定，不依赖前端隐藏保护数据。
- 网络与中断：超时、重新打开、返回上一步均有恢复路径，不产生重复申请。
- 键盘与放大：焦点顺序合理，错误能够被识别，文字放大后字段和操作仍可使用。
评估优化效果时，按任务和角色观察完成率、错误类型、反复修改与求助情况，先保证统计口径一致。B端用户可能每天填写多次，减少重复核对和返工，往往比追求一次点击率更贴近真实价值。
在Pixso中制作表单原型时，可以把普通、条件展开、校验失败和提交结果放在相邻画面，再用同一条业务任务走读。让产品、设计、研发共同确认规则，后续美化与组件复用才有稳定基础。
