forms

ユーザーが混乱や不安を感じたり、途中で諦めたりすることなく入力できるフォームを作成します。目的は、考え得るすべての項目を集めることではありません。ユーザーが目標を達成するまでにある、不要な障害をすべて取り除くことです。

検証のタイミング、エラーの配置、複数フィールド間の依存関係、非同期検証、リカバリー設計、コンバージョン測定、フィールドごとの離脱、フィールドごとの最適化については、フォームの検証パターンのリファレンスを参照してください。 フォーカスを外したときとリアルタイムのどちらで検証するか、早期に報酬を与え遅れて罰する動作、コピー＆ペーストしやすい検証については、ライブ検証のUXのリファレンスを参照してください。 検証または送信に失敗した後の動作については、エラーからのリカバリーのリファレンスを参照してください。 送信ボタンを無効にするか、エラーの説明を添えて有効なままにするかを判断する際は、無効化されたボタンのUXのリファレンスを参照してください。 ボタン、入力欄、チェックボックス、ラジオボタン、トグル、ドロップダウン、テキストエリアの構成要素に関するガイダンスについては、コンポーネントの構成のリファレンスを参照してください。 フォームが補足テキスト、説明、オンボーディングに頼りすぎている場合は、ひと目でわかるインターフェース設計のリファレンスを参照してください。より明確なグループ分け、デフォルト値、制約、入力例、インラインフィードバックを優先してください。

必須の準備

frontend-designを読み、そのコンテキスト収集プロトコルに従ってください。利用可能なコンテキストを活用し、重要な情報が不足している場合に限って質問してください。加えて、ユーザーが達成しようとしている目標、本当に必須のフィールド、現在のフローで離脱が発生する原因を確認してください。

フォームのニーズを評価する

フォームの目的と利用状況を把握します。

1. ユーザーの目標：このフォームを入力すると、ユーザーは何を得られますか？得られるものが明確であるほど、完了率は高くなります。
2. フィールドの必要性：フィールドを追加するたびに完了率は下がります。各フィールドについて、本当に今必要なのか、それとも後で収集できるのかを検討してください。
3. 利用状況：ユーザーは急いでいる、気が散っている、表示領域が狭い、または粗いポインターを使っている状況でしょうか？ストレスの多い状況では、フォームをよりシンプルにする必要があります。
4. 離脱の原因：現在、ユーザーはどこで離脱していますか？フォームが長い、ラベルがわかりにくい、予期しない検証が行われるといったことが、よくある原因です。
5. データの用途：送信後に実際に使われるフィールドはどれですか？営業、サポート、オンボーディングで使われないフィールドは、削除するか、値を推測するか、後で収集してください。
6. 測定：分析では、フォームの表示、最初のフィールドへのフォーカス、フィールドの入力完了、検証エラー、送信の試行、送信の成功、モバイルとデスクトップでの完了率を確認できますか？

フォームの構成

フィールドの順序

• 簡単な質問から始めて、入力の勢いをつけます
• 関連するフィールドを視覚的にまとめます（氏名のフィールド同士、住所のフィールド同士など）
• 任意項目は最後に配置するか、任意であることが明確にわかるようにします
• 請求先と配送先は、実際に異なる場合にのみ分けます

ラベルの設計

• 入力欄の上に、明確で見つけやすいラベルを配置します（プレースホルダーテキストとして入力欄の中に表示しないでください）
• タイトルケースより文頭のみ大文字にする形式のほうが読みやすくなります
• 「お支払い情報」ではなく「カード番号」のように、具体的にします
• 補足テキストでは、ラベルを繰り返すのではなく、入力形式の要件を説明します
• 補足テキストを追加する前に、入力タイプ、幅、プレースホルダーの例、接頭辞／接尾辞、デフォルト値、グループ分けによって、フィールドをひと目でわかるようにできないか検討します

入力項目の設計

• 想定される内容に合わせて入力欄の幅を設定します（郵便番号の入力欄を全幅にしないなど）。
• ブラウザーのキーボード、オートフィル、入力検証のヒントを活用できるよう、適切な入力タイプ（type="email"、type="tel"、type="date"）を使用します。
• ユーザーの入力に合わせて書式のヒントを表示します（クレジットカード番号のスペース、電話番号のグループ分けなど）。
• オートフィルに対応できるよう、標準的な name 属性と autocomplete 属性を使用します。
• フィールドごとに適切な使いやすさを実現します。メールアドレスの入力ミス候補、電話番号の国コード処理、選択肢が多い場合の検索可能なセレクト、選択肢が5つ未満の場合のラジオボタン、長文メッセージ用の拡張可能なテキストエリアなどを使います。
• カスタム入力欄の背景が暗い、半透明、またはブランド色が強い場合は、ブラウザーのオートフィル表示を調整します。まず通常のフィールド状態に Tailwind ユーティリティを使い、次に Tailwind では表現しにくいブラウザーの疑似クラス用に小さな CSS レイヤーを追加します。

@import "tailwindcss";

@layer components {
  .input:-webkit-autofill,
  .input:-webkit-autofill:hover,
  .input:-webkit-autofill:focus,
  .input:-webkit-autofill:active {
    border-color: color-mix(in oklab, white 40%, transparent);
    caret-color: var(--color-white);
    -webkit-text-fill-color: var(--color-white);
    -webkit-box-shadow: 0 0 0 1000px color-mix(in oklab, white 20%, transparent) inset;
    transition: background-color 5000s ease-in-out 0s;
  }

  .input:autofill {
    border-color: color-mix(in oklab, white 40%, transparent);
    caret-color: var(--color-white);
  }
}

:-webkit-autofill は Chromium と Safari を対象とします。:autofill は、対応ブラウザーで使用する標準準拠のセレクターです。両方を使い、hover、focus、active の各状態も含めます。静的なスクリーンショットを信頼せず、保存済みのパスワードや住所を使った実際の入力フローをテストしてください。

マルチステップフォーム

次のような場合は、長いフォームを複数のステップに分けます。

• フィールドが6〜8個を超える
• フォームが異なるトピック（アカウント情報、支払い、確認）を扱う
• 最終送信の前にユーザーが内容を確認する必要がある

ステップの設計：

• ユーザーが残りのステップを把握できるよう、進捗状況（「ステップ2/4」など）を表示します。
• 前のステップに戻れるようにします。
• ユーザーがページを離れて戻ってきても、入力済みのデータを保持します。
• 次のステップに進む前に各ステップを検証します。ただし、前のステップに戻る操作は妨げないでください。

コンバージョン重視のフォーム

見込み客の獲得、デモの申し込み、見積もりの依頼、応募、または購入手続きの意思を捉えるフォームでは、次の点に注意します。

• フォームのすぐ上または横に、価値提案を記載します。
• 送信後の流れを、関連する場合は応答時間も含めて明記します。
• 機密性の高い項目より先に、メールアドレスや名前など、入力の負担が少ない項目から始めます。
• 電話番号、会社の規模、予算、詳細な要件は、フォローアップの質を実質的に高める場合に限って尋ねます。
• 再訪ユーザーには、最初からすべてを尋ねるのではなく、段階的なプロフィール取得を行います。
• 機密性の高い項目の近くにプライバシー保護について記載します。フッターに埋もれさせないでください。
• チャット、メール、電話、カレンダー予約など、申し込み意欲の高いユーザー向けに別の連絡手段も用意します。

入力検証の方針

タイミング

• 入力が完了したことが明確な項目（メールアドレス、電話番号、書式の指定がある項目）は、フォーカスが外れたときに検証します。
• 入力中の検証は、パスワードの強度や文字数など、すぐにフィードバックすることが役立つ場合に限ります。
• その他の項目は送信時に検証します。特に、項目間の依存関係がある場合は送信時に検証します。
• まだ入力されていない項目は決して検証しないでください。不安を招きます。

エラーの設計

• エラーメッセージはフィールドのすぐ下に表示します。
• 問題の内容と修正方法を説明します。
• スクリーンリーダーとの関連付けに aria-invalid と aria-describedby を使用します。
• 入力検証に失敗しても、ユーザーの入力内容をすべて保持します。
• 送信に失敗した後は、最初のエラー項目にフォーカスを移動します。

成功状態

• チェックマークや緑色の枠線を使って、入力が有効であることを控えめに示します。
• ユーザーが項目を再編集したら、成功表示を削除します。
• 有効な項目ごとに強調しないでください。かえってノイズになります。

レスポンシブフォームの UX

• coarse-pointer のタップ対象は、少なくとも44×44pxを確保します。
• キーボードを最適化できるよう、適切な入力タイプを使用します。
• ステップ分割や段階的な表示を使って、スクロールを最小限に抑えます。
• 数値項目ではテンキー、メールアドレス項目ではメール用キーボードを表示します。
• 選択肢が少ないリストではドロップダウンを避け、代わりにラジオボタンやセグメントコントロールを使用します。

アクセシビリティ

• for／id を使って、各入力項目をラベルに関連付けます。
• グループ化された項目には fieldset と legend を使用します。
• フォーム全体のエラーは role="alert" または aria-live="polite" で通知します。
• エラーメッセージがプログラムから各フィールドに関連付けられていることを確認します。
• フォーム全体をキーボードで操作できるかテストします。
• エラーの表示を色だけに頼らないでください。

アンチパターン

• フィールドが多すぎる：フィールドが増えるたびに、入力完了率が低下します
• プレースホルダーをラベルとして使う：ユーザーが入力すると消えてしまい、記憶の助けにもアクセシビリティにも適しません
• 読み込み時に検証する：未入力のフィールドにエラーが表示されると、責められているように感じます
• 曖昧なエラー：「入力が無効です」のように説明がないと、ユーザーは何をすればよいかわかりません
• エラー時にフィールドをクリアする：入力したデータが失われると、非常にストレスを感じます
• 案内のない無効状態の送信ボタン：目に見えるエラーがないままボタンがグレーアウトしていると、行き詰まってしまいます
• 進捗インジケーターのない複数ステップのフォーム：ユーザーは残りの手順がどれだけあるかわかりません
• 一貫性のない検証タイミング：一部はフォーカスが外れたとき、一部は送信時など、明確なロジックがありません
• 入力の意味を考慮しない：電話番号に type="text" を使うと、ブラウザーで最適なキーボードやオートフィルの動作が利用できません
• 保存して再開できない：途中で保存できない長いフォームは、作業の中断を不利益にします

フォームの品質を確認する

リリース前に確認してください。

• すべてのフィールドに必要性があり、任意のフィールドは明確に示されています
• ラベルは明確かつ具体的で、入力欄の上に配置されています
• まだ入力されていないフィールドでは検証が実行されません
• エラーには問題の内容と修正方法が説明されています
• 検証に失敗しても入力内容が保持されます
• 送信に失敗した後、最初のエラーにフォーカスが移動します
• 複数ステップのフォームでは進捗が表示され、前の手順に戻れます
• フィールドの種類ごとに、ブラウザーのキーボード、オートフィル、検証のヒントが最適化されています
• フォーム全体をキーボードで操作できます
• エラーや成功を示す手段が色だけではありません