あやね
ワークスペースを切り替える画面が即座に答えるべき問いは、「次の操作はどこに反映されるか」です。現在のワークスペース、使っているアカウント、未保存の作業を切り替え前に確認できるようにします。名前の似た顧客案件を複数扱うとき、ロゴだけのメニューではアップロードやコメントの宛先を間違えやすくなります。
小さな制作会社で、担当者がNorthstarの決済画面とRivertonの予約画面を同じブラウザーで担当しているとします。問題は切り替えメニューを見つけられるかだけではありません。コメント、ファイル、招待が別の顧客側に入ることです。この状態をPixsoで行う共同デザイン作業の画面として設計します。ここでの顧客ワークスペースは設計課題であり、Pixso本体のアカウント切り替え仕様を説明するものではありません。
アカウント、ワークスペース、プロジェクトを分ける
アカウントは「誰が操作するか」、ワークスペースは「どの組織・顧客の領域か」、プロジェクトは「その中のどのファイル群か」を答えます。三つをラベルなしで混ぜると、どちらの顧客にもある「Webサイト改修」というプロジェクトを見分けられません。
この例では、常に見えるヘッダーを「Northstar / 決済画面改修」とし、プロフィール付近に担当者の名前を示します。メニューでは顧客名の下にプロジェクトをまとめます。Rivertonへ切り替えたら、ヘッダーと次のアップロード先を同時に変えます。顧客名が開いたメニューの中にしかないのでは遅すぎます。ほとんどの操作はメニューを閉じた後に行われるからです。
長い正式名称でも試してください。「Northstar Brand」と「Northstar Support」の違いが省略記号の先に隠れると、短縮表示は役に立ちません。幅が狭い場合もフォーカス時やメニュー内で正式名称を読めるようにします。色付きのアバターだけに識別を任せてはいけません。
切り替え先の意味が分かるメニューにする
メニューの先頭では現在地を確認できるようにします。各候補にはワークスペースの正式名称、アカウント、権限、最近使ったプロジェクトを必要な範囲で示します。件数が増えれば検索が便利ですが、検索結果にも親の顧客名を残します。同名のプロジェクトだけを表示すると誤選択を招きます。
最近使用した候補を上に出す場合も、メニューを開いている間に項目が突然並び替わらないようにします。現在地の印ははっきり付けます。メニューボタンとして実装するなら、開閉やキーボード操作はW3Cのメニューボタンのパターンを参考にします。検索付きリストやダイアログなら、それに合う操作方法を選び、あらゆる部品にメニューの意味付けを流用しません。
「新しいワークスペースを作成」は既存の場所への移動ではないため、候補とは区切ります。「メンバー管理」「ログアウト」も切り替え先のように並べない方が迷いません。
未保存の作業をどう扱うか決めてから切り替える
Northstarでレビューコメントを入力したまま送信していない担当者がRivertonを選んだとします。まず製品として下書きを維持できるかを決めます。維持できるなら、元のワークスペースに残すと明記します。できないなら、その場にとどまって送信するか、破棄して移動するかを選べるようにします。後から取得できない下書きに「保存」を約束してはいけません。
ブラウザーの離脱確認だけを回復策の中心にするのは不安定です。MDNはbeforeunloadが一部のモバイル経路で期待どおり動かないことを説明し、未保存データがあるときだけ使うよう勧めています。アプリ内の切り替えなら「Northstar / 決済画面改修のコメントは未送信です」と対象を具体的に示せます。
アップロードが進行中なら、そのファイルがどちらのワークスペースに属するかを保ちます。元の場所で安全に続行できる場合だけ切り替えを許すか、続行できない理由を表示します。宛先のない読み込み表示の後に結果だけが現れると、どちらに保存されたのか分かりません。
権限の違いを切り替え後の驚きにしない
Northstarでは編集者、Rivertonでは閲覧者かもしれません。候補一覧を細かな権限表にする必要はありませんが、「Riverton・閲覧のみ」のように重要な違いを見せます。切り替え後は編集に必要な操作をその権限に合わせます。理由の分からない無効ボタンより、「ここでは閲覧できます。コメント権限は管理者に依頼してください」の方が次の行動が分かります。
権限の高い操作を境界越しに持ち越してはいけません。Northstarで招待ダイアログを開いたまま切り替えた場合、ダイアログを閉じるか、Rivertonの宛先に変わったことを送信前に明確にします。そうしなければ別の顧客へメンバーを招く可能性があります。重要な操作の確認画面には、ヘッダーとは別に宛先を繰り返してください。
別アカウントへの切り替えはさらに別の操作です。同じワークスペースでもログイン先が違えば権限が変わります。複数アカウントを扱う画面では、ワークスペース名の近くにアカウントの識別情報を置き、切り替え後に権限を再評価します。
切り替え結果と失敗時の現在地を示す
成功したら常設ヘッダーをすぐ更新し、新しいワークスペースの最近のプロジェクト一覧など予測できる場所へ移動します。最後に見たファイルを開き直す場合も、編集操作を出す前に所属先を示します。「Rivertonに切り替えました」という短い通知は役立ちますが、消える通知より残り続ける現在地表示が重要です。
候補を表示した後でアクセス権が取り消されたなら、安全な元のワークスペースにとどめます。Rivertonが使えなくなったことを説明し、候補を更新します。通信エラーでも現在地がNorthstarのままかどうかを明示してください。空白のファイル画面に古い顧客名だけを残すのは危険です。
W3Cの状態メッセージに関する解説は、成功やエラーを必要以上にフォーカス移動させず伝える方法を扱います。未送信コメントの処理を本人に選んでもらう場面ではダイアログが必要ですが、成功するたびに中断を強いる必要はありません。
間違った宛先になりかける瞬間を試す
Pixsoで、未送信コメントを持つNorthstar、両顧客と権限を示す切り替え画面、切り替え後のRivertonの三つをつなぎます。アクセス権が失われた場合や通信失敗の経路も追加します。各画面の常設ラベルを比べると、孤立した画面では見えない宛先の混乱を確認できます。
同僚に「Northstarのレビューへコメントし、Rivertonへ移動してメンバーを招待してください」と頼み、二つの顧客名が似ていることは教えません。各段階の現在地、未送信コメント、招待の宛先を自分で説明できるかを見ます。操作先と途中の作業の扱いが明確なら、切り替えは単なる移動ではなく安心して仕事を続けるための仕組みになります。
