Design clear forms and validation feedback

Translate real fields and business rules into a complete form structure, accessible feedback and a validation test matrix. A compact direction to help the next screen feel deliberate, specific, and easy to remix.

Design a Web form that people can understand, complete and correct using the supplied task and business rules. Deliver design specifications first; provide code only when explicitly requested with a stack.

INPUT
Task/users: [operation, context, main devices and user characteristics]
Fields/rules: [names, types, required status, ranges, defaults, dependencies; confirmed versus pending]
Submission: [existing API, success behavior, known business errors, duplicate-submission concerns]
Existing conventions: [brand/components, dimensions, language, page or screenshot; optional]
Deliverable: [specification; or specification plus implementation for a specified stack]

METHOD
1. Check whether each field serves the task. Recommend removing fields with no clear purpose; add no sensitive information independently. Ask up to three blocking questions and wait when missing rules, dependencies or success conditions affect correctness. Mark other unknowns; invent no APIs, legal requirements or persistence capabilities.
2. Group and order fields by user understanding and dependencies. Select short/long text, single/multiple choice, select or switch with reasons. Keep visible labels; placeholders are examples, not label replacements. Explain required/optional status, format, units and limits. Show counters for known limits when useful, without presenting examples as actual user data.
3. Build a rule table with provenance, format/length/range constraints, cross-field conditions and client/server responsibilities. Match types and required status to actual rules. Client validation provides feedback and never replaces server checks or establishes account existence, inventory, permissions or uniqueness.
4. Choose validation timing per field with reasons. Do not show errors before initial interaction. Check format or long content on blur or submit when appropriate, then update feedback after correction. Validate the entire form on submission. Provide specific, concise causes and recovery instructions; distinguish field, form and network errors and preserve entered data.
5. Define applicable default, focus, typing, invalid, disabled/read-only field states, plus submitting, success, failure and retry behavior. Without an asynchronous API, submission/result states are proposals only. Prevent duplicate requests while explaining progress. Disable/read-only requires real conditions; clear/redirect after success only according to supplied rules.
6. Associate labels, descriptions and errors with controls and expose invalid state to assistive technology. Do not convey errors by color alone. Define error navigation/focus after failed submission, logical keyboard order, visible focus and readable layouts. Conditional fields need consistent visibility, validation and data-retention rules without interaction dead ends.
7. Check valid, empty, boundary, conflicting-field, server-failure and repeated-submit scenarios from the inputs. When unimplemented or unexecuted, deliver expected behavior and test steps without claiming tests passed.

DELIVER IN ORDER
A. Structure: groups, order, control choice, labels, descriptions, required status and pending rules.
B. Validation matrix: field / rule origin / constraint / timing / error message / client or server responsibility.
C. State/interaction matrix: state / trigger / visible feedback / available action / recovery; identify inapplicable states.
D. Accessibility and verification: label/error relationships, keyboard, focus, non-color feedback and mobile layout; inputs, expected outcomes and actual verification status.
E. Only if requested, complete minimal implementation for the specified stack. With no API supplied, explicitly label demonstration integration points rather than claiming real submission works.

BOUNDARIES
Focus on structure and validation; error messages support interaction rather than marketing copy. Install no library by default. When choosing React Hook Form/shadcn/ui, use Controller, Field, visible FieldLabel, FieldDescription, FieldError and validators according to the actual project version; assume no universal import paths or APIs.

Independent site synthesis from shadcn/ui's official React Hook Form documentation/examples (MIT, Copyright (c) 2023 shadcn). Async form states and server responsibilities are site-added design requirements, not evidence that the original demo implements a real API: https://ui.shadcn.com/docs/forms/react-hook-form .

invented business rules, placeholder-only labels, color-only errors, client validation treated as security, lost inputs after errors, unexplained disabled actions, fake submission APIs, unverified test claims