目に見える変更の確認メッセージは必要ですか？
ほとんどの場合、ステータスメッセージをユーザーに提供することは良いことです。 （例：「顧客が追加されました」または「データが保存されました。」）しかし、私は今、本当にそのようなメッセージを常に伝えるべきかどうかを自問しています。特にこれらの2つのケースについては、変更が非常に目に見えるという事実を与えることが有用であるかどうかわかりません。
- ウェブサイト/アプリケーションの言語を変更する
- ウェブサイトのテーマ/デザインを変更する
これについてどう思いますか？常に確認/ステータスメッセージを提供しますか？または、メッセージを印刷しない他の状況がありますか？
（ほとんど）常に変更に関するフィードバックを表示する必要があります。テーマの変更のように明らかな場合でも、ユーザーが選択したテーマの名前をユーザーに伝えるのは良いことです。間違って間違ったものを選択した。
explicit確認メッセージを表示する必要はありません。たとえば、多くのWebサイトでは、ログインしても確認メッセージは表示されません。右上隅に名前が表示されるだけです（「ベネットとしてログイン」など）。グレンの例では、New Foo画面に移動すると、Fooの作成が成功したことが暗黙的に確認されます。
他の人が述べたように、メッセージは一般にモーダルというよりも目立たなくする必要があります。コメントとバッジに関するUXExchangeの通知が良い例です。それらはそこにあり、明白ですが、ユーザーはそれらを確認するためのアクションを実行する必要はありません。
私は実際にはほとんどの場合、特にモーダル形式で確認メッセージを避けています。ユーザーが「OK」と言わなければならないことは、あまり価値がなく、とにかくメッセージを読みません。
「[foo]を作成」した場合は、ユーザーを新しい[foo]の最初の画面に移動して、作業を開始させます。メッセージは必要ありません。
データの保存は、ユーザーが操作する必要のないステータスメッセージのように、邪魔にならないメッセージである可能性があります。
一般的に、答えは次のとおりです。ユーザーがすでに知っていることをユーザーに話さないでください。彼らが次に必要とするものを先に進めるだけです。
また、意図されたユーザーが誰であるかに依存します。私は古い人口統計を持ついくつかのサイトで作業しており、テストは彼らが彼らの行動の非常に明示的な肯定を好むことを数回示しました。
ユーザーが自分の能力に確信が持てないほど、ユーザーはより安心する必要があります。
成功した操作を伝えるためのメカニズムはいくつかあります。
アクションの結果、まったく新しい画面が表示される場合（たとえば、[作成]をクリックすると編集画面が表示される）、何も言う必要はありません。
アクションによって同じ画面にとどまり、その画面上のスペースが更新される場合は、 Change Spotlight デザインパターンを使用します。
アクションの結果として要素が追加または削除される場合は、 Self Healing Transition も使用します。
アクションが表示されている画面にまったくまたは最小限の影響しか及ぼさない場合は、 Status Blip を使用できます（Googleアプリで何かを実行すると、画面の上部に一時的に表示される小さな黄色の浮遊状態のメモ） 。
いくつかの確認応答が連続している可能性があり、ユーザーにそれらを一瞬ではなく表示したい場合は、 Notification Bars を使用します。
通知がたくさんある場合は、ページに通知を蓄積してスクロールする専用のスペースを用意できます。ログウィンドウのようなものです。
最後に、操作の結果、ユーザーが必要とする追加情報（受付番号など）が表示される場合は、この確認を明示的な Modal Overlay で提供する方が適切です。
私は可能な限り、明示的なメッセージを避け（ユーザーが2度目にしたメッセージを無視する可能性が高いです）、状況に応じた手がかりを利用すること、つまり：
アプリケーションが非同期の場合、タスクが実行されていることを視覚的に示し、完了したらインジケーターを削除します。失敗した場合はエラーを表示します。
微妙な視覚的手掛かりを使用して、変更されたものに注意を引きます。つまり、タスク/アクションの結果が画面に何かが追加された場合（つまり、テーブルに追加された新しいユーザー）、一時的なフェードハイライトを使用して注意を引きます。または、それが削除されている場合は、フェードアウトします（その場所を埋めるために何かを上下にシフトします）。
Glen Lipkaがすでに提案したように、最も一般的な使用例は、前のアクションから生じたものに対してさらにアクションを実行する場合（たとえば、ユーザーの詳細/権限などを編集する場合）、ユーザーをその画面/状態/等.
言語とテーマの変更の2つの例では、変更is確認です。確認メッセージは、システムのアクティビティが不透明または見落としやすい場所に役立ちます。言語やテーマが変更された場合、誰かが変更が起こったかどうかについてすぐに手がかりをつけるでしょう。そのため、これらの確認メッセージはありません。
それを超えて、一般的なルールに向けて、私はここで何が問題になっているのかを考えるここでの提案とアプリの聴衆を組み合わせると、すべてではないにしてもほとんどの場合に適切な決定に導くと思います。
ええ、それは何が問題になっているのかにも依存します。アクションは一般に「ハイステークス」または「ローステーク」として識別できます。
'High Stake' =これが機能しないが、機能していると思う場合、私はイライラする/ねじ込まれる。 「低い利害関係」=これがうまくいかない場合でも、誰も気にかけません。
あなたが挙げた例は、リスクが低いと考えます。
しかし、購入が行われているようなハイステークスのケースでは、メッセージを表示する必要がありますが、Glenが指摘しているように、ユーザーは必ずしも対話を強制されるべきではありません。
はいといいえをお勧めします。私自身の経験以外にこれを裏付ける証拠は証明されていませんが、変更が容易に見える場合は、ユーザーに明白なメッセージを送信する必要はありません。ただし、すべてのルールには例外があります。変更が行われていて、ユーザーだけがそれを見ることができない場合は、はい、確認メッセージを表示することをお勧めします。これの背後にある私の推論は、アクセシビリティです。ただし、スクリーンリーダーやテキストブラウザーなどを使用している場合は、ユーザー自身が変更を確認できない場合があります。確認メッセージを表示または読み取ることができ、ユーザーは変更が保存されたことを知っています。
結論として、それは何かのように、状況に依存します。ベストプラクティスは一貫しており、常に確認メッセージを表示することですが、状況はそれぞれ異なります。たとえば、小さな画面用に設計する場合。
お役に立てれば。
まあ、インターネット経由でダウンロードされるデスクトップアプリケーション（特にエンドユーザー製品）での私の経験によれば、これらのソフトウェアは、技術に詳しい人から、ニーズを満たしたいだけのホームユーザーまで、誰でも使用されます。実際に何をしているのか、または実際に行った変更を認識していない人に出くわすこともあります。そのため、確認メッセージ、警告メッセージ、成功メッセージを表示することは常に良いことです。誰かが自分のパスワードを変更したが、最終的にメッセージがまったく届かなかったとしましょう。彼は自分のパスワードが実際に変更されたことを知ることはなく、次回も同じ古いパスワードを使用する可能性があります。