エラーメッセージは謝罪する必要がありますか？
「申し訳ありませんが、この機能にアクセスする権限がありません。管理者に連絡してください。」というエラーメッセージについてチームで話し合っています。
この場合、「謝罪」の言葉を使うことは適切ですか？それに対する論理的根拠は、ダウンタイムなどのアプリケーションの「障害」のみと見なされるものについては「謝罪する」ことがより適切であろうということです。 （「申し訳ありませんが、当サイトは現在ご利用いただけません...しばらくしてからもう一度お試しください。」）
申し訳なさそうな口調をとることが重要であると私が考える理由は、間違いがあり、この場合、ユーザーがマシンまたはアプリケーションとやり取りしているにもかかわらず、ユーザーの行動を尊重し、人間化していることをユーザーに伝えることです。間違い。
これを引用するには XMattersの記事 ：
「エラーメッセージを人に表示するので、エラーメッセージを人に直接伝える場合に使用するような口調で書いてください。」
また、この優れた記事もご覧になることをお勧めします Webフォームで「はい」と言っていたときに「いいえ」と言っていませんか？ ：
エラーメッセージは、ユーザーエクスペリエンスを作成する上で重要ではなく、非常に退屈な部分のようです。ただし、エラーメッセージの調性により、エクスペリエンスがほぼ一定の放棄からコンバージョンに変わる可能性があります。
この記事では、エラーメッセージはポジティブなトーンを伝える必要があることを強調しているため、謝罪の応答は、ユーザーが迅速に回復し、自分が犯した可能性のある間違いについてすぐに防御的にならないようにするのに役立ちます。
肯定的な口調を伝えるエラーメッセージを書くことはロケット科学ではありません。いくつかの簡単なルールに従ってください：
まず、「互換性なし」などの技術用語を取り除きます。ほとんどのユーザーはこれが何を意味するのか知りません。開発者の言語ではなく、母国語で話しかけてください。たとえば、「互換性なし」はプレーンな英語では「一緒に機能しない」という意味です。
否定的な言葉を使わない
ユーザーが何を修正すべきかがわかるように、エラーを明確に識別します。
問題を解決する方法のヒントをユーザーに提供します。
ユーザーではなく自分のせいにします。
また、謝罪のエラーメッセージを使用することによるユーザーの気分状態への影響と人間の方法を分析した研究について、 謝罪エラーメッセージと気分状態がコンピューターユーザーのパフォーマンスの自己評価に及ぼす影響 を調べることをお勧めします。謝罪のような音は、コンピュータのインターフェースで効果的です。記事からの抜粋を引用するには
HHIでは、謝罪は一般的に後悔を表すために使用されます（Leech、1983; Schlenker andDarby、1981）、または他者の行動の不承認によって引き起こされる個人の怒りを緩和するために使用されます。 、Nielsen（1998）は、エラーの理由が目的のタスクを実行するためのコンピューターインターフェイスの制限である場合、コンピューターユーザーのアクションに応答するエラーメッセージには単純な謝罪文を含める必要があると主張しています。 Tzeng（2006）は、3つの異なるエラーメッセージを含むオンラインシステムに対するユーザーの認識を調査する調査を行いました。それぞれに異なる礼儀正しさの戦略が含まれています。この調査では、最初にユーザーの丁寧な方向性が導き出され、その後、参加者は、所定の問題を含むWebサイトと対話するように求められました。ユーザーが問題に遭遇すると、システムは1つの肯定的な丁寧な戦略（つまり、冗談）、1つの否定的な丁寧な戦略（つまり、単純な謝罪）、およびエラーに対する機械的なメッセージ（つまり、ページが一時的に利用不可になる）を表す特定のエラーメッセージを提供しました。調査の結果、丁寧な表現で社交イベントを扱うユーザーは、機械的なメッセージや冗談のメッセージよりも謝罪メッセージを大幅に受け取ることを好み、礼儀正しい表現に向いていないメッセージよりも謝罪メッセージをはるかに好むことがわかりました。
記事 は、否定的なトーンとは対照的に、謝罪のトーンがユーザー自身の認識にどのように影響するか、肯定的な謝罪の認識が肯定的なパフォーマンスの向上にどのように役立つかについても述べています。
De Laere、Lundgren、およびHowe（1998）は、コンピュータインターフェイスの人間のような相互作用スタイルと機械のような相互作用スタイルを比較しました。彼らは、ユーザーの自己評価に関して、異なるスタイル間の有意差を観察しませんでした。調査の結果は、負のフィードバックが参加者の自己認識に正のフィードバックとは異なる影響を与えることも示しました。
Tzeng（2004）は、謝罪のフィードバックがコンピューター化された環境でのユーザーのパフォーマンスの知覚に影響を与えるかどうかを調査しました。この研究は、ユーザーがコンピューターが礼儀正しくあることを期待しないかもしれないことを示唆しましたが、謝罪の声明は、プログラムとの相互作用について被験者に気分を良くさせました。
研究論文 コンピューター謝罪：謝罪のフィードバックがコンピューター環境のユーザーに与える影響 謝罪の否定的なフィードバックが社会的側面からユーザーエクスペリエンスに結びつく理由
エラーメッセージを伴う謝罪文の使用は、人間とコンピュータの相互作用に貢献します。ユーザー中心のデザインの主な目的が、ユーザーが快適に過ごせる環境を作ることだと考えると、ユーザーインターフェイスデザインでの謝辞の使用は非常に重要な問題になります。さらに、人間と人間の相互作用において、最も重要で最も重要なことの1つは、敬意をもって行動することです。人が礼儀正しく振る舞わなかったり、他の人に対して誤りを犯したりする社会のほとんどでは、謝罪は問題を克服するための伝統的かつ最も効果的な方法です。同様に、この研究は、ほとんどの被験者が謝罪のフィードバックは不快に思われないと考え、謝罪のフィードバックを受けた被験者の95％は、謝罪のフィードバックが彼らに敏感であると感じたと示しています。ここでは、コンピュータの無力に起因するエラーに遭遇したときに、人間の相互作用に問題が発生したかのように、謝罪などの敬意を表する行動に直面することが興味深いようです。この研究の調査結果は、人間が感性、尊敬、人間性の感情などのインターフェースの感情的な側面を見るのに共感しているため、インターフェース設計で個人の感情状態を表現することは、人間とコンピュータの相互作用において非常に重要であることを示しています。したがって、これらの結果は、コンピューターがユーザーに謝罪文を提供することで、実際のユーザー中心のデザインのアイデアを実証できるという主張の証拠として使用される可能性があります。
反対に Microsoftが推奨深刻なエラーが発生した場合にのみ、申し訳ありませんまたは謝罪の言葉を使用します。
「sorry」という単語は、ユーザーにとって深刻な問題（データの損失やコンピューターの使用不能など）を引き起こすエラーメッセージでのみ使用してください。問題がプログラムの通常の機能中に発生した場合は謝罪しないでください（たとえば、ユーザーがネットワーク接続が見つかるのを待つ必要がある場合）。
マービンの答えは素晴らしいですが、私はそれが「許容できる」または「好ましい」と言っているだけではありません。謝罪の口調を使用する必要があるのは、1つの非常に正当な理由があります。ユーザーがミスを犯している場合、それはユーザーがシステムのルールやロジックを理解していないためです。それはユーザーの責任ではありません！システムのロジックをユーザーに正確に説明するのはシステムの責任です。ユーザーエラーは、ユーザーが実行する必要があると考えていることと、システムが実行できることとの不一致です。
この言葉のようなものは決してないでしょうが、すべてを綴ると、謝罪のエラーメッセージは次のようになります。 "他の同様のプログラムは、あなたが現時点でそのような行動をとることができると信じるように導きましたが、あなたがそうすることができないので.... "
上記のケースに固有：ユーザーはアクセスが可能である可能性があると考えました。システムが以前に許可が利用できないことを通知していなかったため、ユーザーが持っていた誤解をお詫びします。
エラーがユーザーの責任である可能性があるとはどういう意味ですか？ユーザーは、knowが機能しない（自分の時間を浪費する）ことをしないでください。彼らが何か間違ったことをする唯一の理由は、彼らがそれが機能しないことを知らないからです。ユーザーが何かを知らないのであれば、これを透過的にしないのはシステムのせいではないでしょうか。プログラマーがそれをどれほど明白であると考えているかに関係なく、ほとんどの場合、間違いはシステムの障害です。したがって、エラーメッセージを適切に記述してください。そうすれば、ユーザーはより幸せになります。
一歩後戻り：そもそもなぜこの機能がユーザーに利用可能（可視）になったのですか？
特定のユーザー（またはユーザークラス）が使用できない機能である場合は、非表示にします。
それがあなたがアップセルしたいプレミアム機能であるならば、そうしてください。
履歴のエクスポートはデータをバックアップする優れた方法ですが、プレミアムアカウントでのみ使用できます。管理者に連絡して、アカウントをプレミアムにアップグレードするよう依頼してください。
ダウンタイムまたはエラー（責任がアプリケーションのみにある場合）に関して、私は口調が次のことを知ることに次ぐものであると感じています。
問題はログに記録されており、暖かい体がどこかに問題があることを認識している。
私が連絡できる人がいます。
私はもう一度試すことができます。
何かがひどく間違っていました！
エラーを記録しました。
もう一度お試しいただくか、help @ application.comにご連絡ください。できるだけ早くご連絡いたします。
コンピュータからの人間味のある謝罪は見つけられません。電話ネットワークの自動保留システムにすぎないため、「あなたの通話は私たちにとって非常に重要です。電話をつないでください。次に利用できる担当者。」
謝罪はここでの主な問題ではないと思います。はるかに重要なことは、ユーザーがそれらを圧倒することなく問題を解決できるように十分に明確であることです。
適切なエラーメッセージには、問題の原因と修正方法が正確に記載されています。また、完全に理解可能であり、ユーザーが理解できない専門用語を使用してユーザーにストレスを与えることはありません。
もちろん、これらの2つの目標は互いに矛盾します。 47行目でカーネルのディスコンボリューション中に致命的な例外が発生し、ログに記録されたメモリダンプがあることをユーザーに伝えることは、開発者にとって非常に役立ちますが、ユーザーにとって完全に失われ、エラー自体よりもユーザーにストレスをもたらします。それでも、「申し訳ありません。私はめちゃくちゃになりました。それについて申し訳ありません！」というエラーメッセージが表示されるのは、それほど面倒ではありません。ユーザーとして、何がうまくいかなかったのかをどのようにして知ることができますか？どうすれば問題を解決し始めることができますか？
それは、ユーザーに配慮した妥協に帰着します（おそらくパワーユーザーですか？それは事実ですか？英語が第一言語ですか？など）。
私は、ユーザーが自分自身にもたらした間違いに対する謝罪の綿毛と乱雑さを避け、代わりにそれを解決する方法を完全に明確にすることにより、ユーザーを本当に思いやりのあるエラーメッセージを書くことが望ましいと思います。
はい、エラーメッセージはそれがもっともらしいときに謝罪する必要があります。 人々は人間の感情をコンピュータに帰する なので、コンピュータは、特に人々が礼儀正しくなることを期待するユーザにとって、礼儀正しくなければなりません。
たとえば、高齢者向けに設計されたウェブサイトは、非常に丁寧なメッセージの両方から恩恵を受けるでしょう。
- ユーザーではなくサイトに問題があることを示す
- これらのユーザーの社会的期待に合わせるため。 （私は、高齢者は通常の人と人との社会的相互作用で礼儀正しさを期待する可能性が高いと仮定しています。）
「 ヒューマンコンピュータインタラクションに影響を与える 」という章には、謝罪のフィードバックに関するセクションがあります（私の強調）：
Nielsen（1998）は、ユーザーが問題に遭遇し、エラーメッセージを受け取った場合、エラーの原因はインターフェースの制限であることを示す簡単な謝罪文を含める必要があると主張しましたユーザーのアクションではなく、目的のタスクに対してコマンドを実行します。 [...]
Tzeng（2004）は、謝罪のフィードバックグループの被験者は、彼らのパフォーマンスと能力を、非謝罪グループの被験者よりもよく知覚していないことを示しました。彼はさらに、コンピュータユーザーはコンピュータが礼儀正しいとは期待しないかもしれないことを示しました。それでも謝罪の声明は、被験者にプログラムとの相互作用について気分を良くさせます。 Tzeng（2006）は、参加者の礼儀正しさの向きが謝罪のコンピューターエラーメッセージの認識に影響を与える可能性があるという考えに基づいて、3つの異なるエラーメッセージを含むオンラインシステムに関するユーザーの認識を調査する別の調査を実施しました。彼はユーザーの丁寧な方向性を引き出し、それぞれに所定の問題が含まれるWebサイトと対話するようにユーザーに求めました。問題が発生すると、ユーザーには3つの異なる丁寧な戦略を表す特定のエラーメッセージが提供されます。それは、肯定的な丁寧な戦略（つまり、冗談）、否定的な丁寧な戦略（つまり、単純な謝罪）、およびエラーの機械的なメッセージ（つまり、ページは一時的です）です。利用できません）。調査結果によると、ソーシャルイベントを処理するときに丁寧な表現を使用するユーザーは、他の機械的メッセージやジョークメッセージや礼儀正しさにあまり向いていない他のユーザーよりも、謝罪メッセージを大幅に好むことがわかりました。式。
エラーメッセージのムードに対するユーザーの反応は、自分のムードに依存する であるという証拠もあります。ユーザーがどのような気分かを知っている場合は、それを使用して、代わりにエラーフィードバックを構造化できます。
人間が他の人間と話しているような平易な言葉でメッセージを書くと、これは煩わしいかもしれません 。エラーの原因がユーザー（アプリ、サーバーなど）の場合は謝罪を追加し、それ以外の場合は、事実と問題の解決方法を明記してください。
例えば：
- 「サーバーに問題があるため、メッセージを送信できませんでした。もう一度やり直してください。」
- 「メッセージを送信できませんでした。メールフィールドに入力してください。」
別のもの：
- 「申し訳ありませんが、この機能にアクセスする権限がありません。残高が少なく、プランをダウングレードしました。」
- 「この機能へのアクセス権がありません。これは拡張プランでのみ利用できます。」
メッセージからこれらすべての「申し訳ありません」を削除すると、短くなります。つまり、ユーザーは問題をより早く読み、解決できます。明確な指示を与えれば、問題は簡単に修正できます。謝罪の必要はありません。
ほとんどの場合、2つの経験則を適用できると思います。
ユーザーがミスを犯した場合、そのミスを謝罪しないでください。むしろ、次または将来の問題を回避/修正する方法を指示します。可能/該当する場合はヘルプリソースを提供します.
問題がプログラムによって引き起こされた場合、ご迷惑をおかけして申し訳ありませんが、実際に何が起こるか、次に何が起こるか、修正するために何ができるかをユーザーに通知することがより重要です問題の修正を支援する機会を提供します（つまり、エラーレポートを発行します）。
ソフトウェアには感情やエゴはありませんが、人々は持っています。たとえば、AMEXの販売者のPBXを使用しているときに間違いを犯した場合、システムは「申し訳ありませんが、私の間違い」と心地よい人間の声で言います。これは一部の人にとってはひいきのように見えるかもしれませんが、人間味を帯びており、私の意見では非常に賢いです。
統制しすぎたり、意地悪をしたりするのではなく、謝罪しすぎる側に誤りを犯す方がよい（たとえば、「数値を入力してください。人間はしばしば階層的であり、残念ながら謝罪はしばしば従順な行動と見なされます。人々は自分が使っているコンピュータよりも優れていると感じたいので、謝罪はこの方向に働きます。
要するに、これを「誰のせいなのか」の問題として見る。は、非常に論理的でない問題にアプローチするための非常に論理的な方法です。つまり、ソフトウェアを使用する流れの障害について、ユーザーが問題を感じないようにするにはどうすればよいですか。
謝罪の口調は、適切な人間のようなコミュニケーションを維持するのに役立ちます。過小評価すべきではない何か！
インターフェースとの相互作用は、常に対面式の人間の会話と比較する必要があります。あなたのケースに適用されない割引で列車の切符を購入しようとしていると想像してください。 「アクセスが禁止されています！」と聞きたいですかレジ係から、何か有益で丁寧なものより？
また、ユーザーが操作できない場所にアクセスできる場合、多くの場合、デザイナーの致命的なエラーです。ユーザーを責めることは何もありません。
はい、ユーザーに礼儀正しく伝えてください。ただし、ユーザーは読んでいないことに注意してください-特に中央のテキスト。そのため、実際の情報を簡単に見つけられるようにしてください。そして、フォームに複数のエラーメッセージがあり、「Sorry ...」または「Oops ...」で始まるすべてのエラーメッセージがある場合、それは本当に痛いことがあります。
あなたの発言は私には問題ないようです。それは本来あるべきではないので、それは本質的にあまり謝罪ではありません。そして、次の行の関連するソリューションで謝罪を非常によく褒め称えます。一部のエラーメッセージは、ユーザーをやる気にさせてしまう可能性のある、あまりにも率直で否定的なものとして出力されるため、状況によっては謝罪が必要になります。
それがユーザーの責任であっても、ソフトウェアが特定のユーザーが特定のエラーメッセージをどのように受け取るかを知ることができないため（特に、生産性を妨げる場合）、失礼で鈍感になりたくありません。小さな謝罪と考えられる解決策を追加すると、エラーメッセージ全体が無効になり、ユーザーは問題ではなく解決策に集中できます。
サイトまたはアプリの目的に依存します。ユーザーに困惑していると感じてもらいたいですか？例えば;アカウントをアップグレードして収益を増やしたいですか？ユーザーは、機能を失ったり「機能がない」という感覚に直面したときにアップグレードすることがよくあると思います。エラーメッセージは、ユーザーに印象を与える貴重な機会です。エラーがインターフェースの目的にとって重要でない場合。私はエラーからより大きな「もの」を作りません。エラーをすばやく確認し、ユーザーを目的のタスクに戻すのに役立ちます。
すべてのUXの決定と同様に、使用のコンテキストを考慮します。ユーザーが行ったことについて謝罪することは適切だとは思いませんが、システムやアプリケーションがユーザーに利用できなくなった場合や、ユーザー以外の問題（停止、インフラストラクチャの障害など）により失敗した場合は、検討する価値があります。既知の問題に関するその他の有用な情報、修正のETA、次に何をすべきか、回避策-ユーザーを継続させるため、またはユーザーを元に戻すためのあらゆるもの。
関連する点で、ユーザーを不快にさせるのは謝罪や不足ではなく、システム管理者に連絡するための指示です。多くのユーザーはそれを行うことができず、システム管理者がどのようにまたは何であるかさえ知りません！このようなアプリケーション障害の場合は、インシデント管理と自動ロギングを使用して、連絡先（ヘルプデスクやサポートチームなど）に連絡し、完了したことを伝えてください。次に、続行する方法、作業が安全かどうか、インシデント番号は何か、それを共有する方法などをユーザーに伝えます。
おそらくこれが役に立つでしょう： https://blogs.Oracle.com/userassistance/entry/unexpected_errors_are_they_ever_expected_anyway
エラーメッセージに関しては、おそらくその根拠は最善の方法ではありません。もし私たちが普遍的な論理に従うなら、そうです、私たちのせいではない何かについて謝罪するべきではありません。
しかし、私たちは常にユーザー中心のアプローチに価値を置き、何があってもユーザーを快適に感じることを最終的な目的としています。この点で、謝罪のアプローチが最善の解決策です。
その瞬間にユーザーが感じることを考えてみましょう。
「くそー、私はこの機能を使用することはできません！」
エラーは、訪問者を簡単に失う可能性がある重大な瞬間です。そのため、すべての認知的および心理的影響を考慮して、状況を非常に注意深く処理する必要があります。これは、日常生活のロジックではなく、本当に重要なことです。
それが彼のせいであるかどうかにかかわらず、エラーが発生すると、ユーザーは不満を感じるでしょう。欲求不満を感じたら、誰かの謝罪を求めます。はい、あなたはあなた自身の周りのすべての人とすべてを非難します。
幼稚ですが、私にも起こったことは認めます。アプリケーションが失敗して（私の間違いが原因で）謝罪したとき、本当に笑顔で考えさせられました。
「罰金、私はあなたを許します。とにかくあなたが何も悪いことをしなかったのを知っています。」
特定の政治的正当性のためにすべてのコストを目指していて、自分のせいではない何かについて謝罪したくない場合は、次のようなより中立的な口調を検討してください。
「残念ながら、この機能にアクセスする権限がありません。」
「残念ながら」という言葉は重要です。そうでなければ、それは差別のように聞こえ、欲求不満なユーザーを一瞬で追い払うでしょう：
「この機能にアクセスする権限がありません。」 （感嘆符を追加すると、そのユーザーは再び表示されなくなります）
メッセージ全体がなんらかの形式をとっているように見えます（本当です。アプリのコンテキストによって異なります）。私は、メッセージを非ロボット的な方法で提供する、短くて面白いものに行きます。簡単に聞こえますが、そのようなテキストを思い付くのは非常に困難です。あなたがそのように訓練されている限り、次のようなジレンマを回避するためです。
エラーの考えられる説明と、エラーから回復するためのいくつかの方法も提供する必要があります。これにより、ユーザーの不満が大幅に軽減されます。
SAS会社で働いている場合、あなたが過失ではないと仮定すると、謝罪する必要があると私は言うでしょう。
スターバックス、アップル、ザッポスなどの会社が出回っているので、それが自分のせいでない限り、人々は誰のせいなのか気にしない。消費者、エンドユーザー、購入者は王様か女王様です。
アプリ/サイトがすべてのデータを削除した場合は謝罪しないでください...それは、武器を広げた訴訟を歓迎しますが、人々は世界が彼らのカキであるように感じるのが大好きです。そして、あなたがすぐに解決策を見つける手段を備えた謝罪のメッセージを持っているなら、それのために行きなさい。
「管理者にサポートを依頼する」ためのリンクや電話番号などの方法を伝えないことをお詫びします
ユーザーは、「何の管理者ですか？」、「オフィスの管理者ですか、それとも会社の管理者ですか？」