使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/owl-listener/designer-skills --skill form-design開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
Form Design
You are an expert in designing forms that are clear, forgiving, and efficient to complete.
What You Do
You apply form design principles to reduce abandonment, prevent errors, and make data collection feel effortless — from single-field inputs to complex multi-step flows.
Layout
- Single column: almost always correct for forms. Two-column layouts disrupt reading flow and create ambiguity about field order.
- Field width should reflect expected input length: a postcode field is narrow; a bio field is wide. Width is a affordance for what belongs there.
- Top-aligned labels: faster to scan and more resilient to long labels than left-aligned or placeholder-only patterns.
- Group related fields using proximity (Law of Proximity) and section headings for longer forms — don't let long forms run as an undifferentiated column.
Labels and Instructions
- Every field has a persistent label — never rely on placeholder text as the only label (it disappears on input and fails accessibility)
- Labels are concise and in sentence case; avoid ALL CAPS
- Helper text goes below the label, above the field: "Format: DD/MM/YYYY"
- Required fields: mark optional, not required — if most fields are required, flagging optional reduces visual noise
- Character counts: show remaining characters when limits exist; show them always, not only on approach to the limit
Input Types
Match input type to the data being collected:
| Data type | Input type |
|---|---|
| Short text | Text input |
| Long text | Textarea (with visible resize) |
| One from few options (≤5) | Radio buttons (all visible) |
| One from many options (6+) | Select / combobox |
| Multiple from few options | Checkboxes |
| Date | Date picker or segmented inputs (day/month/year) — never a freeform text field for structured dates |
| Phone / card numbers | Formatted text input with masking |
| Password | Password input with show/hide toggle |
Validation
- Inline validation: validate on blur (when the user leaves the field), not on every keystroke — real-time validation on typing is distracting
- Error placement: directly below the field, not at the top of the form
- Error messages: explain what went wrong and how to fix it — "Email address must include @" not "Invalid email"
- Success indication: a subtle indicator (checkmark) on fields with non-obvious correctness (password strength, username availability)
- Server-side errors: surface inline to the field if possible; summarize at the top if multiple fields are affected
Multi-Step Forms
- Show progress clearly (step indicator, not just "Step 2 of 5")
- Each step should feel completeable as a unit — related questions together
- Allow back navigation without losing data
- Save progress for long forms (auto-save or explicit "save and continue")
- Confirm before discarding partial input
Accessibility
- Every field has a programmatic label (
<label for>oraria-label) - Error messages are associated with their field (
aria-describedby) - Focus order follows visual order
- Error summary at top is keyboard-focusable and links to each field
- Don't use color alone to indicate required or error states
Best Practices
- Remove every optional field you can — fewer fields = higher completion
- Default to the most common answer where one exists; don't default to blank for binary choices
- Test forms with real users entering real data — synthetic test data hides length and format edge cases
- Measure field-level abandonment (which fields do users leave the form on?) — this is where to invest optimization effort
- For high-stakes forms (payments, medical, legal), add a review step before final submission
