設計バグの重大度をどのように伝えますか？標準化する方法はありますか？
ユーザビリティ関連のバグに対処してトリアージするとき、私は頻繁にショーを作成するか、問題に関するユーザーの苦痛を精巧かつ劇的に説明することに頼らなければならないことに気づきます。私は常にこれのいくつかを行う必要があると確信していますが、問題がどの程度深刻であるか/感じているかを伝えるためのより標準化された方法があったら幸いです。私はMozillaでバグをタグ付けするヒューリスティックスを発見するバグをタグ付けしている人々について読んだことがあります。これは素晴らしいアイデアだと思いますが、それは深刻さにはあまり役立ちません。誰かがそこに良いアイデアやプロセスを持っていますか？
例としては、1つのバグがデザイナーに感じられるかもしれませんが、この状態ではこれをリリースしてはいけませんが、それをプログラムした開発者にとっては、動作は明白に見えるので、それほど深刻ではないようです。
User Focusには、 優先度の高いユーザビリティの問題 のトピックに関する優れた記事があります。
私はオープニングポストの感情に同意します。エンジニアリング環境または大規模で複雑なシステムで作業している場合、一貫性のある理解可能な方法論とレポートプロセスを用意することが非常に重要です。それが重要である理由の一部は真剣に受け止められることであり、他の部分は良好なコミュニケーションを実践し、作業している他のチームやプロセスと有意義に統合することです。
実際に何かが本当に本当に問題であり、ユーザーにとって非常に苦痛であるということを本当に家に帰るには、対話のビデオクリップでレポートを補足することで、意見がシフトするのに不思議になることがあります。
この問題に2、3年悩み、使い勝手が比較的悪い製品を作成した後、この問題を別の方法で解決しました。
問題の原因は2つあります（少なくとも私が作業する場所）。1）「ビジネス」は、ユーザビリティの問題をスケジュール設定/優先順位付けすることは決してないため、a）新しい機能/バグ修正が必要であり、b）発想する方法がありません。使い勝手が悪い場合のコストの定量化（つまり、ソフトウェアの専門家ではなく、ドメインの専門家です）。
2）（従来の）開発者は、a）問題の範囲/コストを確認できない場合が多く、b）フロントエンド開発に自信がない場合が多いため、c）常にフォーカスが盗まれているため、ユーザビリティの問題をスケジュールしたり優先したりすることはありません。開発者の仕事の中核となる問題によって。
その結果、使い勝手が悪くなります。
そのため、IMOでは、ユーザビリティに対処するために、本質的に別の開発チャネルが必要です。これは、技術的負債とほとんど同じです（私が主張することも、この方法で「解決」されます）。理想的な世界では、独自の優先順位でフロントエンドエンジニアを採用するために、反復ごとに2、3のアジャイルポイント（または2週間のリリースごとに2日間）を費やすだけの小さな開発チャネルを作成します。 -リスト。この新しい開発チャネルは、ユーザビリティの問題を絶えず一貫して発生させ、ユーザビリティの問題は、非ユーザビリティの問題ではなく、お互いに優先されます。
さて、私の最初の段落の両方の聴衆にとって、いくつかの研究の要約、ケーススタディの結果、認められた教祖からの引用などを集めて数日を費やすなら、人々を説得する議論を構築することができるはずです。しかし、1時間の仕事を十分に優先させるために、4時間の研究と議論の構築に費やす時間のある人は誰でしょうか。しかし、単一の問題の優先順位付けを正当化するのではなく、開発の別のチャネルを正当化することを支持するものではなく（アプリの使いやすさの悪い例をいくつか挙げて）一緒に議論を得る場合、見返りは突如努力に値するものです。
私は普通のC＃.Net開発者であり、ユーザビリティへの関心が高まっています。私がしたことは、ユーザビリティの問題を検討することの重要性についての議論をまとめ、CTOに提案書を提出し、今ではユーザビリティの問題に自分の時間の一部を割り当てています。私のチームはいくつかの中核的な開発リソースを失いました（私たちは採用していたのでとにかくそれはより簡単な議論でした）が、今やいくつかのユーザビリティが最終的に見られるでしょう。
私の新しい仕事の一部は、使い勝手が悪い機能をリリースしないように他の開発者を教育することだと私は長期的に考えています。それがあったように、効果を増幅します。
幸運を！
ビジュアル、特にデモンストレーションは、私が見た中で最もインパクトを与えるものです。
これは、UXチームが製品のバックログにストーリーを送信し、見積もり会議中に投票するアジャイル環境でした。
ビジュアルは常にスクリーンショットを参照することで機能しましたが、最善の方法は実際に問題を実際に示し、それが問題である理由を説明することでした。
アジャイル環境ではない場合でも、問題が発生する可能性のある開発会議を開いている必要があります。何が問題になっているのかを示し、「壊れている」と考える理由について話し合う準備をしてください。
（ちなみに、アジャイルに不慣れな方は、何か作業したい場合は、それを書いて、「取り組む必要のあること」の大きなリストに提出してください。リストは毎週レビューされ、開発、UX、QAによって議論されます、製品管理、および主要な利害関係者）。
標準ゲージが思い浮かびますが、おそらく黄色からオレンジ、赤へと変化する色のグラデーションと組み合わされています。
他の類推を使用することもできます：虫のアイコン、食器の鍋、コップ、人、「壊しさ」のさまざまな段階。つまり、一部に石膏、ひび割れ（またはしわのような「笑顔」）、破片（オフ）、...完全に粉砕/押しつぶされた
動物や人間の類推を使用する場合は、あまりグラフィカルになりすぎないように注意してください。
使いやすさはプログラミングではありません。
このような段階的なシステムを作成することは誤解を招くでしょう。
何かに欠陥があり、システムを何らかの方法で壊してしまうと本当に考えている場合（ボタンが抜けているなど、次のステップに進むため）、それを修正します。
それ以外の場合は、それは単なるユーザビリティの問題であり、実践者として、コードが機能しないときに近いメトリックによってそれらを見つけることがどれほど重要であるかは問題ではありません。
プログラミングでは、が機能しないときは機能しません。これを機能させるには、修正する必要があります。
使いやすさの点で、システムが壊れる前により多くのことを回避できます。