Complete complex form

Problem Context

• The task configures enterprise software, policies, permissions, automation rules, workspace settings, billing rules, compliance controls, or other related product options.
• Users must compare values across sections, such as a threshold in one section that changes approval requirements in another.
• Most fields may be optional, but a small set of required fields and dependencies still block save.
• The product can preserve a form draft while users move between sections, validation errors, and review.

Selection Rules

• Choose a complete complex form when many related configuration fields need one inspectable surface and cross-section comparison matters.
• Use a single-page form instead when the task is a compact related field set that does not need section status or dependency review.
• Use a multi-step form instead when the task is a long transaction best completed across saved pages with focused recovery per page.
• Use a wizard instead when the product must guide users through a dependent setup or creation assistant with step-specific actions, tests, cancel, and finish behavior.
• Use one-question pages instead when research shows each answer needs focus, branching, mobile-first recovery, or one thing per page.
• Group related inputs under section headings, fieldsets, legends, and helper text rather than relying on columns or visual proximity.
• Expose section status from real validation, dependency, and review state; never mark a section complete simply because it was visited.
• Validate cross-section rules in the owning section and keep all entered values visible or recoverable after validation fails.
• For long product configuration forms where most fields are optional, label the required fields explicitly and keep that convention consistent across the product.
• Require review again when an upstream answer changes a downstream rule, generated summary, approval path, notification effect, or save consequence.

Required States

• Initial draft state with named sections, required-field convention, grouped controls, and save unavailable or clearly pending validation.
• Current section state with visible section heading, fields, helper text, and local actions.
• Edited section state that preserves entered values before validation.
• Section complete state derived from required fields, local validation, and dependencies.
• Section error state with status text, summary link, and field-level messages.
• Cross-section dependency error state where a value in one section changes requirements in another.
• Optional section state that does not block save but remains inspectable.
• Stale review state after a dependency or high-risk field changes.
• Review state that summarizes important values and dependencies before save.
• Saved state that confirms the complete configuration was accepted.

Interaction Contract

• Section navigation changes the visible section without discarding draft values.
• Validate all sections reports every save-blocking issue and moves focus or context to the first owning section.
• Error summary entries identify the section and field group responsible for each problem.
• Field-level errors sit next to the owning control and use the same wording as the summary where practical.
• Save is blocked until required fields, cross-section dependencies, and required review are complete.
• Changing a dependency marks affected sections or review stale until validation or review runs again.
• Optional fields and optional sections remain available without being confused with unavailable or disabled states.

Implementation Checklist

• Inventory sections, fields, required rules, optional rules, and dependencies before building the layout.
• Assign each dependency error to one owning section and field group so recovery has a clear destination.
• Use persistent labels, fieldsets, legends, helper text, and simple vertical ordering inside each section.
• Add section status derived from actual validation and review state.
• Implement error summary links that move users to the relevant section and field.
• Preserve draft values across section jumps, failed validation, reload recovery, and server responses.
• Represent stale review or stale dependent sections after upstream changes.
• Avoid dense multi-column grids unless reading order, labels, validation expansion, and responsive behavior remain predictable.
• Test keyboard order, screen reader section names, error summary navigation, zoom, mobile section navigation, draft preservation, dependency validation, and review-before-save behavior.

Common Generated-UI Mistakes

• Calling a dense settings table a complex form without section status, labels, or validation ownership.
• Splitting tightly related settings across pages so dependencies are invisible during editing.
• Using wizard chrome for ordinary configuration edits that do not need guided setup or finish semantics.
• Hiding required fields or save-blocking errors inside advanced disclosure panels.
• Showing generic section errors without field-level messages.
• Marking sections complete because users opened them rather than because data is valid.
• Saving high-risk changes without a review of the combined configuration.
• Making visual column order differ from keyboard and screen-reader order.

Critique Questions

• Which fields or sections depend on values in other sections?
• Can users tell which sections are valid, invalid, optional, not checked, or stale?
• Does each error have an owning section and field-level recovery path?
• Would one-question pages or a multi-step form be easier because the task is public-facing, branched, or mobile-heavy?
• Is this really a guided setup wizard, or is it an editable settings surface?
• What must users review before a high-risk save becomes available?