あやね
通知設定は、トグルを操作する前に「何が起きたら」「どの場所へ」「いつ届くのか」を答えられなければなりません。「通知オン」だけでは、緊急のレビュー依頼、コメントでのメンション、週次ダイジェストの違いを説明できません。保存した選択の結果を予測できる画面を作ることが重要です。
ここでは架空のデザインレビューサービスを例に、今後届く通知の設定画面を設計します。受信箱にすでにある通知を整理する画面とは目的が異なるため、必要なら通知受信箱のUXガイドを参照してください。実際の状態を試すときは、画面をPixsoのプロトタイプでつなぎ、説明なしで一つの変更を行ってもらいます。
チャンネルではなくイベントから始める
メール、プッシュ、アプリ内は届け先であり、通知の理由ではありません。まずサービスが実際に発生させるイベントを洗い出します。この例では、コメントでの直接メンション、担当になったレビュー、フォロー中のファイルの通常更新です。三つを同じ緊急度で扱わないことが出発点になります。
| イベント | 気にする理由 | 検証する初期値 | 設定で説明すること |
|---|---|---|---|
| 直接メンション | 本人への呼びかけで返答が必要かもしれない | アプリ内＋任意の即時チャンネル | メールを切ってもアプリ内には残る |
| レビューの割り当て | タスクが本人に渡された | アプリ内＋許可された即時チャンネル | チャンネルを変更・解除する方法 |
| フォロー中のファイルの更新 | 参考になるが一件ごとに緊急ではない | アプリ内またはダイジェスト | 遅れて届いてもファイルの変更自体は遅れない |
表の初期値は例であり、Pixsoの通知ポリシーを示すものではありません。採用前に対象ユーザーへ確認してください。無効化できないセキュリティ通知があるなら、「すべての通知」という約束に混ぜず、理由を該当行の近くに表示します。
各行で結果を説明する
イベントごとに一行を割り当て、短い説明とチャンネルの選択肢を置きます。「直接メンション — コメントで名前が指定されたとき」のように書けば、ベルや封筒のアイコンだけに意味を背負わせずに済みます。翻訳後や支援技術でも、イベントとチャンネルの関係が読めるラベルにします。
利用できないチャンネルは原因を示します。プッシュが無効なのは、OSの許可がないからかもしれません。メールが無効なのは、アドレスが未確認だからかもしれません。次に取る行動が異なるため、「通知をオンにする」だけでは不十分です。AppleやAndroidのシステム設定が管理する範囲を、製品のトグルが上書きできるかのように見せないでください。
許可・プリファレンス・配信状態を分ける
「プッシュが届かない」には、製品内でオフにした、端末が拒否した、配信条件を満たしていない、という複数の理由があります。たとえば「プッシュを選択済み・システム設定でブロック」と表示すれば、製品側の選択を勝手に変更せずに状態を伝えられます。
保存確認も同じ考え方で書きます。サーバーがイベント条件を受け付けたなら「プリファレンスを保存しました」と言えますが、端末の許可がない状態で「プッシュが届きます」と約束してはいけません。OSの設定で変えられる音や重要度も、製品側の設定とは別の境界として示します。
ダイジェストと静かな時間帯の範囲を明確にする
「少なく送る」だけでは判断できません。頻度、チャンネル、まとめるイベント、タイムゾーンを示します。例として「フォロー中のファイルの通常更新を、現地時間の平日9時にメールで一通」と書きます。直接メンションがダイジェストを迂回するなら、脚注ではなくメンション行に記載します。
静かな時間帯は、一定時間にどの割り込みを待たせるかを決める設定です。アプリ内の記録や作業そのものを消すものではありません。22時から8時を設定した場合、通常更新は朝まで待ち、直接メンションは選択した例外ルールで扱う、と表示します。タイムゾーンを変更したときは新しい現地時刻を確認できるようにします。
ボタンを描く前に保存方法を決める
複数の選択を同時に変更する画面では、各トグルを個別保存すると一部だけ失敗することがあります。ダイジェスト、通常プッシュ、静かな時間帯をまとめて変更するなら、明示的な保存ボタンで一つのプリファレンス集合として送る方法が安全です。送信中は「保存しています」と示し、成功後は重要な結果を要約します。
失敗しても入力値を消さず、再試行を用意します。別の端末で変更されていた場合は、現在の保存値と競合を示してから上書きさせます。押しただけで成功トーストを出したり、説明なく古い値へ戻したりしないでください。
一人の利用者の流れを追う
モバイル決済のレビューを担当するMayaが、コンポーネントライブラリをフォローしているとします。目的はメンションをすぐ受け取り、ライブラリの変更ごとのメールは止めることです。
- 設定を開き、メンションとファイル更新の現在値を確認する。
- ファイル更新だけを平日9時のメールダイジェストへ変更する。
- 22時から8時を設定し、待つ通知とアプリ内に残る通知を確認する。
- 保存後、ダイジェストとメンションの例外を要約で確認する。
- 翌日も同じ選択が表示され、届いたメールから推測せずに済む。
これは設計用のシナリオであり、Pixsoがこの通知を実際に送るという主張ではありません。重要なのは、ノイズの多いイベントだけを変えて別の通知を黙らせないことです。
成功例だけでなく端の状態を試す
保存済み、未保存、保存失敗、保存完了の四状態を描きます。プッシュがある場合はシステム許可との不一致も加えます。小さな画面ではイベント名とチャンネル名を同じ行で読めるようにし、横スクロールするチェックボックスの表を避けます。キーボード操作ではイベントとチャンネルを含むアクセシブルな名前を使い、保存結果は知覚できるステータスにします。
画面をPixsoに置き、保存・再試行・戻る経路を接続します。「メンションは残し、ファイル更新の個別メールは止めて」と同僚に依頼し、今夜と明朝に何が届くと思うかを尋ねます。答えが画面から出てこなければ、文言かグループ分けを見直します。プロトタイプは意図を伝えますが、実装では許可、タイムゾーン、配信ルールを別途保証します。
信頼される通知設定は、各コントロールの範囲が予測できます。イベント、チャンネル、時間を見える形にし、システムが実際に届けられる内容だけを約束してください。
