フォームデザインシステム

フォームデザインシステム は何をしますか？

目的

フォームデザインシステムスキルは、ウェブフォームの視覚的・空間的フレームワークを設計するための方法論を提供します。技術的な実装が「どのように」を扱い、成長最適化が「なぜ」を扱うのに対し、デザインシステムは「何を」「どこに」を定義します。ラベル、入力フィールド、選択肢、アクションといったフォーム要素を、予測可能でアクセシブルかつ信頼性の高いインターフェースに整理し、認知的負荷を軽減してユーザーエラーを防止します。

ユースケース

• フォーム用のUIキットまたはデザインシステムコンポーネントライブラリの設計
• 複雑な多段階データ入力インターフェースの視覚的基準の確立
• 既存フォームの視覚的不整合や空間的な摩擦の監査
• デバイス間で階層を維持するレスポンシブフォームレイアウトの設計
• エラーおよびバリデーションの視覚表現パターンの標準化

使用すべきでない場合

• 汎用検索バー: シンプルな単一入力の検索フィールドに完全なデザインシステム処理は通常不要です。
• 実験的なインタラクティブメディア: フォーム風のインタラクションが物語やアート体験の副次的なものである場合。
• 低リスクのマイクロインタラクション: 「いいね/よくない」の評価や、データ入力のないシンプルなトグルなど。

入力

1. 情報アナトミー: 収集する具体的なデータポイントとその関係性。
2. デバイスブレークポイント: responsive-grid-system からのレスポンシブ要件。
3. ブランドスタイル: fluid-spacing-system からのタイポグラフィスケール、カラーパレット、スペーシングトークン。
4. インタラクション要件: フォームがリアルタイムバリデーション、ファイルアップロード、複雑な選択を必要とするかどうか。

出力

1. 入力アナトミー仕様: ラベル、入力フィールド、ヘルプテキスト、アイコン、エラーメッセージの視覚的定義。
2. レイアウト設計図: フィールドのグループ化、配置（トップ vs レフト）、アクション配置に関する空間ルール。
3. 選択コンポーネントマップ: ラジオボタン、チェックボックス、スイッチ、セレクトボックスをいつ使用するかの定義。
4. フィードバック・状態マトリックス: ホバー、フォーカス、無効、成功、エラー状態の視覚的処理。

ワークフロー

1. コンポーネントアナトミーの定義

すべての「フィールドグループ」に対して一貫した構造を確立します。フィールドは以下で構成されます:

• ラベル: フィールドを識別する明確で簡潔なテキスト。
• 入力フィールド: インタラクティブなコンテナ（テキスト、セレクトなど）。
• ヘルパー/説明テキスト: 常時表示のガイダンス（例: 「パスワードは8文字以上である必要があります」）。
• エラーメッセージ: バリデーション失敗時にのみ表示されるコンテキストフィードバック。

2. 空間レイアウトと配置の確立

ラベルと入力フィールドの関係を決定します:

• トップアラインラベル（推奨）: スキャン容易性とモバイルレスポンシブに最適。
• 左アラインラベル: デスクトップのデータ量が多いインターフェースで、垂直方向のスペースが重要な場合のみ使用。
• グループ化: グループ間は論理的なスペース（例: --space-l）、グループ内は小さなスペース（例: --space-s）を使用。

3. インタラクションパターンの選択

データタイプにUIパターンを割り当てます:

• 二択: 「はい/いいえ」または複数選択にはチェックボックスを使用。
• 相互排他: 2～5個の選択肢にはラジオボタン、6個以上にはセレクトボックスを使用。
• 即時トグル: 「送信」アクションを伴わずに即座に効果が適用される設定にはスイッチを使用。

4. フィードバックループの設計

バリデーションのための視覚的階層を作成します:

• フォーカス状態: アクティブなフィールドを示すために高コントラストのリングを使用。
• エラー状態: 色（通常は赤）、アイコン、枠線の太さを使用してエラーを通知。
• 成功状態: 高リスクのフィールド（例: ユーザー名の利用可否）には控えめな手がかり（緑のチェックマークなど）を使用。

5. レスポンシブ適応の計画

フォームが小さなビューポートでどのように表示されるかをマッピングします:

• スタッキング: デスクトップのマルチカラムレイアウトはモバイルではシングルカラムにスタックする必要があります。
• タッチターゲット: すべてのインタラクティブゾーン（ラジオ、チェックボックス、ボタン）は少なくとも 24x24px（WCAG 2.2 SC 2.5.8 最小）であることを確保。44x44px が推奨され、主要な送信アクションのデフォルトとすべきです。

意思決定ルール

• シングルカラムルール: ほとんどのフォームでは、明確な垂直スキャンパスを維持し視線の追跡疲労を減らすために、シングルカラムレイアウトを使用します。
• ラベルの配置: デフォルトでトップアラインラベルを使用します。これにより、フォームを処理するために必要な視線の固定回数が減少します。
• プレースホルダー vs ラベル: プレースホルダーをラベルの代わりに使用しないでください。ラベルはユーザーが入力を開始した後も表示されたままである必要があります。
• ボタン階層: 主要な「送信」アクションが最も視覚的に目立つようにします。二次的なアクション（例: 「キャンセル」）はテキストリンクまたは低コントラストのボタンにします。
• 近接性: ヘルパーテキストとエラーメッセージは、できるだけ入力フィールドの近く（通常はすぐ下）に配置します。

制約

• アクセシビリティ: ラベルはプログラムで入力フィールドにリンクする必要があります（<label for> またはラッピング）。テキストと枠線のコントラスト比はWCAG AA（テキスト 4.5:1、UIコンポーネント 3:1）を満たす必要があります。エラーメッセージは aria-describedby を使用してプログラムで入力フィールドに関連付け、無効なフィールドは aria-invalid="true" を設定する必要があります。フォーカスインジケーターは、スティッキーヘッダー、トースト、オーバーレイの背後に隠れてはいけません（WCAG 2.4.11 フォーカスが隠れない）。
• レスポンシブ性: フォームフィールドがコンテナからはみ出したり、モバイルビューポートを超える固定幅を持ったりしてはいけません。
• 視覚的階層: エラーメッセージは、見逃されないようにヘルパーテキストと視覚的に明確に区別する必要があります。

よくある失敗パターン

• 「プレースホルダーラベル」の罠: ラベルの代わりにプレースホルダーを使用し、ユーザーが入力を始めるとコンテキストが失われる。
• 過剰なカラム: ユーザーの自然な上から下へのスキャン経路を混乱させるマルチカラムレイアウト。
• 曖昧なエラー: アイコンやテキストメッセージなしに、色だけでエラーを視覚化する（例: 枠線を赤くするだけ）。
• 小さなタッチターゲット: モバイルでの親指操作には小さすぎるラジオボタンやチェックボックス。
• 「見えない」フォーカス: 明確なフォーカスリングを提供せず、キーボードユーザーのナビゲーションを不可能にする。

検証基準

• すべての入力フィールドに永続的で表示可能なラベルがある。
• フォームが論理的なシングルカラムの垂直スキャンパスに従っている。
• エラー状態が色、アイコン、テキストの組み合わせを使用している。
• フォーカスインジケーターが高コントラストで明確に表示されている。
• インタラクティブ要素（入力フィールド、ボタン）がWCAG 2.2の24x24pxタッチターゲット最小値を満たしている（44x44px推奨）。
• レイアウトがモバイルビューポートでシングルカラムにグレースフルに移行する。
• プライマリ、セカンダリ、ターシャリアクションに明確な視覚的階層がある。