Form UX Architecture

Form UX Architecture

Concept of the skill

Form UX architecture is the discipline of structuring a form and its validation behavior so that data entry becomes a guided conversation rather than a data dump. It owns a connected set of decisions: which fields to ask for (the minimum the user's goal truly requires), how to group them (by the user's mental model, not by a storage table), how to classify each one (required, optional, defaulted, derived, or deferred), when validation fires (on submit, on blur, on change, or after an async check), how to split the client-side correction aid from the mandatory server-side trust check, and how the whole submission lifecycle behaves (submit, pending, success, failure, retry, partial-save, and error recovery). Its central principle is that client-side validation is a user-experience aid and never a security boundary — the server must validate every submitted field even when the client appears correct — and its central craft is asking only for what is needed, at the moment the user can answer, with correction paths that preserve trust and the data already entered. It deliberately hands off neighbors it does not own: labels and announcements to a11y, message wording to microcopy, endpoint shape to api-design, and persistence to entity-relationship-modeling.

Coverage

Design form structure and validation behavior. Covers field grouping, labels as structure handoff, required vs optional decisions, progressive disclosure, defaults, input formats, client-side validation, server-side validation, validation timing, submit lifecycle, error recovery, multi-step forms, review steps, autosave, and high-risk data entry.

Philosophy of the skill

Forms are not data dumps. A form is a guided conversation that asks only for information the system truly needs, at the moment the user can answer it, with correction paths that preserve trust.

Client-side validation is a user-experience aid, not a security boundary. The server must validate every submitted field even when the client appears correct.

Method

1. Name the user goal and the minimum data needed to complete it.
2. Remove fields that are not needed now or cannot be acted on.
3. Group fields by user mental model, not database table.
4. Decide required, optional, defaulted, derived, and deferred fields.
5. Choose validation timing: on submit, on blur, on change, or after async check.
6. Split client-side validation from server-side validation and map server errors back to fields.
7. Define submit, pending, success, failure, retry, and partial-save behavior.
8. Hand off labels and announcements to a11y, wording to microcopy, and endpoint shape to api-design.

Verification

• Every field has a reason tied to the user's goal or system requirement
• Required fields are truly required at this step
• Field groups match how users think about the task
• Validation timing avoids hostile on-keystroke errors unless immediate feedback is necessary
• Client-side checks improve correction speed but do not replace server validation
• Server errors map back to fields or a clear form-level recovery path
• Submit, pending, success, failure, retry, and partial-save states are defined

Do NOT Use When