あやね
権限UXは、誰がリソースを見られるか、誰が変更できるか、アクセスが変わったとき何が起きるかを説明します。まず、プロジェクトを読む、ファイルにコメントする、メンバーを招待する、リンクを公開する、といった利用者の行動から始めます。
役立つ権限フローは、対象者を選び、ロールを理解し、変更を確認し、付与後のアクセスを見るまでを扱います。アクセス申請には、正直な保留状態も必要です。インターフェースは、選択したロールだけでなく、サーバー側の認可によって実際に許可される操作を表します。ボタンを非表示にするだけではアクセスを制御できません。
ここでは共有、アクセス申請、継承ロール、協働中の復旧を扱います。より広いチーム作業については、UIデザインの協働ツール（英語）を参照してください。
ロール名ではなく操作から始める
「Editor」「viewer」「admin」は実装ラベルであり、利用者の目的とは限りません。利用者が知りたいのは、プロトタイプを変更できるか、メンバーを招待できるか、ファイルを書き出せるか、リンクを公開できるかです。選択肢の近くに実際の操作を示します。
対象、操作、対象者、結果を含む権限マトリクスを作成します。
| 対象 | 操作 | 対象者 | 結果 |
|---|---|---|---|
| プロジェクト | 下書きを見る | チームメンバー | プロジェクト内のファイルを開ける |
| ファイル | コメントする | レビュアー | コメントを追加できるがレイヤーは変更できない |
| ライブラリ | 更新を公開する | メンテナー | 選択したバージョンを利用者へ公開する |
| ワークスペース | メンバーを招待する | 所有者 | ポリシー確認後に人を追加する |
マトリクスはそのまま画面コピーにはしません。ロール名が複数の能力を隠している場所と、破壊的操作に確認や監査記録が必要な場所を明らかにする設計入力です。
利用者が境界に達する前に現在の状態を示す
制限は利用者が遭遇する場所で説明します。「公開できるのはプロジェクト所有者だけです」は、理由のない無効ボタンより多くを伝えます。説明は表示するかキーボードから到達できるようにし、マウス操作だけで表示されるツールチップに閉じ込めません。申請や問い合わせの経路は、実際に用意されている場合だけ示します。その文脈では決して使えず、説明する意味もない操作なら、無効なボタンを並べるより非表示にする方が分かりやすいこともあります。
存在を知る権限がない利用者へ非公開リソース名を表示しません。「このプロジェクトにはアクセスできません」と伝え、隠されたタイトルやメンバーを確認しない安全な文を使います。画面で明かしてよい情報の範囲は、セキュリティの担当者と決めます。
ロールの要約は短く行動指向にします。ポリシーの長文ではなく重要な能力を先に示し、詳細は必要なときに開けるようにします。メンバー一覧、共有ダイアログ、確認画面で順番をそろえます。
共有フローを結果のプレビューとして設計する
共有は相手の将来の操作を変えます。確認前にリソース、対象者、アクセスレベル、期限、通知を示します。リンクを転送できるなら明記します。選んだロールでダウンロードや複製も可能になる場合は、その結果をツールチップに隠さず表示します。
有用な確認には三つの要素があります。
- 誰が：個人、チーム、グループ、またはリンクを知る全員。
- 何ができるか：閲覧、コメント、編集、公開、アクセス管理。
- 期間：恒久、予定された期限、または手動で削除するまで。
「共有」ボタンを最後の操作にしても、対象者とロールを横に明示します。指定したメンバーから「リンクを知っている全員」へ変えると、確認前の要約に、ログインしていない訪問者も開けるかを反映します。この変更と失敗時の状態を、デザインから開発への引き継ぎにも記録します。
ロール変更を元に戻せ、追跡できるようにする
ロール変更は即時に適用されることがありますが、変更した人には結果を知らせます。確認後に何が変わったか、メンバーが一覧のどこに現れるかを示します。ポリシー審査や招待受諾が必要なら保留として扱います。
ポリシーが許すなら、以前のロールへ戻す操作を用意します。「操作を元に戻しました」ではなく、影響を受けた人とリソースを示します。管理者の承認が必要なら、次の手順を説明し、閲覧権限のある人が変更履歴を確認できるようにします。
編集途中でアクセスを失ったら、新しいポリシーで許されない操作を止め、何が起きたかを説明します。未保存の作業は、許可された回復経路でのみ保持し、保存できた範囲を明示します。たとえば、所有者向けに復元可能な下書きを残す一方、権限を失ったメンバーには機密資料のダウンロードを許さない設計が考えられます。「コピーを保存」ボタンを設計する前に、この挙動を決めます。
アクセス申請を小さく目的のあるフォームにする
アクセス申請は承認者に必要なものだけを集めます。リソース、求める操作またはロール、任意の理由、必要な場合の期限を含め、誰が受け取り次に何が起きるかを示します。システムがファイル名やチームを把握しているなら、利用者にプロジェクト全体を説明し直してもらう必要はありません。
送信後は保留、承認、却下、期限切れ、キャンセルを区別します。保留は記録された状態であり、アクセスが付与されたことではありません。リソースページに状態を残し、同じリンクで後から戻れるようにします。申請の詳細へのリンクも用意します。キャンセルや再申請が許される場合はその操作を示しますが、すべての状態に追加操作を用意する必要はありません。
申請後も境界を表示します。「申請を送信しました」という短いトーストだけでは、今すぐ作業できるか分かりません。ページに対象、要求したロール、申請先、保留状態を示す小さなパネルを置きます。
送信失敗は保留中の申請と別に扱います。応答が不確かな場合は、再送信の前に同じ申請が存在するか確認します。引き継ぎには申請ID、状態の更新方法、判断できる担当者、対象リソースや承認者が変わった場合の扱いを記録します。これにより、重複申請や追跡できない申請を防ぎます。
継承権限と直接付与を分ける
チームツールでは、ワークスペース、プロジェクト、フォルダー、グループから継承したアクセスと、個別ファイルの直接アクセスが組み合わさります。実効権限の出所を表示します。「Design team経由のViewer」は、単にViewerと書くより有用です。
継承ロールを変えようとしたら境界と正しい経路を示します。「このアクセスはプロジェクトから継承されています。プロジェクトのメンバーロールを変えてください」と説明し、編集できそうな無効コントロールを出しません。
複数の出所がアクセスへ影響する場合は、ポリシーが計算した実効権限と関連する出所を表示します。広い許可が常に勝つとは限りません。明示的な制限、組織のポリシー、リソースのルールが結果を変える場合を説明します。たとえば、直接付与したViewer権限を削除しても、プロジェクトのグループから継承したアクセスは残ることがあります。「アクセスを削除」と表示する前に、変更後の実効権限をプレビューします。
ゲスト、外部リンク、グループを別の対象として扱う
外部ゲストと社内メンバーは同じ現在の操作を持っていても、ライフサイクルとリスクが異なります。対象者を明示し、期限、ドメイン制限、ダウンロード規則が適用される場合はそれらを示します。「リンクを知る全員」と組織内限定のリンクを同じ見せ方にしないようにします。
グループは、閲覧者が知らない情報を漏らさずにメンバーシップを理解できる必要があります。グループ名と実効ロールを示し、詳細なメンバー情報へは閲覧権限のある経路から確認できるようにします。複数のグループ経由でアクセスできる場合は、非公開グループ名を漏らさずに最終的な権限を説明します。
地域や規制をまたぐチームではこの区別が重要です。規制産業向けオンプレミスUI設計ツール（英語）の議論は展開制約の背景を示しますが、ここでの権限境界は製品のポリシーに従います。
作業中にアクセスが変わったとき復旧する
プロジェクトの移動、招待の期限切れ、所有者によるロール変更、ポリシー更新でアクセスを失うことがあります。画面全体を汎用エラーに置き換えず、最後に分かっていた対象と保存状態を残し、何ができなくなったかを説明したうえで、最も安全な次の操作を示します。
回復には、ポリシーが許せばローカル下書きへ保存する、アクセスできる親へ戻る、再申請する、責任者へ連絡する、などがあります。内容を保持できないなら、ページを閉じる前に、保存できない範囲を明確に伝えます。ロール変更が原因なら、再試行するだけでアクセスが戻るように見せないことも重要です。
協働セッションでは協働ガイダンス（英語）とデザインからコードへの引き継ぎ（英語）を参照し、「別バージョンが公開中のため読み取り専用」と「ロールが変わったため読み取り専用」を分けます。同じ無効コントロールでも説明とサポート経路が異なります。
監査と通知の挙動を理解できるようにする
権限変更は設定画面を見ていない人にも影響します。誰に通知するか、通知の内容、アクティビティログに出るかを説明し、実際に送信されないメールやアラートを約束しません。一括変更では通知が抑制される場合、確認画面の詳細でそのことを説明します。
アクティビティには実行者、操作、リソース、対象者、時刻を含めます。リソースへのリンクは閲覧権限がある場合だけ置き、影響の大きい操作には確認や再認証が適切な場合があります。その際は、突然作業を中断するのではなく、安全確認が必要な理由を説明します。 監査ログの一覧と詳細では、イベントの記録と読み込み結果も区別します。
権限を孤立した画面ではなくタスクとしてテストする
所有者、編集者、コメント担当、閲覧者、ゲスト、アクセス権のない訪問者について、継承、申請、変更、取り消し、復旧を含む一連のシナリオを作ります。直接リンクと共有リンクも試します。
レビュー担当者には次のタスクを完了してもらいます。
- コメントはできるが編集はできない権限を付けて、チームメイトにファイルを共有する。
- 公開できない理由を確認する。
- 制限されたプロジェクトへのアクセスを申請し、状態を確認する。
- ゲストを削除し、開いているセッションに何が起きるか確認する。
- グループのロールを変え、どのファイルが継承するかを確認する。
アクセス境界をどこで知ったか、どこで推測を強いられたかを記録します。磨かれた共有ダイアログだけでは、変更後の状態が分かりにくい問題を解決できません。
Pixsoでは、制限画面、申請フォーム、保留状態の三つを接続したアクセスフローを作ります。画面が変わってもリソースの文脈を残します。レビューでは「送信すればすぐにアクセスできるか」「申請状況はどこで確認するか」を尋ねます。消えてしまうトーストに頼らず、三つ目の画面で答えが分かるようにします。デザインファイル自体を共有するときも、閲覧者・編集者の権限を目的に合わせて選びます。
両側から結果を確認する
申請者と承認者の両方としてアクセス申請をレビューします。承認前は申請者に保留状態が見え、制限コンテンツは開けないままにします。承認後は、表示されたロールが承認内容と一致し、そのロールで許可された操作だけが有効になることを確認します。次に、継承アクセスが残る状態で直接付与した権限だけを削除し、画面が残りのアクセスを正しく説明しているかを確かめます。最終画面は押したボタンの名前ではなく、実際に有効な権限を示す必要があります。
