設定インターフェースシステム

設定インターフェースシステム は何をしますか？

目的

設定インターフェースシステムは、ユーザー設定、アカウント設定、ワークスペース設定、請求ポータルを整理、設計、構造化するための方法論を提供します。設定画面はしばしば軽視され、断片的なビジュアル構造、分断されたナビゲーションモデル、貧弱なレスポンシブ対応、深刻なアクセシビリティ障壁を生み出します。このシステムは、空間構成、ナビゲーションアーキテクチャ、状態永続化モデル（例：自動保存 vs. 手動バッチ保存）、および視覚的アフォーダンスに対する標準化されたアプローチを確立し、認知的負荷を軽減し、未保存データの損失を防ぎます。

ユースケース

• ユーザープロフィールとアカウント: 個人情報、セキュリティ認証情報、設定を更新するためのインターフェース設計。
• SaaSワークスペース管理: マルチテナントまたはチーム設定、メンバーロール、統合、権限ゲートの整理。
• 通知設定センター: メール、プッシュ、アプリ内アラート用の、粒度の高いマトリクスベースのトグルボードの作成。
• 請求・サブスクリプションハブ: 価格帯、現在のプラン指標、支払い方法、過去の請求書リストを明確に表示する設計。
• 開発者設定: APIキーのローテーション、ウェブフック、環境トグルなどの複雑な技術オプションの整理。

使用すべきでない場合

• 暗黙の同意とプライバシーバー: Cookieの受け入れ、Cookieの分類、コンプライアンスオーバーレイには、consent-and-preference-system を使用してください。
• 単発のオンボーディングフォーム: シンプルな単一列のサインアップ手順や初期調査のキャプチャには、form-design-system を使用してください。
• 低複雑度のインターフェース（設定項目が5つ未満）: 非常にシンプルな設定の場合は、ネストされたマルチページシステムを構築せず、これらのオプションをグローバルヘッダーのプロフィールドロップダウンやサイドバーフッターに直接統合してください。

入力

1. 設定インベントリ: すべての設定可能な属性を論理的にグループ化した包括的なカタログ。
2. 状態永続化モデル: 変更が即座に適用されるか（自動保存）、確認まで保持されるか（手動バッチ保存）の決定。
3. ユーザーアクセスロール: 特定の行を表示/変更できるユーザーに関する情報（例：管理者、請求編集者、閲覧者）。
4. スペーシングとタイポグラフィトークン: 既存のデザイン値（fluid-spacing-system および fluid-typography-system から）。

出力

1. 設定ナビゲーションモデル: セクション密度に基づくナビゲーションレイアウト（サイドバー、サブタブ、アコーディオン）の選択。
2. マスター・ディテールレイアウト仕様: サイドバーコントロールを対応するアクティブな設定ペインにマッピングするグリッド/フレックス構成。
3. 状態永続化と変更ログUI: 保存確認、ローディング状態、未保存変更バナーに関する視覚的および聴覚的パターン。
4. アクセシブルなフィールドと権限注釈: キーボードパス、セマンティックレジェンドタグ、明確な無効/読み取り専用スタイルルール。

ワークフロー

1. 設定のグループ化と優先順位付け（クラスタリング）

設定インベントリに対してカードソーティングまたはテーマ別グループ化を実行します:

• 個人階層: プロフィール情報、アバター、ログイン詳細、個人セキュリティ（MFA）。
• 組織/ワークスペース階層: ワークスペース名、メンバー招待、ロール、グローバル統合。
• 配信/システム階層: 通知ルール、サウンドアラート、テーマオプション（ダーク/ライトモード）。
• 財務階層: プラン階層、クレジットカード、請求先連絡先、請求書テーブル。
• 危険ゾーン: アカウント削除、ワークスペース非アクティブ化、所有権移転。

2. レイアウトとナビゲーションアーキテクチャの選択

空間ナビゲーションパターンを選択します:

• サイドバー駆動（マスター・ディテール）: B2B SaaSや密度の高い設定に推奨。永続的な左ナビゲーションカラム（マスター）とスクロール可能な右側コンテンツペイン（ディテール）を使用します。
• タブ駆動: 軽量から中程度の設定パネル（5ビュー未満）に最適。メイン設定ページヘッダーの下に水平なセカンダリタブメニュー（tab-ui-system または segmented-control-system を使用）を配置します。
• 単一ページスクロール（アコーディオン）: シンプルなモバイルアプリや、垂直方向の高さを管理しやすくするためにサブセクションをインラインで展開/折りたたみできる設定リストに最適。

3. 保存とフィードバックモデルの確立

各設定カードに対して明確な状態永続化メカニズムを選択します:

• 自動保存パターン:
  • リスクの低い単独オプション（ダークモードの切り替え、通知設定）に使用。
  • フィードバック: トグルの横にインラインのスピナー/ローダーと明確な「保存済み」テキストインジケーターを表示。インジケーターは1〜2秒の非アクティブ後にフェードアウトします。
• バッチ保存パターン（未保存状態）:
  • リスクの高いフォームや強く関連するフィールド（パスワード更新、請求先住所）に使用。
  • フィードバック: 「未保存の変更があります」と示す、固定位置のヘッダーまたはフッターバナーを表示。
  • アクション: 「変更を保存」（プライマリCTA）と「破棄」（セカンダリスタイルテキスト）の2つの目立つボタンを提供。未保存状態のときはサイドバー/タブナビゲーションを無効にするか、ユーザーがクリックして移動しようとした場合に「未保存の変更を破棄しますか？」確認モーダルをトリガーします。

4. 高密度設定マトリックスの設計

通知センターや粒度の高い権限テーブルの場合:

• マトリックスグリッドを使用: チェックボックスまたはスイッチを、配信チャネル（例：メール、アプリ内、SMS）に対応する列と、イベント（例：「コメントでメンションされた」、「タスクが割り当てられた」）に対応する行に整列します。
• 列ヘッダーの固定: 垂直スクロール時にラベルを固定してコンテキストを保持します。
• キーボード対応の行ハイライト: interactive-state-system スタイルを使用して、セルにフォーカスすると対応する行がハイライトされるようにします。

5. 「危険ゾーン」カードの構造化

元に戻せない破壊的なアクションには、専用の視覚的処理が必要です:

• 視覚的分離: アクション（ワークスペースの非アクティブ化、アカウント削除）をレイアウトの最下部にある単一のカードにグループ化。
• 高コントラスト危険アラート: 赤い境界線、薄い赤の警告背景、結果を詳述した太字の警告を使用。
• 二重確認モーダル: 破壊を即座にトリガーしないでください。アクションボタンをクリックすると、モーダル（overlay-and-dialog-system）が開き、確認のためにリソース名（例：「ワークスペース名を削除」）を明示的に入力する必要があります。

6. モバイルレスポンシブ対応の設計

• 線形マスター優先に折りたたむ: ビューポートが 768px 未満の場合、サイドバーリストとコンテンツ詳細ペインを線形マスターリストに折りたたみます。
• サブページナビゲーション: モバイルでサイドバーオプションをクリックすると、その詳細セクションのみを含む全幅のスライディングパネルが開き、固定された「設定に戻る」パンくずヘッダーが表示されます。
• タッチターゲットの拡大: チェックボックス、スイッチ、閉じるターゲットを最低 44px x 44px に拡大し、親指によるモバイル操作に対応します。

決定ルール

• 自動保存 vs. 手動保存: トグル/入力が即時のユーザー設定（ダークテーマやアラート音など）として機能する場合は 自動保存 を使用します。フィールドが論理的にグループ化され、検証に依存する場合（メール/パスワード変更、請求情報など）は 手動バッチ保存 を使用して、不完全または無効なデータベース更新を防ぎます。
• サイドバーの閾値: 5つ以上の異なるセクションを含む設定スイートには、永続的な垂直サイドバーナビゲーションを使用します。セクションが4つ以下の場合は、プライマリヘッダーの下に水平なセカンダリタブバーを使用します。
• 未保存変更の破棄: ユーザーが手動保存ビューで入力を変更し、保存せずにタブ/ナビゲーション項目をクリックした場合、常にナビゲーションをブロックし、確認ダイアログをトリガーします：「未保存の変更を破棄しますか？」

制約

• アクセシビリティ（セマンティック構造）:
  • フィールドを <fieldset> と <legend> タグでグループ化し、支援技術がネストされたコントロールのコンテキストを読み取れるようにします。
  • フォームコントロールは、プログラム的に関連付けられたラベル（<label for="...">）または aria-labelledby を使用する必要があります。
  • インラインの自動保存インジケーターには aria-live="polite" を使用し、スクリーンリーダーがタイピングフォーカスを妨げずにバックグラウンド保存を通知できるようにします。
  • アクティブフォーカスインジケーターは、少なくとも 3:1 のコントラスト比を満たし、スティッキーヘッダーや未保存変更バナーによって隠されてはなりません（WCAG 2.2 SC 2.4.11）。
• レスポンシブ対応: マルチカラムグリッドテーブルは、小さなビューポートではクリーンな行に積み重なるか、水平スクロールテーブルになる必要があります。テキスト要素は word-break: break-word を使用して、長いAPIキーやウェブフックURLがオーバーフローしないようにします。
• 視覚階層: 関連する設定を視覚的に分離された「カード」にグループ化し、標準のマージンスペーシング（--space-l）を使用して、単一の無限リストと比較して認知的負荷を軽減します。

よくある失敗パターン

• 「サイレント保存失敗」: 自動保存トグルがエラー状態を表示せずにバックグラウンドで失敗し、ユーザーが変更が記録されたと誤認するパターン。
• 「偶発的な損失」: 入力途中の設定ページから移動すると、確認モーダルを表示したり状態を保持したりせずにすべての変更が失われるパターン。
• 「謎の設定グリッド」: 永続的な列ヘッダーや行ヘッダーなしに大きな多次元マトリックス（通知など）を作成し、ユーザーが画面上で指を頼りに項目を揃えざるを得なくなるパターン。
• 危険ゾーンモーダルでの貧弱なフォーカストラップ: キーボードフォーカスが確認削除モーダルからバックグラウンドページに逃げ、ユーザーが削除確認を入力しようとしている間に誤ってバックグラウンド設定を送信できるようにするパターン。
• プレースホルダーラベリング: 実際の永続的な <label> タグの代わりに入力プレースホルダーテキストを使用するパターン。入力を開始するとコンテキストが失われます。

検証基準

• 5つ以上の設定ビューには永続的な垂直サイドバーナビゲーションが使用され、モバイル画面サイズではスライディングサブビューナビゲーションに適切に折りたたまれている。
• リスクの低い設定トグルは、インラインの aria-live 保存ステータスローダーとともに自動保存パターンを使用している。
• 重要なマルチフィールドフォームは、永続的な「未保存の変更」フローティング/固定バナーとともに手動バッチ保存パターンを使用している。
• 破壊的なアクションは、視覚的に分離された「危険ゾーン」カードにグループ化され、マルチステップの確認ダイアログがある。
• すべての入力グループにセマンティックHTML（<fieldset>、<legend>、<label>）が使用されている。
• アクティブフォーカスインジケーターはWCAG 2.2のコントラストルールを満たし、オーバーレイ要素やフローティングバナーによって隠されていない。
• すべてのテキストのコントラスト比はWCAG AA（最小4.5:1、大きなテキスト/アイコンは3:1）を満たしている。
• モバイルのタッチターゲットは、主要な入力に対して 44px x 44px のターゲットサイズを満たしている。