forms

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

入力規則のタイミング、エラーの配置、複数フィールド間の依存関係、非同期の入力規則、復旧の設計については、フォームの入力規則パターンのリファレンスを参照してください。 ぼかし時とリアルタイムのタイミング、早めに報い遅めに罰する動作、コピー＆ペーストに適した入力規則については、ライブ入力規則の UXのリファレンスを参照してください。 入力規則や送信に失敗した後の動作については、エラーからの復旧のリファレンスを参照してください。 送信ボタンを無効にするか、エラーの説明を表示して有効なままにするかを決める際は、無効化されたボタンの UXのリファレンスを参照してください。 ボタン、入力欄、チェックボックス、ラジオボタン、トグル、ドロップダウン、テキストエリアの構造に関するガイダンスについては、コンポーネントの構造のリファレンスを参照してください。

必須の準備

ユーザーは /forms を使ってこのワークフローを開始します。このスキルが有効になったら、$frontend-design を読み込んでください。デザイン原則、アンチパターン、コンテキスト収集プロトコルが含まれています。作業を進める前に、そのプロトコルに従ってください。デザインコンテキストがまだない場合は、必ず最初に $setup を読み込んでください。さらに、ユーザーが達成しようとしている目標、本当に必須の項目、現在のフローで離脱につながる要因を確認してください。

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

フォームの目的とコンテキストを把握します。

1. ユーザーの目標：このフォームを完了すると、ユーザーは何を得られますか？得られるものが明確であるほど、完了率は高くなります。
2. 項目の必要性：項目を追加するたびに完了率は下がります。各項目について、本当に今必要なのか、それとも後で収集できるのかを検討してください。
3. 利用状況：ユーザーは急いでいたり、気が散っていたり、モバイル端末を使っていたり、ストレスの多い状況にいたりしますか？ストレスの多い状況では、よりシンプルなフォームが必要です。
4. 離脱ポイント：現在、ユーザーはどこで離脱していますか？フォームが長いこと、ラベルがわかりにくいこと、予期しない入力規則がよくある原因です。

フォームの構成

項目の順序

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

ラベルの設計

• 入力欄の上に、明確でひと目でわかるラベルを配置します（プレースホルダーテキストとして入力欄の中に置かないでください）
• Title Case よりも文頭のみを大文字にする表記のほうが読みやすくなります
• 具体的にします。「支払い情報」ではなく「カード番号」とします
• 補助テキストでは、ラベルを繰り返すのではなく、入力形式の要件を説明します

入力欄の設計

• 想定される入力内容に幅を合わせます（郵便番号の入力欄を全幅にしないでください）
• モバイルのキーボードを最適化するため、適切な入力タイプ（type="email"、type="tel"、type="date"）を使用します
• ユーザーの入力に応じて、書式のヒントを表示します（クレジットカード番号のスペース、電話番号の区切りなど）
• 自動入力に対応できるよう、標準の name 属性と autocomplete 属性を使用します

複数ステップのフォーム

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

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

ステップの設計：

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

入力規則の方針

タイミング

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

エラーの設計

• エラーメッセージはフィールドのすぐ下に表示します
• 何が問題だったのか、どうすれば解決できるのかを説明します
• スクリーンリーダーで関連付けるために、aria-invalid と aria-describedby を使用します
• バリデーションに失敗しても、ユーザーが入力した内容をすべて保持します
• 送信に失敗した後は、最初のエラーにフォーカスを移動します

成功状態

• チェックマークまたは緑色の枠線で、入力が有効であることをさりげなく示します
• ユーザーがフィールドを再編集したら、成功の表示を取り除きます
• 有効なフィールドごとに成功を強調しないでください。表示がノイズになります

モバイルフォームの UX

• タッチターゲットを少なくとも 44×44px にします
• キーボードを最適化できる適切な入力タイプを使用します
• 手順に分けるか、段階的開示を使ってスクロールを最小限にします
• 数値フィールドではテンキーを、メールアドレスのフィールドではメール入力用キーボードを表示します
• 選択肢が少ない場合はドロップダウンを避け、ラジオボタンまたはセグメントコントロールを使用します

アクセシビリティ

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

アンチパターン

• フィールドが多すぎる：フィールドが増えるたびに、完了率が下がります
• プレースホルダーをラベルにする：入力を始めると消えるため、記憶のしやすさとアクセシビリティに悪影響を及ぼします
• 読み込み時のバリデーション：入力前のフィールドにエラーが表示されると、責められているように感じます
• 曖昧なエラー：説明のない「無効な入力」では、ユーザーは何をすべきか分かりません
• エラー時にフィールドをクリアする：入力内容を失うのは非常にストレスになります
• 案内なしで送信を無効にする：エラーが見えないままボタンがグレーアウトすると、先に進めません
• 進捗インジケーターのない複数ステップ形式：残りの手順が分かりません
• 一貫性のないバリデーションのタイミング：明確なルールがなく、フィールドによってフォーカスを外したときに検証したり、送信時に検証したりします
• モバイルキーボードを考慮しない：電話番号に type="text" を使うと、ユーザーはキーボードを切り替えなければなりません
• 保存して再開できない：途中で保存できない長いフォームは、中断したユーザーに負担をかけます

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

リリース前に確認します。

• すべてのフィールドに必要性があり、任意のフィールドには任意であることが明確に示されています
• ラベルが分かりやすく具体的で、入力欄の上に配置されています
• 入力前のフィールドではバリデーションが実行されません
• エラーは何が問題だったのか、どうすれば解決できるのかを説明しています
• バリデーションに失敗しても入力内容が保持されます
• 送信に失敗した後、最初のエラーにフォーカスが移動します
• 複数ステップのフォームには進捗状況が表示され、前の手順に戻ることができます
• モバイルキーボードはフィールドの種類ごとに最適化されています
• フォーム全体をキーボードで操作できます
• エラーや成功の表示が色だけに頼っていません