より良いエラーの説明を送信するようユーザー/顧客に教える方法

多くの場合、アプリケーションのエラーを報告している顧客またはユーザーに対処する必要があります。ほとんどの場合、コンテンツは次のような役に立たないものです。

• エラー！！！
• xは機能しません

多くの情報なしで。

問題を解決するために、私はそれらのすべての詳細を要求する必要がありますが、多くの場合、問題自体を修正するよりも時間がかかります。他の人は、リンク（システムにアクセスできます）などを送信できますが、スクリーンショット（エラーではなくデータレコード）などの理想的ではない形式で情報を送信します。

プロセスを両方の側で簡単にするために、ユーザー/顧客に問題をより詳細に説明するようにどのように伝えますか？

編集する

この質問は、ログおよびエラー情報のプログラムによる収集を達成する方法よりも、ソーシャルスキルに関するものです。これは優れたソフトウェア設計の一部である必要があるという事実を知っています。

優れたバグレポートに対してユーザーに報酬を与え、悪いレポートに対しては罰します（少なくとも少し）。

ユーザーは、問題を迅速に修正するために優れたバグレポートが不可欠であることを理解する必要があります。したがって、ソリューションをより迅速に取得できるため、ユーザーにとっても良いことです。

したがって、最初の応答は、「わかりました、レポートを読みましたが、どこから始めればいいのかわかりません。これは一度起こりましたか？繰り返し起こる現象ですか？Xを試して何を教えてくださいYはその後のように見えますか？」等々。

多くの場合、人々はこの種のフィードバックを受けて、何をすべきかを伝え、最初に学んだことを（直接的または間接的に）彼らに伝えなかった。すぐにではないかもしれませんが、提出するレポートが多ければ多いほど、彼らはあなたが彼らに尋ねようとしていることを予想し、直接答えを提供します。

はい、これは段階的なプロセスであり、明日の朝まですべての通信の問題を解決しませんが、それでも開始です。

いくつかのオープンソースプロジェクトが行っていることの1つは、一般的に必要な情報のセクションを使用して、バグレポートの標準「フォーム」を作成することです。

顧客がアクセスできるバグ報告サイトまたはアプリケーションがある場合は、その空白バージョンをバグの説明フィールドのデフォルトテキストにできるかどうかを確認してください。それ以外の場合は、サイトや製品のインストールディレクトリなど、ユーザーが見つけられる場所（またはポイントできる場所）に置きます。

あなたの場合、これは次のようなものです。

URL where the error occurred:

What you did:

What you expected to happen:

What actually happened:

<Some other information you (ckeller & colleagues) often find useful>:

Any extra information you think might be relevant:

（ここでの「あなた」は顧客を指します）

アイデアは、最も頻繁に役立つ情報の種類のリストを提供することにより、有用な情報を提供することを奨励することです。

通常、私は彼らにエラーのスクリーンショットを毎回頼みます、そして、彼らは私がそれを求めることを知っているので、最終的に彼らはエラー要求で私にスクリーンショットを送り始めます。

時々詳細を調べるためにそれらを呼び出す必要がありますが、多くの場合、スクリーンショットを見るだけで問題を見ることができます

しかし、@ Mahmoudのコメントには同意します。最良の方法は、ユーザーに依存するのではなく、アプリケーションにエラーを送信させることです。

悲観的な見方：できません。40年前と同じ状況ですが、ユーザー数、システム数、アプリケーション数が増加している点が異なります。

（悲観主義者は経験のある楽観主義者であることに注意してください。）

彼らが簡単にできるようにします。

できれば、必要な情報を提供する方法でエラーを報告できる最も簡単な方法を作成してください。これはほぼ間違いなく、ソフトウェアのエラー報告プロセスを自動化することを意味します。

詳細なログファイルを保持し、エラーレポートを添付することから始めます。

顧客との会話を終えたら、「次回このような事態になったら、データ項目A、B、Cなどを用意してください。」と言います。もちろん、これは同じ顧客が繰り返し電話をかけている場合にのみ機能します。このアプローチでは成功しました。ユーザーは、a）呼び出しを高速化し、b）全体的な解決をより迅速にする特定の重要なことを学びました。

それらのほとんどが1回限りの呼び出し元である場合、「エラー！」を更新するのが最善かもしれません。「当社の担当者と話す前に、データ項目A、B、Cを収集する必要があります」というテキストの画面。これは、アプリをどの程度制御できるかに大きく依存するため、まったく実行できない場合があります。これも確実な方法ではありませんが、「ERRORZ PLZ HLP !!!」と叫ぶというアイデアを顧客の頭に収めることができれば幸いです。十分ではありません。

最新のアプリケーションでのエラーメッセージの問題は、関連する可能性のあるすべてのコンテキストを含めることが事実上不可能であることです。プロセッサアーキテクチャから時刻までのすべてが関連する可能性があるため、エラー報告とエラー処理の両方が科学よりも芸術的です。のようなシステムapport-bugは、関連情報を収集して送信するという点で便利です。残念なことに、問題の複製者、タイムトラベル、ハイゼンベルグ補償者の時代まで、ユーザーから得た情報が問題をデバッグしたり再現したりするのに十分であると確信する方法はありません。

必要なものをすべて記録します。x mbのローリングログファイルがあります。何か問題が発生した場合、ユーザーはログファイルを送信しますが、多くの場合、これで問題を修正できます。

別のオプションは、リモートデスクトップクライアントを使用して、何が問題なのかを自分で確認することです。最近では、クライアントにexeをダウンロードさせるのと同じくらい簡単です。

あなたは先のとがった質問をしなければならなくて、あなたにすべての答えを与えるためにそれらを非常に要求しなければなりません。問題に対する彼らの不満は、週末の彼らの計画、彼らの重要な他者、または天気に関する不満に散在することがあります。彼らに仕事を続けさせ、「OK、あなたはXをするがYをしないとき、何が起こるのか？」と尋ねてみてください。それらの応答に注釈を付けて、後で戻ってデバッグできるイベントのシーケンス図の作成を開始します。

時間をかけて、アプリの右上隅にある[バグを報告]赤いボタンを追加できます。ユーザーがボタンを押すと、スクリーンショットを撮り、セッションで利用可能なすべてのログを収集し、ユーザー画面への直接画面共有を開き、簡単なフォームを表示して、サーバーにデータを自動的に送信します。

-アプリがデータ自体を取得できるかどうかをできるだけユーザーに尋ねないでください。画面解像度、OSバージョン、ユーザー名、ログイン、最後のアクションとログ

-チケットをユーザーに割り当ててリンクを提供すると、www.yoursite.issues / 1234にバグ番号1234があることがわかります。

-ユーザーに達成しようとしたことを尋ねます。

これをすべて、または部分的にすれば、十分なデータを受信し、ソフトウェアをさらに改善するために役立つことをユーザーに示すことができると思います。

最も簡単な方法は、実際にクライアントが望むものを「理解」できるツールを使用することです。多くのツールがありますが、おそらく最高のものはUsersnapです。 こちらのストーリーをご覧ください。