mcpField
U
ux-notifications-and-toasts

ux-notifications-and-toasts

github.com/uxcel-labデザイン・UI3698 回インストール17 週間前に更新
リポジトリ

ux-notifications-and-toasts について

ux-notifications-and-toasts は、緊急度や状況、ユーザーのニーズに合わせて通知形式を選ぶ生成型デザインスキルです。頻度や簡潔な文面、ユーザー制御に加え、プッシュ通知やパーソナライズの判断も扱います。

主な機能

  1. 01緊急度に応じた通知形式の指針
  2. 02頻度管理と通知のグループ化
  3. 03簡潔で行動につながる文面の指針
  4. 04ミュートと配信停止の制御
  5. 05プッシュ通知の方針に関する判断
  6. 06注意への配慮とアクセシビリティ監査連携

活用シーン

  1. 01アプリ更新に適した通知形式の選択
  2. 02通知の繰り返しによる疲労の軽減
  3. 03プッシュ許可とミュート設定の設計

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/uxcel-lab/product-skills --skill ux-notifications-and-toasts

インストール後、Claude Code で/ux-notifications-and-toastsを入力して読み込まれたか確認します。

詳細

通知 & トースト スキル

このスキルの動作 (最初にお読みください)

これは生成型のスキルです。デフォルトの失敗モードは次のとおりです: 緊急度のインフレ (すべてがアラートになり、成功メッセージが割り込む)、頻度の濫用 (同じイベントに対してユーザーがすべての通知を切るまで繰り返し通知する)、注意力の軽視 (通知でないものにバッジを付け、ユーザーにとって価値のない通知を送る)。通知はユーザーの注意力を消費します。種類はメッセージの実際の緊急度と一致していなければならず、システムは耳を傾ける価値があり続ける必要があります。このスキルは次をゲートします:

  1. 緊急度、オーディエンスの状況、チャネルを確定する — これらが種類を選びます。
  2. 常に適用されるコアを適用する — 種類と緊急度の一致、頻度の規律、コンテンツの簡潔さ、ユーザーの制御。
  3. エンゲージメントのレバー (プッシュ戦略、パーソナライゼーション、リッチメディア) をトレードオフとともに表面化する — これはダークパターンに近い領域です。

その後、検証のために ux-heuristics-audit、ux-accessibility-audit、ux-aesthetics-audit、ux-microcopy-audit、ux-dark-patterns-audit に引き継ぎます。


ステップ 0 — 設計前にコンテキストを確定する

不明な場合は質問し、回答なしで進める場合は前提を明示します:

  • そのメッセージは、実際どれほど緊急ですか? 今すぐ対応が必要 (支払い失敗) → 持続的なアラート。まもなく役立つ (ストレージが上限に接近) → 警告。参考情報 (保存済み、送信済み) → 一時的なスナックバー/トースト。ただ「何か新しい」 → バッジ。正直になりましょう — 緊急度のインフレが根本的な失敗です。
  • ユーザーはどこにいますか? アプリ内でアクティブ → 割り込まない: バッジをインクリメントするか、更新をインラインで挿入します。離れている → プッシュ (オプトインされている場合)。タスクの途中 → 後でまとめて配信します。
  • それは誰の目標に資しますか? ビジネスにしか資さない通知 (再エンゲージメントの催促) は信頼を損ないます。ユーザーがそれに感謝しないなら、再検討してください。
  • プラットフォーム — Android のトースト/スナックバーと iOS の慣習。プッシュの文字数制限 (タイトル約 39 文字 / 本文約 150 文字)。

常に適用されるコア (ほぼすべてのケースで正しい)

種類を緊急度に一致させる
  • バッジ — アイコンの右上のドット (またはカウント) で、未読通知のみに使用 — スコア、天気、マーケティングには決して使いません。ドット形状、慣習的な配置。一度見られると消えます。
  • ステータスバッジ — 一目でわかる状態 (オンライン、進行中、完了) — 情報提供であり、通知ではありません。
  • バナー — 一瞥する価値のあるイベント (新着メッセージのプレビュー) のための一時的な帯 (上部/下部)。ブロックしません。
  • スナックバー — コンテキスト内での画面下部の確認で、しばしば 1 つのアクションを伴います (「メッセージを送信しました」+ 元に戻す)。FAB や重要なコントロールを決して覆いません。
  • トースト — 優先度の低いシステムメッセージ。閉じられず、積み重なる場合があります — 控えめに使用してください。
  • アラート — 解決されるまで持続し、注意を要求するものに使用します。成功 = 緑 + チェック、自動で消える;情報 = ℹ;警告 = 対応までの時間の予告;エラー = 赤 + 感嘆符、即時対応。 情報メッセージを警告に見せかけないでください。
  • プッシュ — アプリ外のユーザーに届きます。最もコストの高いチャネルで、オプトインであり、最も失われやすいものです (ゲートされた表を参照)。
頻度の規律
  • 1 つのイベントに 1 つの通知。 同じ未読メッセージに対して再通知しないでください。代わりに関連する通知をグループ化します。
  • フォアグラウンドでの猶予: アプリが開いているときは、バッジを更新するかコンテンツをビューに挿入します — すでに画面を見ている人にシステム通知を発火させないでください。
  • コンテキストに基づく個別化は一斉配信に勝る: セグメント化し、ユーザーの実際のジャーニー (使用制限の接近、よく使う機能) を参照し、決してばらまかないでください。
コンテンツ
  • 簡潔で読みやすい: メッセージを伝える短いタイトル、平易な言葉、専門用語なし。プッシュ: タイトル約 39 文字、本文約 150 文字 — 短いほど良いです。
  • 可能な限りアクション可能に: スナックバーの元に戻す、アプリを開かずに解決するプッシュアクション。
ユーザーの制御 (譲れない)
  • ミュートまたはオフにしやすい — グローバルおよび種類ごとに、頻度オプション付きで。通知を調整できるユーザーは通知を使い続け、できないユーザーは通知を (またはアプリを) 切ってしまいます。
  • オプトアウトのフローで責めたり恥をかかせたりしない。

文脈依存の判断(表面化させ、自動適用しない)

判断項目適用する場合避ける/適応させる場合デフォルトの推奨
プッシュ通知をそもそも送るか時間に敏感で、ユーザーにとって価値のある更新(注文の発送、メッセージの受信)再エンゲージメントを促す執拗な通知、一般的なプロモーション — オプトアウトへの最短ルートまずはトランザクション通知。プロモーションは明示的で詳細なオプトインがある場合のみ
プッシュ通知のオプトイン依頼事前の働きかけがあり、関連するジャーニーのタイミングで、価値が示されている初回起動時のままのシステムダイアログ事前の働きかけ → 文脈の中で依頼する(権限のパターンについては ux-modals-and-dialogs を参照)
パーソナライゼーション名前、過去の行動、好み — 測定可能なほどエンゲージメントが高まる気味の悪いほどの具体性。ユーザーが使われると予想していなかったデータアプリ内の行動からパーソナライズし、透明性を保つ
リッチメディア(画像/GIF)視覚的なコンテンツが実際の情報を加える場合(商品画像、配達写真)シンプルなメッセージを肥大化させる装飾まずはテキスト。情報を伝える場合にメディアを使う
位置情報ベース(ジオフェンシング)真に文脈的な価値がある場合(ゲート変更、注文が有効な状態での近隣店舗)監視色のあるマーケティングのping高い基準を設定。明示的な権限、明白な価値
タイミングの最適化ユーザーのアクティブな時間帯、そのタイムゾーンで送信する有用性よりもクリックのために最適化する(午後11時の「会いたいです」)ユーザー行動に基づくタイミング、頻度の上限設定
バッジの件数 vs. ドット数えられる未読アイテム(受信トレイ)には件数無制限に増え続け、不安を誘発する件数「何か新しいもの」にはドット。数が役立つ場合には件数
パフォーマンス監視開封率/CTR および オプトアウト/ミュートを疲労のシグナルとして追跡するオプトアウトが増える一方で開封率を喜ぶオプトアウト率を主要な健全性指標として扱う

結果を検証する(オーケストレーション)

受け渡しでは、各レンズをインストール可能なスキルの name で指定します。インストール済みの場合にのみ呼び出してください。インストールされていない場合、このスキル自体のコアにすでにこれらのルールが含まれているため、ブロックせずにそのまま進めてください。

生成または改訂した後、完了と宣言するのではなく、結果を監査レンズに渡してください。これらは候補のレンズです — 姿勢は docs/orchestration-policy.md によって設定されるか、全体を ux-design-review 経由でルーティングしてください。ここでは、**heuristics、microcopy、dark-patterns は Tier A(自動実行)、accessibility、aesthetics、mobile-responsiveness は Tier B(提案)**です — 既存のデザインシステムがある場合、aesthetics は抑制され、accessibility は使用状況に絞り込まれます。mobile-responsiveness はモバイルの場合にのみ適用されます。ユーザーがこのスキルを特定の用途で呼び出した場合は、その範囲を尊重してください。

  • ux-heuristics-audit (Tier A) — 妨害のないシステムステータスの可視性、緊急性と表現の一致、ユーザーの制御と自由。
  • ux-accessibility-audit (Tier B — 提案。デザインシステムがある場合は絞り込み) — 色とアイコンを組み合わせた緊急性のコーディング(色だけに頼らない)、一時的なメッセージのスクリーンリーダーによる告知、読むのに十分なスナックバーの表示時間。
  • ux-aesthetics-audit (Tier B — 提案。デザインシステムがある場合は抑制) — アラートスタイリングの抑制、インターフェース全体におけるバッジ/バナーの視覚的ノイズ。
  • ux-microcopy-audit (Tier A) — タイトル/本文の簡潔さ、平易な言葉遣い、CTA の動詞の品質、オプトアウトの文言。
  • ux-dark-patterns-audit (Tier A) — バックログはこのスキルを注意尊重の領域としてフラグを立てています。作り出された緊急性、執拗な通知ループ、埋もれたミュート設定、罪悪感を煽るオプトアウト。
  • ux-mobile-responsiveness-audit (Tier B — 提案。モバイルの場合にのみ適用) — 文脈がモバイルの場合。スナックバー/FAB のレイアウト、OS 間でのプッシュ通知のレンダリング。

監査によって競合が表面化した場合(例:エンゲージメント目標 vs. 通知疲労)、主要なタスクに立ち返って解決してください。通知システムはユーザーが信頼している間だけ機能します — 単一のキャンペーンよりもその信頼を守ってください。


よくある do/don't パターン

❌ しない✅ する
すべてのメッセージを緊急アラートとしてスタイルする実際の緊急度に合わせた種類にする。ほとんどのメッセージは控えめにする
同じ未読メッセージを毎時再通知する1 つのイベントに 1 つの通知。残りはグループ化する
ユーザーがアプリ内にいるときにシステム通知を出すバッジの増加またはインライン挿入にする
バッジ件数に天気を表示するバッジは未読通知のみに使う
フローを中断する成功モーダル自動で消えるスナックバー/成功アラート
FAB を覆うスナックバースナックバーはすべてのコンテンツの上に、コントロールを避けて表示する
初回起動時にプッシュ許可ダイアログを出す事前に説明し、価値を示したうえで文脈に沿って依頼する
午後 11 時に「We miss you 😢」タイムゾーンを考慮し、行動に基づき、ユーザーにとって価値のある通知
ミュートが 4 画面も奥に埋もれている種類ごとのコントロール、簡単なグローバルオフ
150 文字の専門用語メッセージを伝える約 39 文字のタイトル
確認せずに出荷するヒューリスティクス + アクセシビリティ + 美学 + マイクロコピー + ダークパターンに引き継ぐ

出典レッスン (Uxcel)

コメント