「問題を提出する」ためのベストプラクティスは何ですか？
「問題を送信する」フォームから「うまくいかない」などのフィードバックがよく寄せられます。
ユーザーに優しく教えてください。
- やった ...
- そして期待していた...
- しかし、これは起こりました...
上記の接頭辞が付いた3つのテキストボックスを検討しています（質問の種類：[回答]スタイル）
更新
すでにスクリーンショットをキャプチャしています（アプリのみ、それはWebブラウザーにあるため、機密情報はなく、Webページのみを表示できます）。また、マシンの仕様を収集しています。
提案された解決策：1.問題があるスクリーンショットにマークを付けるオプションを提供します。 （正直なところ、これは脳の怪我をした人のためのソフトウェアなので、画面は非常にシンプルです）
Short Titleは、長い説明があり、長いテキストボックスに入力した後でのみ表示されることに注意してください。私たちは「返信します」b/c（ログインから）の電子メールをすでに持っていますが、多くの場合、それは患者を助ける医療従事者であり、「アカウント所有者」ではなくそれらに返信してほしいと思うかもしれません
この問題のベストプラクティスはありますか？
フォームに入力フィールドを追加すると、フォームがより複雑に見えるため、ユーザーが入力する可能性が低くなります（特に、入力する必要のあるものが何もない場合）。あなたが試すことができるのは、プレースホルダーテキストで説明的であることです。知りたいことを説明します。ユーザーがフィードバックを提供する方法は、ユーザー次第です。
それ以外にも、オペレーティングシステムやブラウザのような開発者にとって重要な他の情報があるかもしれません。このいわゆるユーザーエージェント情報は、ユーザーから取得できます（例は http://www.thismachine.info/ ）。エラーが発生したり、ユーザーがフォームに記入したりするたびに、この情報を一緒に送信すると便利です。
これは、私たちの多くがある時点で直面しなければならないトリッキーな問題です。
問題は、ユーザーが適切な問題報告の利点を認識していないこと、および（おそらく）作成したツールが必要なときにユーザーを支援できなかったときに支援するために後戻りしないように動機づけられていないことに起因します。
このトピックに関して、デスクトップクラッシュレポートの世界から学ぶべき多くの素晴らしい教訓があります。
発生したときと場所で壊れたアクションをインターセプトしてみてください（たとえば、404ページテンプレート、フォーム検証テンプレートなどで、[バグを報告]ボタンを追加し、現在のページ、リクエスト、レスポンスの詳細をパススルーします）。これにより、ユーザーは何が問題だったかを説明する必要がなくなり、理論的には、ユーザーの作業がほとんどなくても、新しい診断データの大きなチャンクが自動的に提供されます。
（オプションで）問題レポートに追加できるユーザーのアクションのトレースをキャプチャします。これはWebではトリッキーになる可能性がありますが、各ユーザーが試みたアクションをタイムスタンプでログに記録しているだけの場合でも、ユーザーが実行しようとした機能のkindと問題レポートを関連付けることができます。失敗したリクエストをログに記録する場合に二重に役立ちます。また、ブラウザの問題を特定するために、ユーザーエージェントの詳細などを（理想的にはユーザーの同意を得て）送信することもできます。
スクリーンショットを撮る方法をユーザーが知っていると期待しないでください。これは、ほとんどの主要なプラットフォームでの複雑なアクションです。問題レポートの要件にしないでください。
タイトルと問題の説明を別々に要求することに成功しました。 （偶発的に）私のユーザーはメールに意味のある件名を書くことに慣れているようです。そのため、説明が少し薄い場合でも、問題の報告には同じようにしてください。
適切な問題レポートのテンプレートを説明テキスト領域に事前に入力します。
バグを発見したと思います。いつでも…
どうなる…
期待していた…
私が知る限り、「ベストプラクティス」はありません。あなたは正しい道を進んでいると思います。それを試して、何が起こるか見てください。万能薬ではありませんが、役立つはずです。
皮肉なことに私を呼んでも、具体的な報酬がない限り、ほとんどのユーザーは「それはうまくいかない」以上のことはしません。
問題の診断はユーザーの仕事ではなく、あなたの仕事です。ユーザーは、自分がもっと役立つ可能性があることを知らない（つまり、とにかくそれを理解できると想定している）か、単に努力したくないだけです。
私はあなたが事前記入された答えでどこに行くのが好きですが、私は別のアプローチで行きます：
まず、可能な場合は、ヘルプセンターにアクセスする前に、ユーザーがアクセスしていた最後の数ページを何らかの方法で追跡します。
次に、ブラウザー/デバイスから可能な限り多くの情報（OS、画面サイズ、アカウント情報、言語など）を収集します。
最後に、1つのテキストボックスにさまざまなセクションを事前に入力します。
What you were doing:
What you expected:
What happened instead:
これにより、ユーザーは必要に応じて事前入力されたテキストを削除できますが、問題がその構造に当てはまる場合は入力することをお勧めします。
3つの個別のボックスを作成すると、ユーザーは問題をさまざまなセクションに詰め込もうとすることになります。そうするのが面倒だとしたら、あきらめるでしょう。
ユーザーによって識別されたバグの数を記録し、StackExchangeのようにバッジタイプシステムを実装することを検討してください。
たとえば、ユーザーが新しくユニークなバグを報告すると（実際の修正が必要です）、ユーザーのステータスが増加します。バグが実際に修正された場合、ユーザーのアカウントに他のステータスが追加されます。
このようにして、ユーザーはフィードバックがどのように役立つかを確認し、優れたフィードバックを提供するためにいくつかの独占性を追加します。
ここで2つのことを理解する必要があります
問題
- ユーザーとして、私には多くの時間がありません。バグについてお知らせしているという事実は非常に助かります。タイピングをやり過ぎるとは思わないでください。
- 開発者として、私はそれをよりよく理解して修正できるように、バグの詳細を期待しています。
今、あなたはこれら二つのバランスを取る必要があります。私は次の方法を提案します。
可能な方法
- （必須）ユーザーに1つのテキスト領域だけを提供し、問題を自分の自然言語で説明できるようにします。
- （必須）ブラウザ/デバイス/場所などの他の詳細とともに、ページのスクリーンショットを自動的にキャプチャできます。
- （オプション）上記のスクリーンショットから、ユーザーに問題の領域をマークするように依頼できます。
このメソッドの短所：
- ユーザーの許可なく直接スクリーンショットを撮ったため、そのページにユーザーの個人データが含まれていた可能性があります。ユーザーにそれらの領域をぼかすことを許可することができます
- これは実装が少し難しいですが、完全に可能です
例
この典型的な例は Google Plus です。メニューにはフィードバックオプションがあり、同じように機能します。
OPの問題をよりクリエイティブな方法で聞きたいです:)