Design patterns
Form UI design with AI: labels, validation and recovery
Design forms around necessary inputs and recoverable errors. Includes a project-request example and a prompt that specifies more than the happy path.
Ask only for information the task needs
Start a form by writing what happens after submission. For an illustrative project-request form, the recipient may need a contact address, a short description and a preferred start date. A company size field is harder to justify if it does not affect the response.
Decide which inputs are required and explain that convention consistently. Keep visible labels associated with their controls. Placeholder examples can demonstrate format, but they disappear during entry and should not carry the whole labeling task. W3C’s forms tutorial provides the implementation guidance behind these basics.
Write the errors before the layout
List the failures that matter: an invalid contact address, a missing description, an unavailable submission service and a duplicate request. Each needs a different response. A generic “Something went wrong” message does not tell the user whether to correct a field or try again later.
Keep successfully entered values when a request fails. For a project request, a long description may represent significant work. Make it clear whether the request was saved, sent or still waiting. Avoid an optimistic success screen when the system has not confirmed receipt.
Use grouping to explain the task
Separate contact information from project details if it helps the reader understand the request. A one-column form can be easy to scan, but do not turn that into an absolute rule: a short related pair may fit well together. Test the grouping with actual field labels and realistic content.
In Taste, save examples that clarify grouping and inline feedback. Annotate where the example helps a person recover. Decorative treatments around an input are less useful if the label, error and hint become difficult to associate.
Brief the full submission cycle
This prompt keeps the form tied to a concrete action and requires the agent to distinguish simulated behavior from a real integration.
Implement a project-request form using the current component library. Fields: contact email, project description and optional preferred start date. Explain required fields, preserve input after errors and prevent duplicate submission while a request is pending. Use associated labels and meaningful error text. Inspect my Taste form references for grouping and hierarchy. Include invalid input, service failure and confirmed success. Do not claim a request was sent if the backend is mocked.
Try completing it without a mouse
Check the order of focus and whether the submit button has an understandable name. Test validation after submission, correct one error and try again. Verify that the user can find both the error and the corresponding control.
Review with long descriptions, autofill and a narrow viewport. W3C’s notification guidance covers error summaries and inline feedback. A form that looks tidy when empty may still be frustrating once someone has made a mistake.