通知 (設計の基本)

[アーティクル]
06/13/2023

Note

この設計ガイドは Windows 7 用に作成されており、新しいバージョンの Windows では更新されていません。ガイダンスの多くは原則として適用されますが、プレゼンテーションと例には現在の設計ガイダンスは反映されていません。

通知は、通知領域のアイコンから吹き出しを簡単に表示することで、現在のユーザーアクティビティとは無関係のイベントをユーザーに通知します。通知は、ユーザーアクションまたは重要なシステムイベントによって発生する可能性があります。または、Microsoft Windows またはアプリケーションから有用な情報を提供する可能性があります。

通知の情報は便利で 関連性がありますが、重要ではありません。 その結果、通知は即時のユーザー操作を必要とせず、ユーザーは自由に無視できます。

タイトルに

一般的な通知。

Windows Vista 以降では、9 秒間の固定期間の通知が表示されます。ユーザーが非アクティブな場合やスクリーンセーバーが実行されている場合、通知はすぐには表示されません。 Windows は、これらの時間帯に通知を自動的にキューに入れ、ユーザーが通常のアクティビティを再開したときにキューに登録された通知を表示します。そのため、このような特別な状況に対処するために何もする必要はありません。

開発者： SHQueryUserNotificationState API を使用して、ユーザーがアクティブになっているタイミングを確認できます。

メモ：通知領域、タスクバー、バルーンに関連するガイドラインは、別の記事で示されています。

これは適切なユーザーインターフェイスですか?

それを判断するには、以下の質問を考えます。

この情報は、ユーザーがアプリケーションとやり取りした結果として、即時に直接行われますか? その場合は、ダイアログボックス、メッセージボックス、バルーン、またはインプレース UI を使用して、アプリケーション内でこの同期情報を直接表示します。通知は非同期情報のみを対象としています。

Windows セキュリティアラートのスクリーンショット

この例では、[Windows ファイアウォールの例外] ダイアログボックスがユーザー操作の直接の結果として表示されます。ここでは通知が適切ではないでしょう。

この情報は、ユーザーがアプリケーションを積極的に使用している場合にのみ関連しますか? その場合は、アプリケーションのステータスバーまたはその他のステータス領域に情報を表示します。

Outlook ステータスバーのスクリーンショット

この例では、Outlook は接続と同期の状態をステータスバーに表示します。

情報は急速に変化し、継続的でリアルタイムの情報ですか? たとえば、処理の進行状況、株価、スポーツスコアなどがあります。その場合は、急激に変化する情報に適していないため、通知を使用しないでください。
情報は役に立ち、関連性がありますか? ユーザーは、情報を受信した結果、動作を変更したり、不便を避けたりする可能性がありますか? 表示されない場合は、情報を表示しないか、ステータスウィンドウまたはログファイルに配置します。
情報は重要ですか? 即時アクションは必要ですか? その場合は、注意が必要で、モーダルダイアログボックスやメッセージボックスなど、簡単に無視できないインターフェイスを使用して情報を表示します。プログラムがアクティブでない場合は、プログラムのタスクバーボタンを 3 回点滅させ、プログラムがアクティブになるまで強調表示したままにすることで、重要な情報に注意を引くことができます。
主要なターゲットユーザーは IT プロフェッショナルですか? その場合は、ログファイルエントリや電子メールメッセージなどの代替フィードバックメカニズムを使用します。 IT プロフェッショナルは、重要でない情報に対してログファイルを強く優先します。さらに、多くの場合、サーバーはリモートで管理され、通常はユーザーがログオンせずに実行されるため、通知は無効になります。

設計概念

優れたユーザーエクスペリエンスを促進する効果的な通知は次のとおりです。

[非同期]。 このイベントは、ユーザーが Microsoft Windows またはアプリケーションと現在やり取りした場合の直接的な結果ではありません。
有用。 ユーザーが通知の結果としてタスクを実行したり、動作を変更したりする可能性は妥当です。
関連。 この通知には、ユーザーが関心を持ち、まだ知らない有用な情報が表示されます。
重要ではありません。 通知はモーダルでなく、ユーザーの操作を必要としないため、ユーザーは自由に無視できます。
実用的。 アクションの実行を提案する通知の場合、そのアクションは通知をクリックして開始されます。ただし、アクションは常に延期できます。
適切に提示されます。 通知のプレゼンテーション (期間、頻度、テキスト、アイコン、対話機能) は、その状況と一致します。
迷惑ではありません! イベントをユーザーに優しく通知することと、それらを有害にすることの間には細かい線があります。

残念ながら、そこに迷惑な、不適切な、役に立たない、無関係な通知が多すぎます。 Windows XP の羞恥のホールからの次の通知を検討してください。

'ツアーウィンドウXP'通知のスクリーンショット

これらの例では、Windows XP は表向き、ユーザーの初期構成を支援しようとしています。ただし、これらの通知は、役に立った後にあまりにも頻繁かつ適切にポップアップするので、未承諾の機能の広告に過ぎない。

ユーザーフローを維持する必要がある

作業に没頭しているユーザーには、通知がまったく表示されないのが理想的です。代わりに、フローが既に壊れている場合にのみ通知が表示されます。

フロー:最適な経験の心理学、Mihaly Csikszentmihalyiは、ユーザーが時間の感覚を失い、大きな満足感を持っている活動に完全に吸収されると、ユーザーがフロー状態に入ると言います。

効果的な通知は、ユーザーが無視しやすい有用な関連情報を提示することで、フローを維持するのに役立ちます。 通知は低キーの周辺機器で表示され、操作は必要ありません。

通知がモードレスの場合、迷惑な中断にはなれないと想定しないでください。通知はユーザーの注意を必要としませんが、確かに要求します。次の方法でユーザーフローを中断できます。

ユーザーが気にしない通知を表示する。
通知の表示頻度が高すぎます。
1 つの通知で十分な場合に複数の通知を使用する。
通知を表示するときにサウンドを使用する。

Windows 7 では、ユーザーは通知を最終的に制御できます。 ユーザーがプログラムの通知が煩わしいと感じる場合は、そのプログラムからのすべての通知を抑制することを選択できます。 ユーザーが役に立つ関連情報を提示し、これらのガイドラインに従ってプログラムに対してこれを行わないよう確認します。

通知は無視できる必要があります

通知には即時のユーザー操作は必要なく、ユーザーは自由に無視できます。

開発者やデザイナーは、多くの場合、ユーザーが無視できない方法で通知を表示したいと考えています。この目標は、ユーザーのフローを損なうため、通知の主な利点を完全に損ないます。ユーザーが通知に気を取られたり、通知を読む義務がある場合、通知の設計は失敗します。

ユーザーが通知を無視している場合は、次の点を考慮してください。

通知を正しく使用していて、すぐにユーザー操作を必要としない場合は、ユーザーに無視を選択してもらうのは設計上の方法です。これを変更しないでください。
イベントに即時ユーザーアクションが必要な場合は、ユーザーが無視できない代替ユーザーインターフェイス (UI) を使用します。「これは適切なユーザーインターフェイスですか?」を参照してください。代替案の場合は。

必要に応じてプログレッシブエスカレーションを使用する

ユーザーが最初は安全に無視できるが、最終的に対処する必要があるイベントに対して通知を使用する場合は、状況が重大になったときに代替 UI を使用する必要があります。この手法は、プログレッシブエスカレーションと呼ばれます。

たとえば、Windows 電源管理システムは、通知領域アイコンを変更するだけで、最初はバッテリ残量が少ないことを示します。

バッテリーの状態を示す 6 つのアイコンのスクリーンショット

これらの例では、Windows 電源管理では、通知領域アイコンを使用して、バッテリーの電力が徐々に低下することをユーザーに通知します。

バッテリーの電力が低下すると、Windows は通知を使用して弱いバッテリ電源をユーザーに警告します。

バッテリ残量が少ない場合の通知のスクリーンショット

この例では、Windows 電源管理は通知を使用して、バッテリーの電源が弱い旨をユーザーに通知します。

この通知は、ユーザーがまだいくつかのオプションを持っている間に表示されます。ユーザーは、プラグイン、電源オプションの変更、作業のラップアップとコンピューターのシャットダウン、または通知を無視して作業を続行できます。バッテリーの電源が切れ続けるにつれて、通知のテキストとアイコンに追加の緊急度が反映されます。ただし、バッテリの電源が非常に低くなり、ユーザーがすぐに操作する必要が生じると、Windows 電源管理はモーダルメッセージボックスを使用してユーザーに通知します。

深刻なバッテリー残量警告のスクリーンショット

この例では、Windows 電源管理ではモーダルメッセージボックスを使用して、バッテリの電力が非常に低いことをユーザーに通知します。

3 つの操作のみを行う場合...

本当に必要な場合にのみ通知を使用します。通知を表示すると、ユーザーを中断したり、ユーザーに迷惑をかけたりする可能性があります。中断が正当化されていることを確認します。
重要でないイベントや、ユーザーの即時操作を必要としない状況に通知を使用します。重要なイベントや、ユーザーの即時操作が必要な状況では、代替 UI (モーダルダイアログボックスなど) を使用します。
通知を使用する場合は、適切なユーザーエクスペリエンスにします。ユーザーに通知の表示を強制しないでください。ユーザーが自分の作業に夢中になっているため、通知が表示されない場合は、設計をお勧めします。

使用パターン

通知には、いくつかの使用パターンがあります。

Label	値
アクションの成功非同期のユーザー開始アクションが正常に完了したときに、ユーザーに通知します。	正確: この例では、Windows Updateはコンピューターが正常に更新されたときにユーザーに通知します。正しくない: この例では、データファイルのチェックが完了すると、Microsoft Outlook によってユーザーに通知されます。ユーザーは今何をする必要がありますか? また、正常に完了したことをユーザーに警告する理由は何ですか? 次の場合に表示します。非同期タスクの完了時。完了を待機している可能性がある場合、または最近の失敗後にのみ、成功したアクションをユーザーに通知します。次の方法を示します。リアルタイムオプションを使用して、ユーザーが全画面表示アプリケーションを実行しているとき、またはコンピューターをアクティブに使用していないときに、これらの通知がキューに登録されないようにします。頻度を表示します。ある時。迷惑要因: 最近のエラーが原因で成功が予想されない場合は低く、成功は重大または非常に異常な障害の後であるため、ユーザーは追加のフィードバックを必要とするか、ユーザーが完了を待っています。高い場合は。選択肢：操作の実行中に通知領域にアイコン (または既存のアイコンを変更) を表示して、"オンデマンド" にフィードバックを送信します。操作が完了したら、アイコンを削除します (または前のアイコンを復元します)。
アクションの失敗非同期のユーザー開始アクションが失敗したときにユーザーに通知します。	正確: この例では、Windows ライセンス認証によってユーザーにエラーが通知されます。正しくない: この例では、Microsoft Outlook を使用して、気になる可能性が低いエラーをユーザーに通知しました。次の場合に表示します。非同期タスクが失敗した場合。頻度を表示します。ある時。迷惑要因: 便利で関連性の高い場合は低。問題が直ちに解決されるか、ユーザーが気にしない場合は高くなります。選択肢：ユーザーがエラーに直ちに対処する必要がある場合は、モーダルダイアログボックスを使用します。
重要でないシステムイベント少なくとも一時的に無視しても問題がない重要なシステムイベントまたは状態をユーザーに通知します。	この例では、Windows はユーザーにバッテリの低電力を警告しますが、アクションを実行するまでに十分な時間が残っています。次の場合に表示します。イベントが発生し、ユーザーがアクティブな場合、または条件が引き続き存在する場合。問題が発生した場合は、問題が解決されたら、すぐに現在表示されている通知を削除します。アクション通知と同様に、ユーザーがイベントを待機している可能性が高い場合、または最近の障害の後にのみ、成功したシステムイベントをユーザーに通知します。頻度を表示します。イベントが最初に発生したときに 1 回。ユーザーが解決する必要がある問題が原因の場合は、1 日に 1 回再表示します。迷惑要因: 通知があまり頻繁に表示されない限り、低。選択肢：ユーザーが最終的に問題を解決する必要がある場合は、解決が必須になったときに最終的にモーダルダイアログボックスを表示することで、段階的なエスカレーションを使用します。
省略可能なユーザータスク実行する必要がある非同期タスクをユーザーに通知します。オプションでも必須でも、タスクを安全に延期できます。	この例では、Windows Updateは新しいセキュリティ更新プログラムをユーザーに通知しています。次の場合に表示します。タスクを実行する必要性が判断され、ユーザーがアクティブな場合。頻度を表示します。 1 日に 1 回、最大 3 回。迷惑要因: 低。ユーザーがタスクを重要と見なし、通知が頻繁に表示されない限り。選択肢：ユーザーが最終的にタスクを実行する必要がある場合は、タスクが必須になったときに最終的にモーダルダイアログボックスを表示することで、段階的なエスカレーションを使用します。
Fyi 役に立つ可能性のある関連情報をユーザーに通知します。省略可能で、ユーザーがオプトインする場合は、限界関連の情報をユーザーに通知できます。	正確: この例では、新しい電子メールメッセージを受信すると、ユーザーに通知されます。正確: この例では、連絡先がオンラインになったときにユーザーに通知を受け取り、このオプションの情報を受け取ります。正しくない: この例では、この情報は、ユーザーが既に高速 USB ポートをインストールしている場合にのみ役立ちます。それ以外の場合、ユーザーは、その結果として何も変わることはありません。次の場合に表示します。トリガーイベントが発生したとき。次の方法を示します。リアルタイムオプションを使用して、ユーザーが全画面表示アプリケーションを実行しているとき、またはコンピューターをアクティブに使用していないときに、これらの通知がキューに登録されないようにします。頻度を表示します。ある時。迷惑要因: ユーザーの有用性と関連性に対する認識に応じて、中から高。ユーザーの関心の確率が低い場合は推奨されません。選択肢：ユーザーに通知しないでください。
機能の提供情報新しくインストールされ、使用されていないシステムまたはアプリケーションの機能をユーザーに通知します。	機能広告に通知を使用しないでください。代わりに、次のような別の方法を使用して機能を検出できるようにします。必要なコンテキストで検出しやすくするために機能を設計します。特別な操作を行わないで、ユーザーが自分で機能を検出できるようにします。正しくない: 機能アドバタイズには通知を使用しないでください。

ガイドライン

全般

使用状況に基づいて通知パターンを選択します。 各使用パターンの説明については、前の表を参照してください。
最初の Windows エクスペリエンスでは、通知を使用しないでください。 最初のエクスペリエンスを向上させるために、Windows 7 では、最初の数時間の使用中に表示されるすべての通知が抑制されます。ユーザーにこのような通知が表示されない場合を想定して、プログラムを設計します。

通知する内容

次の状況を除き、正常な操作を通知しないでください。
- セキュリティ。 ユーザーは、セキュリティ操作が最も重要であると考えているので、セキュリティ操作が成功したことをユーザーに通知します。
- 最近のエラー。 ユーザーは、直前に失敗した場合に成功した操作を当然受け取らないので、操作が最近失敗したときに成功したことをユーザーに通知します。
- 不便を防ぎます。 これを行うときに正常な操作を報告すると、ユーザーの不適合が回避される可能性があります。そのため、操作が長い場合や、予期したよりも前または後に完了した場合など、予期しない方法で正常な操作が実行されたときにユーザーに通知します。
他の状況では、成功のためのフィードバックを提供しないか、フィードバックを "オンデマンド" で提供します。 ユーザーが正常な操作を受け取ることを前提としています。操作の実行中に通知領域にアイコンを表示 (または既存のアイコンを変更) し、操作が完了したときにアイコンを削除 (または前のアイコンを復元) することで、必要に応じてフィードバックを送信できます。
FYI パターンでは、 ユーザーが引き続き正常に作業できる場合、または通知の結果として何か異なる操作を行う可能性が低い場合は、通知を行わないでください。

正しくない:

この例では、この情報は、ユーザーが既にポートをインストールしている場合にのみ役立ちます。それ以外の場合、ユーザーは、その結果として何も異なる操作を行う可能性はありません。
- 例外: オプションであり、ユーザーがオプトインする場合は、疑わしい関連性の情報をユーザーに通知できます。
  
  正確:
  
  この例では、ユーザーは連絡先がオンラインになったときに通知を受け取り、このオプションの情報を受け取ります。
重要でないシステムイベントと FYI パターンの場合は、 1 つのイベントに対して完全な通知を使用します。 部分的なものを複数提示しないでください。

正しくない:

これらの例では、ユーザーが特定の USB キーボードを接続したときに Windows XP によって表示された 8 つの通知のうち 4 つだけを示し、それぞれが段階的に詳細情報を表示します。

正確:

この例では、USB キーボードを接続すると、2 つの完全な通知が表示されます。

通知するタイミング

デザインパターンに基づいて通知を表示します。

Pattern	通知するタイミング
アクションの成功	非同期タスクの完了時。完了を待機している可能性がある場合、または最近のエラーの後にのみ、成功したアクションをユーザーに通知します。
アクションの失敗	非同期タスクが失敗した場合。
重要でないシステムイベント	イベントが発生し、ユーザーがアクティブな場合、または条件が引き続き存在する場合。問題が発生した場合は、問題が解決したら、すぐに現在表示されている通知を削除します。
省略可能なユーザータスク	タスクを実行する必要性が特定され、ユーザーがアクティブな場合。
Fyi	トリガーイベントが発生したとき。

アクションエラーパターンの場合、 問題が数秒で問題自体を修正する可能性がある場合は、適切な時間、エラー通知を遅延させます。 問題が解決した場合は、何も報告しません。十分な時間が経過した後にのみ、エラーが顕著であることを通知します。レポートが早すぎると、報告された問題に気付かない可能性が高くなりますが、不要な通知が表示されます。

正しくない:

ネットワーク接続なし通知のスクリーンショット

直後に次の値が続く場合:

接続成功通知のスクリーンショット

この例では、Windows Vista では、ワイヤレス接続がないという通知は、多くの場合、すぐに良好な接続の通知が続くため、早期です。

アクションの成功と FYI パターンの場合は、 リアルタイムオプションを使用 して、ユーザーが全画面表示アプリケーションを実行しているとき、またはコンピューターをアクティブに使用していないときに古い通知がキューに登録されないようにします。
重要でないシステムイベントパターンの場合は、 ユーザーログオンなどの既知のイベントに関連付けられているイベントをずらすため、通知ストームの可能性を作成しないでください。 代わりに、イベントをイベントの後の期間に結び付けます。たとえば、ユーザーがログオンしてから 5 分後に製品を登録するようユーザーに通知できます。

通知する期間

Windows Vista 以降では、9 秒間の固定期間の通知が表示されます。

通知する頻度

通知を表示する回数は、そのデザインパターンに基づいています。

Pattern	通知する頻度
アクションの成功	1 回のみ
アクションの失敗	1 回のみ
重要でないシステムイベント	イベントが最初に発生したときに 1 回。ユーザーが解決する必要がある問題が原因である場合は、1 日に 1 回再表示します。
省略可能なユーザータスク	1 日に 1 回、最大 3 回。
Fyi	1 回のみ

省略可能なユーザータスクの場合は、常に通知を表示してユーザーを提出するようにしないでください。 タスクが必要な場合は、通知を使用するのではなく、すぐにモーダルダイアログボックスを表示します。

通知のエスカレーション

ユーザーに通知が表示されると想定しないでください。 次の場合、ユーザーには表示されません。
- 彼らは彼らの仕事に浸っている。
- 彼らは注意を払っていません。
- コンピューターから離れています。
- 全画面表示アプリケーションを実行しています。
- 管理者がコンピューターのすべての通知をオフにしました。
ユーザーが最終的に何らかのアクションを実行する必要がある場合は、プログレッシブエスカレーションを使用して、 ユーザーが無視できない代替 UI を表示します。

相互作用

次の場合に通知をクリックできるようにします。
- ユーザーはアクションを実行する必要があります。 通知をクリックすると、ユーザーがアクションを実行できるウィンドウが表示されます。この方法は、アクションエラーとオプションのユーザータスク設計パターンに適しています。
- ユーザーは、詳細を表示する必要がある場合があります。 通知をクリックすると、ユーザーが追加情報を表示できるウィンドウが表示されます。
ユーザーがクリックしてアクションを実行すると、常にウィンドウが表示されます。 [アクションを直接実行する] をクリックする必要はありません。
クリックして詳細情報を表示すると、常に詳細情報が表示されます。 通知に既に含まれている情報を言い換えないでください。

アイコン

アクションの失敗パターンには、標準エラーアイコンを使用します。
重要でないシステムイベントパターンの場合は、標準の警告アイコンを使用します。
その他のパターンでは、セキュリティ用のシールドや電源用バッテリーなど、件名に関連するオブジェクトや提案されるオブジェクトを示すアイコンを使用します。
ターゲットユーザーがアイコンを認識し、より優れた代替手段がない場合は、アプリケーションまたは会社のブランドに基づいてアイコンを使用します。
段階的なエスカレーションの場合は、 状況がより緊急になるにつれて、徐々に強調された外観のアイコンを使用することを検討してください。
標準情報アイコンは使用しないでください。 その通知は言うまでもなく情報です。
次の場合は、大きなアイコン (32 x 32 ピクセル) を使用することを検討してください。
- ユーザーは、テキストではなくアイコンをすばやく理解します。
- 大きなアイコンは、標準の 16 x 16 ピクセルアイコンよりも明確かつ効果的に意味を伝えます。
- アイコンは Aero スタイルを使用します。

この例では、ユーザーは大きなアイコンを一目で確認して、通知の性質をすばやく理解できます。

通知キュー

メモ： 通知は、別の通知が表示されている場合、ユーザーが全画面表示アプリケーションを実行しているとき、またはユーザーがコンピューターをアクティブに使用していない場合など、すぐに表示できない場合は常にキューに登録されます。リアルタイム通知は 60 秒間だけキューに残ります。

アクションの成功と FYI パターンの場合は、通知が 長時間キューに登録されないように、リアルタイムオプションを使用します。これらの通知には、すぐに表示できる場合にのみ値があります。
キューに登録された通知が関連しなくなったら削除します。
開発者： これを行うには、uFlags で NIF_INFO フラグを設定し、szInfo を空の文字列に設定します。通知がキューに存在しなくなった場合は、この操作に害はありません。

システム統合

実行中にアプリケーションの通知領域にアイコンが常に表示されない場合は、 通知の原因となった非同期タスクまたはイベント中に一時的にアイコンを表示します。

Text

タイトルテキスト

わかりやすい簡潔な特定の言語でユーザーに伝えるために必要な最も重要な情報を簡単に要約したタイトルテキストを使用します。 ユーザーは、通知情報の目的をすばやく最小限の労力で理解できる必要があります。
句読点を終了せずに、テキストフラグメントまたは完全な文を使用します。
文章スタイルで大文字と小文字を使い分けます。
ローカライズに対応するには、48 文字以内 (英語) を使用してください。 タイトルの最大長は 63 文字ですが、英語のテキストを翻訳する場合は 30% の拡張を許可する必要があります。

本文

(タイトルの情報を繰り返さずに) 説明を提供する本文テキストを使用し、必要に応じて通知に関する特定の詳細を提供し、ユーザーが使用可能なアクションを知ることもできます。
終了句読点で完全な文を使用します。
文章スタイルで大文字と小文字を使い分けます。
ローカライズに対応するには、200 文字以内 (英語) を使用してください。 本文テキストの最大長は 255 文字ですが、英語のテキストを翻訳する場合は 30% の拡張を許可する必要があります。
本文テキストに、特定のオブジェクト名などの重要な情報を含めます。 (例: ユーザー名、ファイル名、または URL)。ユーザーは、このような情報を見つけるために別のウィンドウを開く必要はありません。
オブジェクト名を二重引用符で囲みます。
- 例外： 次の場合は引用符を使用しないでください。
  - オブジェクト名では、ユーザー名などのタイトルスタイルの大文字が常に使用されます。
  - オブジェクト名はコロンでオフセットされます (例: プリンター名: マイプリンター)。
  - オブジェクト名は、コンテキストから簡単に決定できます。
ローカライズに対応するためにオブジェクト名を固定の最大サイズに切り捨てる必要がある場合は、省略記号を使用して切り捨てを示します。

この例では、省略記号を使用してオブジェクト名が切り捨てられます。
通知が実行可能な場合は、次の言い回しを使用します。
- ユーザーが通知をクリックしてアクションを実行できる場合:
  
  < 重要な情報の簡単な説明>
  
  <省略可能な詳細>
  
  クリックして <何かを>行います。
  
  この例では、ユーザーはクリックしてアクションを実行できます。
- ユーザーが通知をクリックして詳細を表示できる場合:
  
  < 重要な情報の簡単な説明>
  
  <省略可能な詳細>
  
  詳細については、こちらをクリックしてください。
  
  この例では、ユーザーがクリックして詳細を確認できます。
ユーザーが通知でアクションを実行する必要があるとは言いません。 通知は、ユーザーが自由に無視できる重要でない情報を対象とします。ユーザーが実際にアクションを実行する必要がある場合は、通知を使用しないでください。
ユーザーがアクションを実行する必要がある場合は、重要度を明確にします。
アクションの失敗と重要でないシステムイベントパターンについては、 問題を平易な言語で記述します。

正しくない:

この例では、過度に技術的で、まだ指定されていない言語を使用して問題について説明します。

正確:

この例では、問題は平易な言語で記述されています。
ターゲットユーザーに関連する方法でイベントを記述します。 通知は、ユーザーがタスクを実行したり、通知の結果として動作を変更したりする可能性が妥当な場合に関連します。多くの場合、技術的な問題ではなく、ユーザーの目標に関する通知を記述することでこれを実現できます。

ドキュメント

通知を参照する場合:

大文字と小文字を含む正確なタイトルテキストを使用します。
コンポーネントは、バルーンやアラートとしてではなく、通知として参照します。
ユーザーの操作を説明するには、クリックを使用します。
可能な場合は、太字のテキストを使用してタイトルテキストの書式を設定します。それ以外の場合は、混乱を防ぐために必要な場合にのみ、タイトルを引用符で囲みます。

例: [重大な更新プログラムをインストールする準備ができました ] という通知が表示されたら、通知をクリックしてプロセスを開始します。

通知領域を参照する場合:

通知領域は、システムトレイではなく通知領域として参照してください。

次の方法で共有