ui-context-and-scope

UI のコンテキストと範囲

ユーザーは常に、次の3つを把握できる必要があります。

1. 今どこにいますか？ — 製品階層内での現在の位置
2. どのコンテキストにいますか？ — アクティブなセクション、レコード、またはワークスペース
3. 操作によって何に影響しますか？ — 変更を確定する前に、その適用範囲を把握できること

これらが明確でないと、ユーザーは間違いを犯し、迷い、製品への信頼を失います。

視覚的な構造で階層を伝える

線と区切り

水平線や境界線は、セクション間の境界を示します。装飾としてだけでなく、異なるコンテキストに属するコンテンツ領域を分けるために使います。

• ヘッダーとコンテンツの間に線があると、「下のコンテンツはこのヘッダーに属する」ことを示します
• サイドバーの境界線は、「ここは目的の異なる別の領域である」ことを示します
• 区切り線を使いすぎないようにします。まずは近接性と余白で表現し、それだけでは不十分な場合に区切り線で補います

色の領域と背景色

背景色は、「今は別の領域にいる」ことを示す最も強力な手がかりの1つです。

• サイドバー、パネル、コンテキストドロワーには、異なる背景色を使います
• アクティブまたは選択中の領域には、控えめな塗りつぶしを使うと、「これが現在のコンテキストである」ことを確認できます
• ユーザーの変更が特定のセクションに限定される場合は、そのセクションを枠線、塗りつぶし、またはその両方で視覚的に囲み、確定する前に適用範囲がひと目でわかるようにします

セクションラベルとコンテキストヘッダー

主要な領域はすべて、ユーザーが周囲のコンテンツを読まなくても「ここは何か」に答えられるようにします。

• システム側の用語ではなく、ユーザーが使う用語でセクションに名前を付けます
• アクティブな対象を表示します。「設定」だけではなく、「編集中：請求書 #2041」や「ワークスペースの設定」のようにします
• 特定のレコードに影響するフォームでは、フォームヘッダーにレコード名を目立つように表示します

階層の深さを移動する

パンくずリスト

製品の階層が3段以上ある場合、またはユーザーが複数の経路からページに到達できる場合は、パンくずリストを使います。

Home > Projects > Website Redesign > Tasks > #142 Fix header

• 各パンくず項目は、その階層に戻るクリック可能なリンクにします
• 現在のページは最後の項目にします。リンクではなく、テキストとして表示します
• モバイルでは、直近の親だけを表示するよう折りたたみます：← Website Redesign
• パンくずリストは主要なナビゲーションの代わりではなく、それを補完するものです

ナビゲーションとしての検索とフィルター

大規模または動的なコンテンツツリーを持つ製品では、検索によって階層移動の認知的負荷を軽減できます。

• 製品全体からあらゆる対象を探すためのグローバル検索
• 現在の範囲内で絞り込むためのコンテキストフィルター
• 検索結果には、類似する項目を見分けられるだけのコンテキストを表示します（例：タスク名と併せてプロジェクト名を表示する）

操作前に適用範囲を伝える

変更、設定、または操作が特定の範囲に影響する場合、その範囲はユーザーが確定する前に伝えなければなりません。後から気づかせてはいけません。

• ラベル：「この設定の適用先：このワークスペースのみ」／「すべてのユーザーにこの変更が表示されます」
• **視覚的な囲み：**ユーザーが編集しようとしている領域をハイライトまたはアウトラインで示します
• **確認メッセージ：**破壊的な操作や広範囲に影響する操作では、確認ダイアログで適用範囲を明示します（「このプロジェクトと、その中の47件すべてのタスクを削除しますか？」）

隠れた適用範囲には、見えるインジケーターが必要

設定によってアプリケーション全体に表示されるデータ（テナント、サイト、環境）が決まる場合、切り替えコントロールは設定ダイアログ内に置いてもかまいません。ただし、状態まで隠してはいけません。画面の常に見える場所に、読み取り専用のインジケーターを配置します。変更頻度が低いことは、コントロールについての議論にはなりますが、状態を隠す理由にはなりません。インジケーターがないと、誤ったデータセットを表示していても、どの画面も正しく見えてしまいます。

適用範囲を切り替えると、以前の範囲から派生したものはすべて破棄されます。検索、ステージング済みの行、選択内容が該当します。

他の人の代理として操作する

ユーザーが別のユーザー、顧客、またはアカウントとしてデータを表示または変更する場合（代理ログイン、管理者の「〜として表示」、顧客に代わって行うサポート対応など）、その間ずっと、単にそのモードに入る瞬間だけでなく、代理操作中であることがはっきりわかるようにする必要があります。

• 常に表示され、見落としようのないインジケーター： セッション中ずっと画面に表示される色付きのバナーまたはバー（「Acme Corp として操作中です。変更はこのアカウントに反映されます」など）を使い、消えてしまうトースト通知は使いません。
• 誰の画面かを明示する： 操作対象のアカウントや顧客の名前を示し、オペレーター自身の通常のコンテキストと視覚的に区別して、混同の余地をなくします。
• わかりやすい終了方法： 「自分のアカウントに戻る／代理操作を終了」といった明確な操作を常に表示します。

ここで防ぐべきリスクは、オペレーターが自分自身のコンテキストにいると思い込んで変更した結果、実際には顧客のコンテキストだったという事態です。コンテキストの取り違えは、深刻な損害につながります。

認証は信頼に関わるコンテキストです

ログイン／サインアップ画面は、ユーザーがパスワードを預ける場所です。これは本質的に不安を感じる瞬間であり、正しく安全な場所にいると最も実感してもらう必要がある場面です。後回しにせず、信頼を築く画面として設計します。

• ブランドらしさが一目で伝わる必要があります。 汎用的なログインページやブランドイメージに合わないログインページは、不審に見えます（「本当にあのサービスなのか、それともフィッシングページなのか？」）。ロゴ、色、書体、トーンなど、ブランドアイデンティティを認証画面にも反映します。
• URL は顧客自身のエコシステム内に置く必要があります。 認証画面は顧客のドメインまたは明確なサブドメイン（app.customer.com、customer.com/login など）でホストし、無関係なサードパーティーの URL は使いません。パスは短く読みやすく保ちます（domain/path/path までとし、クエリパラメーターは意味のあるものだけにします）。ユーザーはアドレスバーを見て安全性を判断するため、不透明なリダイレクトの連鎖はフィッシングのように見えます。

ログアウト中はシェルを一切表示しません。 ルートでログイン画面だけを描画し、その背後には何も表示しません。ぼかしたシェルや閉じられないモーダルは隠蔽にすぎず、隠蔽は CSS によるものです。開発者ツールでクラスを 1 つ削除するだけで、匿名の訪問者にナビゲーション、顧客名、機能切り替えが見えてしまいます。ログアウト中にシェル要素が存在しないことをテストで検証します。

コンテキスト外に出るデータ。 機能がユーザーや顧客のデータを外部モデルに送信する場合、リクエストの前に、識別につながる文字列をすべて一貫した仮名に置き換え、レスポンスをクライアント側で元に戻します。行をまたいで仮名の一貫性を保ち、関係性が維持されるようにします。いったん名前が外部に渡れば、ベンダーがどのように約束しても、取り戻すことはできません。

内部ツールと外部向け製品を区別する

内部向け／バックオフィス向けソフトウェアには、意図的な視覚上の「特徴」を持たせます。異なるアクセントカラー、環境バッジ、目立つヘッダーなどを用いて、顧客向けアプリと見間違える余地がないようにします。これにより、オペレーターが内部管理画面を外部向け製品と（またはステージング環境を本番環境と）取り違えるのを防ぎます。この目印は常に表示され、すぐにわかるものである必要があり、設定ページに隠してはいけません。

どのアプリケーションか、誰のデータか、どの権限か

1つのログインで複数のツールを開ける場合、「今どこにいるのか」には、ユーザーが同時に把握する必要のある2つの答えがあります。その両方をページではなく、永続的なシェルに表示します（[[app-shell]]）。

どのアプリケーションか。 ツールがシェルとブランドを共有すると、見た目も似てきます。これは望ましい結果ですが、新たな問題も生みます。間違ったツールで操作してしまうことです。アプリケーション固有の名前はシェル内の常に同じ場所に表示します。

誰のデータか。 マルチテナントまたは複数顧客向けのツールでは、現在のテナント名を常に表示し、破壊的な操作の確認にも繰り返し表示します。テナント名はラベルとして示してください。ブランドを損ない、コントラストを予測できなくする色やテーマで表現してはいけません。色は、ステージングと本番環境を取り違えると実害が生じる、上記の環境表示にのみ使用します。

どの権限か。 内部ユーザーには、自分が現在どのロールで操作しているかを表示すると役立ちます。アクションが利用できない理由が分かり、過剰な権限を持つセッションを本人が認識できます。ロールはシェルに表示し、ユーザーのロールによって制限されるアクションは、何も表示せず隠すのではなく、理由を添えて無効にすることを優先します（[[nielsen-usability-heuristics]]）。顧客向け製品では、このようにロールを表示しないでください。その場合は、表示しないほうが分かりやすい答えになります。

レビューチェックリスト

• ユーザーは、現在編集しているセクションやレコードをいつでも特定できますか？
• 色の領域や境界線を使って、異なるコンテキストを一貫して区別していますか？
• 2階層を超えるナビゲーションには、パンくずリストまたは明確な戻り道がありますか？
• アクションの確認ダイアログには、影響を受ける範囲が記載されていますか？
• 別のアカウントの代理で操作する場合、誰の代理かを示す、常に表示される見落としにくいインジケーターと、いつでも使える終了手段がありますか？
• 内部向け／バックオフィスツールには、顧客向けアプリと（ステージング環境と本番環境を）区別する、常に表示される視覚的な手がかりがありますか？
• 設定でスコープの切り替え項目が非表示の場合も、現在のスコープはクローム内に読み取り専用で表示されていますか？
• ログアウト状態ではログイン画面だけが表示され、ぼかしやモーダルの背後にシェルが残っていませんか？
• 識別可能なデータは、外部のモデルやサービスに渡る前に仮名化されていますか？
• 認証画面はブランドに完全に沿ったデザインですか？ログイン URL は、お客様自身のドメイン／サブドメイン内にあり、短く読みやすいパスになっていますか？
• セクションタイトルはユーザーが使う言葉で書かれ、該当する場合は現在のエンティティを示していますか？
• コンテンツ構造が大きすぎて閲覧しにくい場合、グローバル検索を利用できますか？
• 複数のツールが1つのログインと1つの外観を共有する場合、現在のアプリケーション名は常に表示されていますか？
• 現在のテナントは、色やテーマで表現するのではなく、ラベルとして示されていますか？
• 内部ツールではユーザーのロールが表示されていますか？また、制限されるアクションは何も表示せず隠すのではなく、理由を添えて無効になっていますか？