削除確認メッセージの色は何色ですか?
これは質問'yes、delete it'は赤か緑か?に関連していますが、この質問は受動的な確認メッセージについて尋ねるので異なります。アクティブな削除ボタンではありません。
一般的な成功色である緑と言うかもしれませんが、削除ボタンは赤で、奇妙に見えます。メッセージを赤にしても、何かを削除しただけでは意味がありません。赤はエラーを想定しているためです。
私の特定のケースでは、提案を拒否または受け入れることです。オプションは次のとおりです。
(成功)
(危険)
(警告)
(情報)
rejected を太字にすると、 rejected と accepted の違いがより強調されます。また、テキストを「成功提案を拒否しました」に変更することもできます。これにより、色に関係なく実際のアクションがより強調されます。
色を使わず、灰色の背景に黒いテキストを使用すると、奇妙に見えます。もう通知のようには見えないので、私はそれをオプションとは考えていません。
最後に、プロポーザルはプロポーザルのリストから削除されるため、誰かがメッセージをまったく表示しないよう提案しました。その人によると、その削除自体は十分なフィードバックであるはずです。でも個人的には同意しません。変な感じです。
全体として、私は緑または青に傾いています(成功または情報)。赤いメッセージはある種の失敗であるべきであり、黄色の警告はまた、私が取るべき追加のアクションがあるように感じさせます。緑は拒否のようには見えず(拒否ボタンは赤、承認ボタンは緑)、青も何らかの理由で外れています。
どのオプションを使用する必要がありますか?
これは、UXとの混乱の共通点です。次の2つのメッセージを検討してください。
Sorry, the app has crashed
-これはエラーであり、エラーとして強調表示する必要があります(つまり、ポップアップアラート、ダイアログ、赤いボタンなど)。You have rejected a date with Kate Upton
-これはエラーのように聞こえますが、エラーではありません。これは、否定的な選択を示す確認通知です。あなたの状況では、プロポーザルの拒否の確認はエラーではなく、通知です。
これが通知であることがわかったので、色とレイアウトの選択はアプリ/サイトの他の通知に準拠する必要があります。
したがって、肯定的な(承認された提案)通知がどのように見えるかを確認せずに色の選択の質問に答えることは不可能です。
通知のペアがあるとします:Proposal accepted
およびProposal rejected
。
通知の具体的な色、形、アニメーションはアプリのレイアウトとカラーパレットによって異なりますが、どちらの通知も明確に同じ種として認識されるように、承認と拒否で一貫している必要があります。
この場合は、確認メッセージの色を変更することをお勧めします。
特に「拒否」と「承認」に赤と緑を使用しているため、ユーザーが混乱する可能性があるので、赤から緑に移動するアクションが正常に行われないと、方向感覚が失われ、価値のない余分な認知的オーバーフローになる可能性があります。
彼らがスナックバーやトーストと呼んでいるものを使って、Googleがどのようにやっているかを見てみましょう。
あなたが言ったように色を取り除き、「成功」のような言語を使用することによって、それは特定の色に関連付けられたメンタルモデルについてではなく、メッセージについてより多くなります。
編集:
ダニエルが非常に類似した解決策で答えたのを見たことがあります!
他のメッセージがある場合は、作成したパターンに従う必要があります。
したがって、これがアクションの正常な完了と見なされ、成功した他のすべてのアクションが緑のメッセージを受け取る場合、これは緑のメッセージを受け取る必要があります。
灰色の背景に白のテキストを使用すると、非常にニュートラルな感触が得られ、目にも似合います。良くも悪くもない限り、私は緑や赤を避けます。
メッセージは成功したアクションを示しているため、カラーキューを使用している場合、このメッセージは成功の色を使用する必要があります:緑色の場合。危険色(この例では赤)は、ユーザーがやろうとしている破壊的なもの(たとえば、「本当に削除してもよろしいですか?」これですか?」)、しかし、あなたが尋ねているメッセージは、ユーザーがすでにそれを完了したときです。 危険が過ぎたので、危険がまだ存在していることを示す可能性のあるカラーキューを使用しないでください。もちろん、状況が他の理由で危険でない限り。
すでに色から離れることを促す良い答えがいくつかあります。私は彼らに同意します。色覚異常/文化的関係を考慮して、色は常に情報を伝える二次モードとして使用する必要があります。しかし、繰り返しになりますが、成功のアラートがすでにあるアプリケーションで作業している場合、カラーキューを使用している失敗は、一貫性を保つ必要があります。
そのシナリオでは、すべての成功が表示される色に固執しますです。ユーザーアクションの確認です。情報、成功の目盛り、間違った十字架、またはその他の該当するものの適切な記号でメッセージを補強します。
さらに、赤を使用すると、アプリケーション全体でエラーが発生したと想定して、ユーザーからの応答をすばやく開始します。彼/彼女は、彼/彼女が遭遇した/作ったはずのエラーを修正する方法を期待しています。この場合、エラーは発生しないため、誤警報になります。 一貫性がなく、プログラムで意図的に誤ったアラームを作成するシステムを作成したくない。これは、他のエラーメッセージにも影響します。ユーザーは、否定的な確認と実際のエラーとを区別するために処理するいくつかの知的負荷があります。
さらに、拒否または否定的であると想定している場合、アクションの削除は本質的に危険/悪いことなどです。これは明らかにそうではない場合があります。正常とは異なるエラーメッセージは、ユーザーが実行したアクションが何らかの理由で不適切に考慮されているような印象を与えます。あなたはそれをしたくないでしょう。
色を消す答えは、メッセージにとらわれない方法でそれを示します。通知とアラートはコンテンツによって異なりません。これらは本質的により一般的であり、基本的に操作の成功または失敗を示します。