設計による「バグ」は悪い兆候ですか？
ユーザーが仕様によるバグレポートを提出した場合、それは悪い兆候でしょうか？
それは通常、アプリケーションが混乱している、または不明確であることを意味しますか、それとも、特に明記されていない限り、1回限りのユーザーの間違いまでそれをチョークすべきですか？
（実際にはそのようなレポートはありません。これは、設計上の「バグ」の存在が悪いことであるかどうかについての純粋に仮説的な質問です。）
それは悪い兆候ですか？調べる価値のある警告だと思いますが、発生する可能性もあると思います。
人々が私に何らかの種類のフィードバックを送信するとき、私はそれを3つのバケットにフィルタリングしようとします：
- バグ
- 機能のリクエスト
- コミュニケーション不足
バグ
バグとは、何かが明らかにyoが期待するように機能しない、またはserが期待する方法も機能しない場合です。たとえば、名前を尋ねられたので、「スコット」と入力してEnterキーを押すと、「ハイジョー！」
機能のリクエスト
これは、「これについて話したことがないことはわかっていますが、マウスのジェスチャーから、プログラムが左利きで、OKボタンを画面の左側に移動したことを推測できますか？」のようなものです。これは、現在の動作がユーザーとユーザーのの両方の期待に一致するが、期待を変更したい場合です。
コミュニケーション不足
これはあなたがシナリオからの1つの結果を期待するときですが、ユーザーは別の結果を期待します。期待を伝えていなかったが、そうしたと思った場合、これは機能のリクエストになることがあります。期待が間違っていることが証明された場合、これはバグになることがあります。
ただし、多くの場合、ユーザーが知らない知識があります。 「この画面で、自分の姓と名が同じレコードを2回追加できます。これは明らかにバグです！」あなたの回答は、「同じ姓名を持つ人は世界中にたくさんいるので、その組み合わせを一意にする必要はありません。夜間に実行されるクリーンアップタスクがあり、重複の可能性があるレポートをメールで送信しています。カスタマーサービスは、類似した名前と住所の重複を検出し、手動で確認するように求めた場合に、
そのため、すべてのバグレポートを読む必要がありますが、ほとんどの複雑なシステムでは、実際には機能のリクエスト、または要件の誤った伝達であるバグレポートが作成されます。現実世界の根本的な複雑さを理解していないことが、おそらくこれらの問題の最大の原因です。
これはこれまでの回答では触れられていなかったため、無知なユーザーベースの兆候である可能性もあると付け加えます。私は「無知」という言葉を軽蔑的または侮辱的な方法で使用していません。彼らが自分のドメインまたはソフトウェア自体の複雑さについて適切な知識または教育を受けていないことを表現する方法としてだけです。
ほとんどのユーザーは、特定の要件を満たすためにソフトウェアがどれほど複雑である必要があるかを認識していません。作業の80％の効果の一部は、機能のわずか20％になります（フリンジと例外の場合）。
彼らは時々、ソフトウェアが本質的に特定の方法で動作する必要がある理由を理解しません。
これは心配する必要はありません。明確で簡潔なドキュメンテーションとコミュニケーションによってこれが改善されるからです。
その分野の専門家であるユーザーがいる場合、大きな問題が発生する可能性があります。あなたのソフトウェアを意図的に見つけた会計士が、一般的な会計手順に従っていない、またはあなたが間違った式を持っていることを発見したエンジニアを想像してみてください。これは、それらが正しいかどうかを調べるために調査することは難しくありません。必要に応じて再設計して修正します。
特定のUI機能や、通貨記号やその他の形式が必要だと思われるフィールドについての意見は、少なくともフィードバックが増えるまで検討する必要があります。これを研究することはもう少し難しいかもしれません。
私の経験における設計上のバグは、ユースケースが実際のユーザーに適合しないことを意味します。ユースケースで実際のユーザーを使用することについて読んでみてください（ユーザーに名前とサムネイルの説明を与えるだけで、ユースケースの品質に疑問が生じます）。
著名なOSベンダーが「この振る舞いは設計によるものである」と言ったとき、彼らは一般に実装の容易さまたは商業上の利点を念頭に置いていました。それがあなたではない場合は、ユーザーの実際のスキルセットとソフトウェアとの関係を見つけてください。彼らはそれを一日中使用しますか？お楽しみですか？ TPSフォームを置き換えたため、週に1回ですか？
UIは The Principle of Least Astonishment に従う必要があります。設計どおりに機能する機能に関するバグレポートが繰り返し報告されている場合は、この原則が正しく守られていないことを示しています。
必ずしも。報告されたバグは、最初に定義された範囲のすぐ外にあるソフトウェアの使用にある可能性があります。 A、B、Cを実行するように設計されたソフトウェアについて考えてみます（簡単な例として、線、三角形、および長方形を描画します）。 Dが論理的な次のステップ（たとえば、五角形）である場合、ユーザーもそれを行うべきであると想定する場合があり、そうしないことはバグです。ただし、これが元の範囲外の場合は、バグではありません。代わりに、設計の見落とし（バグ）、仕様の灰色の領域、または開発者とユーザーが行った別の一連の仮定である可能性があります。
（編集-@Marjan Venemaの提案に従って私のコメントを回答に追加しました。
バグには2種類あります。機能がプログラマの意図と一致しないか、機能が要件と一致しません。プログラマーは前者に焦点を当て、後者を損なう傾向があります。簡単に言えば、ユーザーが多くの「設計上のバグ」を報告している場合、要件はあなたが思っているものではありません。
Maple_shaftのユーザーの「無知」についての回答に追加したいと思います。また、ユーザーの90％が自分自身の経験とシステムの使用方法のみを気にすることにも留意する必要があります。彼らは他のユーザーを気にしません、なぜ彼らはそうすべきですか？デザイナー/開発者としての私たちの仕事は、さまざまな種類のユーザーからの意見を取り入れ、すべての人に可能な限り適合するものを作ることです。ほとんどの場合、すべての人に最適なソリューションを作成することはできません。
ただし、もちろん、ユーザーからのフィードバックを読んで評価する必要があります。結局のところ、あなたの創造物を使用するのは彼らです！
設計が一般的ではなく、ユーザーの要件が完全に理解/分析されていないという事実が主な原因であると私はそれを悪い兆候と信じています。
デザインの2つのカテゴリが表示されます-偶然のデザイン。 -意図的なデザイン。
偶然の設計はそのような問題を頻繁に引き起こし、持続することができません。
バグリクエストを送信したユーザーは、通常、設計について相談を受けなかったため、意図的な設計決定であるバグと見なされても驚くことではありません。ユーザーにとって、期待どおりに機能しないものはバグです。
私は問題がBAまたはPMが実際のユーザーではなくマネージャーからの要件しか得ていないことの兆候であることが多いことを発見しました。マネージャーがシステムに期待することは、多くの場合実際にデータを入力する人々とは大きく異なります私は実際のユーザーから直接データを収集するように教えられましたが、最近遭遇したほとんどのBAはマネージャー（そして一般的には比較的上級のマネージャー）としか話しません。