🎃
ユーザーへの通知が必要な場合、適切な手段が準備されているか？
ユーザーへの通知が必要な場合、適切な手段が準備されているか？
背景・概要
機能変更や影響がある場合、ユーザーに事前に伝えることが信頼維持の鍵となる
通知手段・内容・タイミングを設計段階で明記することが望ましい
例
- システムメッセージ、バナー表示、メール、CS連携による通知計画
- 機能追加時に新旧 UI 並存期間を設定し、移行ガイドを併記
- API変更時に Deprecation ヘッダーの追加
よくある失敗例
- 告知なしで機能変更し、CSへの問い合わせが殺到
- メール通知の翻訳・承認フローを忘れていてリリースに影響
- ドキュメントの更新が漏れていてユーザーが困惑
FAQ
Q. 小さな変更でも通知すべき？
A. 影響の程度に応じて判断。UIやレスポンスの変化がある場合は通知するのが無難
Q. 通知手段はどれがよい？
A. メールは正式通知、バナーは簡易告知、SlackやWebhookは外部連携向けなど、用途に応じて併用するとよい。CSに連携してもらうのが一番楽かも
関連観点
- 変更の影響を考慮し、適切なリリース戦略が計画されているか？
- 変更の影響範囲が整理され、必要なコンポーネントの再利用が考慮されているか？
- API のスキーマが適切に設計され、他の API との整合性があるか？
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🚀 リリース・ロールバック
レベル：Structure（構造・原則・責務整理レベル）
推奨読者：設計初心者 / 設計中のチーム / レビュワー
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion