--- name: forms-inputs-checkout description: "Use when designing, critiquing, or implementing forms, inputs, validation, checkout, registration, payment, or any data-entry flow." license: MIT metadata: author: hueyexe --- # Forms, Inputs, and Checkout ## Purpose Help an agent design, critique, and implement clear, accessible, high-conversion forms, inputs, validation, and checkout flows. Treat every form as a barrier between a person and a goal. The agent's job is to reduce that barrier without collecting bad data, hiding meaningful choices, or weakening accessibility, privacy, legal, or business requirements. ## When to use this skill Use this skill for: - Checkout, cart, payment, shipping, billing, promo-code, account, registration, sign-in, onboarding, subscription, lead-capture, support, survey, settings, profile, upload, and data-entry forms. - Critiquing screenshots, wireframes, Figma descriptions, HTML/CSS/React components, design-system components, or product flows involving forms. - Choosing labels, input controls, grouping, progress indicators, defaults, validation, error messages, help text, submit states, and success states. - Making frontend guidance for semantic HTML forms, accessible names, focus, keyboard flow, validation, and responsive behavior. ## When not to use this skill Do not use this skill for: - General page layout, landing pages, navigation, marketing content, or visual brand work unless the page contains a form or checkout decision. - Backend data modeling, fraud detection, tax, legal, PCI/security implementation, or payment processor integration details beyond UX/frontend implications. - General conversion-copy work outside form context. - Native platform-specific form controls when the user explicitly asks for a platform guideline not covered by the source material. In that case, ask or use the appropriate platform skill/source. ## Core principles 1. **Start outside-in.** Begin with the user's goal and the moment in their journey, not with the database fields the organization wants. 2. **Remove, defer, infer, or default before designing another field.** Every question creates effort and the possibility of error. 3. **Make the path to completion visually obvious.** A form should have a clear scan line from title to first question to final action. 4. **Use controls that match the question.** Prefer native, semantic form controls and visible options when the number of options is small. 5. **Use labels as durable context.** Do not rely on placeholder-only labels for anything longer than a trivial, familiar, one-field interaction. 6. **Validate to help, not to scold.** Validate after a person has finished an answer, prevent avoidable errors, and provide remedies in context. 7. **Design for mistakes.** People will omit steps, choose the wrong action, mistype, misunderstand labels, and miss information under stress. 8. **Do not use color alone.** Errors, success, required/optional status, disabled states, and payment/security cues need text and/or shape in addition to color. 9. **Keep checkout focused.** Remove distractions, avoid forced account creation, show costs and consequences clearly, and keep the primary action aligned with the buyer's goal. 10. **Make progress honest.** Use progress indicators only when the sequence and scope are stable enough that the indicator will not mislead. See [references/principle-cards.md](references/principle-cards.md) for each principle as a reusable card. ## Default recommendations Use these defaults unless the user provides a product-specific constraint or the skill's decision prompts indicate a question is needed. ### Form purpose and scope Default: optimize for successful completion of the user's current goal with the minimum trustworthy data required. Override when: regulatory, security, fraud, identity, eligibility, support, or fulfillment requirements demand additional data. Ask for the requirement and consequence. ### Question set Default: remove nonessential questions; postpone optional or marketing questions until after the core submission; infer answers from known context when confidence is high. Override when: optional answers are critical to personalization, eligibility, pricing, compliance, or operational routing. ### Structure Default: use a single page for short forms with a few coherent topics; use multiple pages or one-thing-per-page for long forms, branching flows, mobile-first flows, or high-focus tasks. Override when: users need to review many related answers together, compare choices, or complete a dense expert workflow. ### Labels Default: use visible, concise, natural-language labels above fields. Top labels usually minimize completion time, handle localization better, and work well on mobile. Override when: a dense desktop form has severe vertical constraints, or when a complex settings form needs label scanning more than speed. ### Required and optional fields Default: avoid optional fields. When most fields are required, mark the few optional fields with text such as "Optional." When most fields are optional, mark the few required fields with text such as "Required." Do not mark every field required. Override when: organizational standards require asterisks; still provide a legend and associate the indicator with the label. ### Input controls Default: use native controls and semantic HTML. Use radio buttons for one choice among a small set, checkboxes for yes/no or multiple choices, text inputs for free-form answers, and select/combobox patterns only when they reduce effort for long option sets. Override when: the design system has tested accessible custom controls that preserve keyboard, screen reader, focus, and error behavior. ### Select boxes Default: use select boxes as a last resort. Prefer visible radio options for a short list, autocomplete/combobox for long searchable lists, or sensible defaults when the likely answer is known. Override when: platform conventions or limited space make a select control the simplest accessible solution. ### Input width Default: make field width communicate expected answer length when the answer has a known size, such as postal code or security code. Use consistent practical widths when length does not carry meaning. Override when: responsive constraints, localization, or auto-formatting make exact width misleading. ### Help text Default: provide short, adjacent help only for unfamiliar data, privacy/security concerns, unusual formats, sensitive questions, optional/required exceptions, or recommended answer formats. Override when: expert, repeated-use, or complex workflows require a persistent contextual help panel. ### Validation Default: validate after the user finishes a field, usually on blur or after selection, not while they are still typing. Use inline validation for fields with high error rates, strict formats, uniqueness checks, limits, or large valid answer sets. Override when: a live counter or meter directly supports answer construction, such as character limits or password strength; make the feedback nonblocking while typing. ### Error messages Default: provide a top-level error summary for long forms or multiple errors and inline field-level remedies for each problematic field. Mark error fields with text plus visual emphasis, not color alone. Override when: a very short form has only one obvious error and the inline message is in view. ### Submit button and submission state Default: keep the primary action visible and enabled; when clicked, clearly show processing and prevent duplicate submission. Avoid hiding or disabling the submit button before submission unless the reason is communicated and the next fix is obvious. Override when: a destructive, irreversible, or legally sensitive action requires explicit prerequisites; explain what is missing and move focus to the first blocker. ### Checkout Default: support guest checkout or account-after-purchase, keep order summary and total visible, minimize offramps, ask for delivery/payment information in a sensible order, and postpone account/profile questions. Override when: the product cannot fulfill the transaction without an account, identity verification, eligibility, or saved relationship. ### Progress indicators Default: omit progress bars for short, uncertain, or dynamically branching forms. Show scope, position, and save/status only for stable multi-step flows. Override when: long forms need reassurance but steps are dynamic; use general progress language such as "Almost done" or section completion rather than precise step counts. ### Accessibility level Default: design to WCAG-style expectations: semantic controls, visible labels, keyboard access, meaningful focus, sufficient contrast, text alternatives, no color-only cues, scalable text, and error messaging announced to assistive technology. Override: do not lower accessibility. For high-risk domains, ask whether additional accessibility, testing, or legal conformance is required. ### Frontend implementation Default: use semantic HTML first; style the native controls when possible; prefer design-system components that preserve native semantics; build form state around field value, touched/dirty status, validation status, submission status, and server error status. Override when: a custom interaction is necessary; require keyboard, focus, screen reader, and mobile input behavior before recommending it. ## Required user questions Ask a focused question only when the answer changes the recommended form design. Do not ask routine best-practice questions. Ask when any of the following are unknown and materially affect the work: - The form's business/user goal is ambiguous. - The flow involves checkout, payment, identity, legal consent, healthcare, finance, government, minors, accessibility compliance, or irreversible consequences. - The form has many fields and it is unclear which are required, optional, inferable, or deferrable. - The audience, locale, language, device mix, or assistive technology needs are likely to change label length, input formats, keyboard behavior, or trust messaging. - A tradeoff exists between one-page versus multi-page, speed versus careful review, visible options versus compact controls, or guest checkout versus account creation. - Existing analytics/research are needed to diagnose drop-off, error rates, or conversion problems. Use the question-tool-ready prompts in [references/decision-prompts.md](references/decision-prompts.md). ## Workflow for critiquing existing forms Inspect in this order: 1. **Goal fit:** What is the user trying to accomplish, and does the form delay or block it unnecessarily? 2. **Question necessity:** Which fields can be removed, inferred, defaulted, made optional, or postponed? 3. **Flow and sequence:** Does the order match how people think about the task? Are sensitive or high-effort questions delayed until trust/context exists? 4. **Structure and grouping:** Are related questions grouped with the least visual noise necessary? Is branching handled without disorientation? 5. **Scan line and layout:** Can a person move steadily from label to input to action without zigzagging, jumping columns, or missing important information? 6. **Labels and controls:** Are labels visible, succinct, durable, and associated with the right semantic controls? 7. **Help and microcopy:** Is help contextual and minimal? Does it explain only what design cannot make obvious? 8. **Validation and errors:** Are errors prevented where possible, shown at the right time, and written as actionable remedies? 9. **Submission and success:** Is the primary action clear? Are loading, duplicate-submit prevention, success, and next steps handled? 10. **Accessibility and implementation:** Does the form work by keyboard, screen reader, touch, mobile keyboard, zoom, and without color-only cues? 11. **Measurement:** Recommend testing or analytics for completion rate, drop-off, error locations, time to complete, support contacts, and qualitative frustration. When presenting critique, group findings by severity: blockers, high-friction issues, accessibility issues, conversion opportunities, polish. ## Workflow for creating or improving a form 1. **Clarify the task.** Identify the user's goal, business goal, required output, audience, device mix, and constraints. 2. **Define the minimum successful submission.** List fields as required, optional, inferable, defaultable, and deferrable. 3. **Choose the flow shape.** Single page, multi-step, one-question-per-page, progressive disclosure, or gradual engagement. 4. **Order the questions.** Start with low-friction/context-setting questions; delay account, sensitive, legal, or high-effort questions until they are justified. 5. **Group fields by user topic.** Use headings, whitespace, fieldsets, and legends; avoid decorative dividers that add visual noise. 6. **Select controls and labels.** Choose the simplest native control that matches the question; use visible labels and expected input attributes. 7. **Add defaults and help.** Default only when likely correct; keep help adjacent, brief, and specific. 8. **Design validation and errors.** Prevent errors, validate at humane timing, summarize when needed, and provide field-level remedies. 9. **Design submission states.** Make primary, secondary, loading, duplicate-submit prevention, success, and next steps explicit. 10. **Check accessibility and frontend feasibility.** Verify semantic HTML, focus, keyboard order, ARIA where needed, responsive behavior, and design-system fit. 11. **Explain tradeoffs.** State the chosen default, why it is appropriate, and what would change under different constraints. ## Decision framework Use this order of preference before adding complexity: 1. **Remove** the question. 2. **Infer** the answer from known context or system data. 3. **Default** the answer when the default aligns with most users' goals and is easy to change. 4. **Defer** the question until after the core task or until the answer becomes relevant. 5. **Ask** the question in the simplest possible way. 6. **Explain** why the question is needed when people may wonder, worry, or lack context. 7. **Validate** at the least disruptive time. 8. **Recover** gracefully when the answer is missing, wrong, or rejected by the server. ## Practical rules ### Structure and flow - Name the form with a title that matches the user's expected task, not the internal database object. - For checkout, avoid sign-in walls. Let people proceed as guests or create an account after purchase whenever feasible. - Break long forms into meaningful topics; do not split a short form into many pages just to simulate engagement. - Use one thing per page when focus, branching, mobile ergonomics, or comprehension matter more than visible overview. - Use progress indicators only when they honestly communicate scope, current position, and status. - Provide save/resume for long, high-effort forms. ### Labels and questions - Write labels as short, concrete questions or noun phrases in the user's language. - Use consistent capitalization. Avoid all caps except for narrow warning contexts. - Keep labels visible after the user types. Placeholder text can supplement, not replace, labels. - Do not mix label alignments within the same form. - Prefer top-aligned labels for familiar data and mobile-first work. - Prefer left-aligned labels only when scanning unfamiliar or many optional fields matters more than speed. ### Grouping and visual hierarchy - Use proximity and whitespace before lines, panels, or alternating backgrounds. - Use fieldsets and legends for groups of radio buttons, checkboxes, and related controls. - Give the primary action a clear visual relationship to the fields it submits. - Avoid two-column layouts unless tab order, responsive collapse, and scanning remain obvious. ### Controls - Use radio buttons when one option among a small set must be selected and all options should be visible. - Use checkboxes for independent choices or a single yes/no consent/option. - Avoid select boxes for small option sets; they hide choices and add interaction cost. - For long lists, consider autocomplete/combobox with accessible keyboard behavior and clear valid suggestions. - Make option labels clickable; ensure the input and its label share the same activation target. - Use mobile-appropriate input types and attributes: `email`, `tel`, `url`, `number` only when numeric behavior is truly appropriate, `autocomplete`, `inputmode`, `autocapitalize`, `spellcheck`, and `aria-describedby` as needed. ### Required, optional, and deferrable inputs - Remove optional fields unless they serve a clear user or business purpose. - Mark the minority case: optional when most are required, required when most are optional. - Use text over symbols for clarity. If using an asterisk, provide a legend and accessible label. - Ask for promo codes, account creation, marketing preferences, and profile enrichment only when contextually useful; otherwise defer. ### Defaults and personalization - Use defaults to reduce work only when the default is likely correct, reversible, and aligned with user interests. - Do not default to hidden costs, marketing opt-ins, premium plans, or risky permissions. - Personalize defaults for returning users when the information is likely stable and easy to change. - Be careful with country, delivery, and payment defaults: wrong defaults can cause costly errors. ### Help text - Use help for unfamiliar terms, sensitive data, privacy/security reassurance, unusual formatting, answer limits, or why a field is needed. - Place help adjacent to the relevant label/input or in a consistent help area for complex repeated-use forms. - Avoid long instruction blocks before the form; people often jump directly into fields. - Do not use help text to compensate for bad labels, wrong controls, arbitrary formats, or unnecessary questions. ### Validation, errors, and success - Accept flexible human input where possible, such as varied phone/credit card spacing, then normalize after entry. - Validate uniqueness, availability, strict formats, and limits at the point they are useful. - Do not show errors while the user is still typing a normal answer. - Explain the problem, the location, and the remedy. - On long forms, provide an error summary and link/focus to each field error. - Use text, icon/shape, and styling for errors; reserve red/warning icons for errors so they retain meaning. - After successful submission, confirm what happened and provide the next logical action. Avoid dead-end success screens. ### Checkout-specific rules - Keep checkout visually calmer than browsing. Remove unrelated navigation, offers, and links that lead away from completion. - Preserve cart context: item count, editable order summary, shipping/billing/payment totals, taxes/fees when known, and delivery expectations. - Ask questions in a sequence people expect: contact/email, delivery/location, delivery method, payment, review/confirm. Adjust when the product context requires another order. - Defer account creation, password, preferences, and marketing until after purchase whenever possible. - Make payment/security reassurance specific and verifiable, not generic decoration. - Keep promo-code entry available but visually secondary unless discounts are central to the business model. - Ensure the final action communicates consequence: place order, pay, subscribe, submit application, save changes. ## Accessibility and inclusion requirements Always check: - Every field has an accessible name, preferably a visible `