通知受信箱のUX設計：既読・対応済み・購読解除を使い分ける

通知の受信箱では、「内容を見た」と「自分の対応を終えた」を区別する必要があります。デザインレビューのスレッドを開いても、コメントで指摘された問題が解決するわけではありません。未読バッジを消しても、その後の更新通知は止まりません。これらを一つの操作にまとめると、利用者は作業の続きが分からなくなったり、まだ追う必要のあるやり取りの通知を止めてしまったりします。

チームのデザインレビュー用受信箱を例に、既読・未読、自分の作業一覧の整理、通知の購読をどう組み合わせるかを考えます。目指すのは、一時的にバッジをゼロにすることではありません。いったん離れても、安心して作業に戻れる一覧です。

既読・対応済み・フォロー中は、それぞれ別の問いに答える

行ごとの操作を設計する前に、各状態の意味を定義します。既読・未読は、その人が該当する更新を見たかどうかを表します。一覧を整理するための状態は、その項目をアクティブな作業一覧に残しておきたいかを表します。フォロー中かどうかは、今後の更新通知を受け取るかを表します。一方、通知の対象であるレビューやタスクには、それ自体の状態があり、チーム全員で共有される場合があります。

これらは別々の軸であり、どれか一つしか選べない四つの状態ではありません。一つのレビューが、既読で、アクティブな一覧にあり、保存済みで、フォロー中ということもあります。すべてをバッジで表示する必要はありませんが、操作によってこれらの違いが曖昧にならないようにします。

GitHubの通知管理ドキュメント（英語）には、既読、完了、保存、購読解除が別の名前の操作として示されています。ただし、操作の影響が重なる部分もあり、購読を解除すると現在の通知も一覧から取り除かれます。また、本人へのメンション、チームへのメンション、レビュー依頼があれば、再び通知される場合があります。自分たちの受信箱のルールを決める際は、このように明記された操作の結果を参考にしてください。ボタンが分かれているからといって、影響まで独立しているとは限りません。

受信箱の1行が何を表すかを決める

このレビューの例では、1行が「購入手続きのエラーメッセージ」という一つのディスカッションスレッドを表します。同じスレッドに新しいコメントが3件付いても、更新されるのは同じ行です。その行には最新の動きとともに、「あなたへのメンション」「このレビューをフォロー中」など、その人に届いた理由を表示します。

このまとめ方なら、やり取りの多い一つのスレッドで受信箱全体が埋まりません。ただし、件数の数え方を決める必要があります。バッジの「3」は、未読スレッドが3件なのか、未読の更新が3件なのか、対応が必要な項目が3件なのか、解釈が分かれます。単位を一つ選び、明確に伝えましょう。この例では、アクティブな一覧にある未読スレッド数を数え、「対応済み」のスレッドは含めません。未読スレッドを「対応済み」に移すと、既読に変えなくても、この件数からは除かれます。同じアクティブな未読スレッドにコメントが3件付いても、数えるのは3件ではなく1スレッドです。

関連する件数は、それぞれ何を表すかを明示します。「アクティブ12件・未読3件」なら、3件を読んでも作業一覧が空にはならないと分かります。情報共有だけの更新や返信不要のやり取りが混在する件数を、「タスク」と呼ぶのは避けましょう。

一方、1行を一つの更新イベントとして扱う製品では、同じ対象が再び更新されたときに、古いイベントをどう扱うかを定義します。まとめ方そのものは設計上の選択ですが、説明なしにスレッド単位とイベント単位を切り替えると混乱を招きます。

次の行動を選べるだけの情報を、各行に載せる

使いやすい行は、すべてを開かなくても四つのことが分かります。何が変わったのか、どこで起きたのか、必要に応じて誰が更新したのか、なぜ自分に届いたのかです。購入手続きのレビューなら、スレッド名、プロジェクト名、「Mayaがあなたにメンションしました」、コメントの短い抜粋を表示できます。

抜粋には、タイトルの繰り返しではなく、判断に役立つ内容を載せます。「カード情報のどの項目を確認すればよいか、説明できますか？」なら、デザイナーは今レビューを開くべきかを判断できます。「『購入手続きのエラーメッセージ』に新しいコメント」という文では、ほかの表示項目に比べてほとんど情報が増えません。

未読の区別を、わずかな色の違いだけに頼らないようにします。読みやすいラベル、支援技術にも意味が伝わる説明を持つドット、文字の太さなどを組み合わせられます。既読になったあとも、タイトルと重要な文脈は読める状態に保ちます。目立ち方を弱めることと、コントラストを不足させることは別です。

相対時刻は一覧を見渡す助けになりますが、順序を理解する手掛かりが「昨日」だけにならないようにします。必要な場面では、利用者の現地時刻で正確な日時を確認できるようにしましょう。見る人のタイムゾーンが違うからといって、そのイベント自体が何を意味するかまで変えてはいけません。

どの時点で既読にするかを定義する

行を選んだ瞬間に既読にするのか、詳細ペインの読み込みが終わってからか、それとも明示的な操作をしたときだけか。実際に画面側で確認できることに合わせて決める必要があります。キーボードのフォーカスが行を通過しただけでは、その人が内容を読んだ証拠にはなりません。

この例では、行を選ぶと詳細ペインにディスカッションが読み込まれます。その内容を正常に表示できたあとで、表示対象の更新を既読にします。読み込みに失敗した場合は未読のままにし、再試行できるようにします。通信リクエストを送信しただけで、バッジを消してはいけません。

読んでいる途中で、新しいコメントが届くこともあります。ペインを開いたときに真偽値を一つ切り替えるだけではなく、どの更新まで表示したかを管理します。イベント18までのコメントを表示したあとでイベント19が届いた場合、古い更新に対する既読の確認応答によって、新しいイベントまで既読扱いにしてはいけません。新しいコメントをすぐに表示しても、別の更新が届いていると知らせても構いません。どちらを選ぶ場合も、一貫した既読ルールが必要です。

利用者がリマインダーとして使えるように、「未読にする」操作は残しておきます。その効果は本人に限られ、予測できるものにします。チームのレビューでスレッドを未読に戻したからといって、投稿者に「あなたの提案は却下された」と通知したり、別の人の既読状態を取り消したりするべきではありません。

「自分の対応は完了」を、あとから戻せるようにする

購入手続きについての質問に返信したあと、デザイナーは通知を「対応済み」にします。この受信箱では、スレッドが本人のアクティブな一覧から外れ、個人用の「対応済み」ビューに移ります。チーム全員にとってディスカッションが解決したことにはならず、画面の承認やコメントの削除も行われません。

周囲の画面から本人だけに関わる操作だと明確に分かるなら、ラベルを短く「対応済み」としてもよいでしょう。同じ画面に、チーム全体に影響する「ディスカッションを解決」もある場合は、文言と配置を分けます。異なる結果をもたらす二つの操作に、どちらもチェックマークだけを使うと混同されやすくなります。

操作直後に取り消せるようにし、時間がたってからも「対応済み」ビュー経由で戻せるようにします。行が消えたら、キーボードのフォーカスを適切な隣の項目、または空になった一覧の見出しに移します。存在しなくなった操作部品に、フォーカスを残してはいけません。

関連する新しいイベントが起きたとき、対応済みの項目をアクティブに戻すかも決めます。この例では、新しいメンションがあるとスレッドを未読として戻しますが、無関係なバックグラウンド更新では戻しません。これはこの受信箱で明示的に採用するルールであり、どの製品にも当てはまる決まりではありません。「対応済み」が当てにならないと感じさせないよう、戻ってきた理由を表示します。

購読解除では、今後の通知がどう変わるかを伝える

「フォローを解除」は、今後の通知の届き方を変える操作です。このデザインレビュー用受信箱では、通常の更新通知は止まりますが、現在のスレッドは「アクティブ」または「対応済み」の、もともとあったビューに残ります。「対応済み」にする操作とは別です。今日の一覧を片付ける操作だと誤解されないよう、この結果を操作の近くで伝えます。

この例では、通常の更新通知を止めたあとも、本人への直接のメンションがあれば、スレッドを未読としてアクティブな一覧に戻します。確認文は、「通常の更新通知を停止しますか？あなたへのメンションがあった場合は、引き続き通知されます」と書けます。製品によっては、チームへのメンションや担当レビューにも例外があるかもしれません。ただし、説明するのは実際にその製品で対応しているルールだけにします。

製品のルール上、停止できない通知に、汎用的な「購読解除」操作を付けてはいけません。代わりに、変更できる設定を説明します。また、購読設定によって非公開スレッドの閲覧権限が付与されるわけではありません。通知の配信とアクセス権は、別に扱う必要があります。

一つのレビューが受信箱を移動する流れを追う

次の流れで、ルールを具体的に確認できます。これは、設計対象であるデザインレビュー用受信箱の動作案であり、Pixso自体の通知システムを説明したものではありません。

一覧、詳細ペイン、メール内のリンクのどこから操作しても、結果が一貫するようにします。メールから戻ってきた人は、該当するディスカッションや更新を開けるべきです。「対応済み」に移動したという理由だけで、説明もなく空の受信箱を見せてはいけません。

操作の失敗や権限の変更があっても、状況を見失わせない

画面上では先に行を取り除いていても、その操作があとから失敗することがあります。「対応済み」への変更が確認できない場合は、分かりやすいメッセージとともに行を戻すか、未完了の操作を示しながら、その項目にアクセスできる状態を保ちます。サーバーが操作を拒否したのに、行が消えたことをもって、対応完了が確定したかのように見せてはいけません。

対象の項目がすでに存在しない場合は、開けないことを説明し、通知を一覧から取り除けるようにします。アクセス権が失われた場合は、キャッシュに残る非公開の抜粋を表示し続けないようにします。回復のための導線も、現在の権限を守る必要があります。通知のリンクは、権限の制限を回避するための抜け道ではありません。

「未読」で絞り込んでいると、行を読んだ時点で一覧から消えることがあります。読み終える前に詳細ペインまで消えないようにします。選択状態が分かるようにしたうえで、一覧を更新しても、開いているディスカッションは表示し続ける方法があります。「すべて」に戻したときも、無関係な項目へ飛ばすのではなく、作業を続けやすい位置を保ちます。

Pixsoで受信箱の状態設計をレビューする

現実的なレビューのスレッドをいくつか使い、Pixsoで一覧と詳細のレイアウトを作ります。未読のメンション、既読でもアクティブなディスカッション、新しいメンションで戻ってくる対応済みの項目、操作に失敗した項目を一つずつ含めます。本人の作業一覧の状態と、共有ディスカッションの状態は、注記を分けて説明します。

レビュー担当者に、Mayaの質問を自分の一覧から取り除かずに読み、そのあと対応を終えて通常の更新通知を止めてもらいます。それぞれの操作で何が変わると思ったかを聞きましょう。「対応済み」がデザインの承認だと受け取られたなら、アイコンを仕上げる前に、文言を改善するか、共有状態を変える操作と分けます。

主要な画面の状態をつないでレビューできるようにし、実装が必要な動作を注記します。対象の更新を識別できる既読の確認応答、項目を取り除いたあとのフォーカス、購読解除の例外、権限の変更などです。クリックできるプロトタイプは、意図した流れを伝えるために使えますが、その背後のルールが実装されたことを証明するものではありません。

Pixsoで、状態が伝わる通知受信箱をデザインする →

安心して使い続けられる作業一覧にする

未読件数は確認すべき更新を示し、本人の対応完了は作業を整理し、購読設定は今後の通知を制御します。それぞれの意味を区別し、変更した状態を戻せるようにし、項目が再び現れた理由を説明しましょう。受信箱が役に立つのは、バッジを消せるからではなく、自分の作業がどこにあるかを予測できるからです。