鳴らしすぎると誰も動かない ― SaaSデザインの通知設計

今日は SaaS デザインの通知設計です。通知って地味な機能に見えますが、実は業務の流れを握っています。鳴らし方を間違えると、承認も返信も埋もれて、使われない SaaS ができあがるんです。

まさにそうです。Slack はモバイル通知の既定値を、デスクトップをロックして1分後、あるいは操作停止から10分後にしています。同じ情報を全端末へ同時に鳴らさず、その人が今見ていない時だけ割り込ませる発想なんですね。

通知は情報配信ではなく、注意配分です。同じイベントでも、担当者には即時対応が必要で、管理者には日次サマリーで十分ということがある。だから設計はイベント起点ではなく、役割ごとの次の行動から逆算すべきなんです。

その通りです。設計では、緊急度、受信者の役割、チャネル、通知後に期待する行動、再通知条件を最低限分けておくべきです。アプリ内の Inbox で広く受け止め、メールや push は本当に急ぐものだけに絞るのが基本です。

Slack はキーワード通知を完全一致にし、端末間の通知タイミングもずらしています。重要なのは、誰にでも全部を送るのではなく、本人が関心を持つ語と不在タイミングに絞って割り込むことです。これはノイズ管理の設計ですね。

GitHub はさらに受信後の動きが明確です。Inbox には Save、Done、Unsubscribe があり、Saved は無期限保持、カスタムフィルターは最大15件まで作れます。つまり通知とは、読むだけでなく、追う、終える、離脱するを設計することなんです。

Asana は Inbox を知るべき更新、My Tasks を自分がやる仕事として分け、時間帯ごとの通知停止やプロジェクト別の既定通知まで持っています。通知とタスクを混ぜないことで、確認と実行のスピードを両立しているわけです。

Linear は重要更新を全部 Inbox に入れたうえで、外部チャネルは desktop、mobile、Slack、email digest に分けています。しかもメールは未読で、緊急度に応じた遅延をかけて送る。まず一元化し、割り込みだけ選ぶ設計です。

Jira Service Management では、Approver や Organization 共有で追加された人の通知が初期状態でオフになっているケースがあります。Intercom も即時会話通知と日次 sign-up サマリーを分けています。役割と頻度を分けるのが基本なんです。

まずはイベントと役割の表を作ってください。イベント、受信者、緊急度、チャネル、期待行動を並べ、即時通知は今反応しないと損失が出るものだけに絞る。評価指標も送信数ではなく、行動率や見落とし率で見るべきです。