設計上の「バグ」は悪い兆候ですか？

ユーザーが設計上のものについてバグレポートを提出するのは悪い兆候ですか

それは通常、アプリケーションが混乱したり不明瞭であることを意味しますか、それとも特に明記しない限り、1回限りのユーザーの間違いまでそれをチョークする必要がありますか？

（実際にはそのような報告はありません。これは、設計上の「バグ」の存在が悪いことであるかどうかについての純粋に仮説的な質問です。）

それは悪い兆候ですか？調査する価値がある警告だと思いますが、それは必ず起こると思います。

人々が何らかのフィードバックを私に送信するとき、私はそれを3つのバケットにフィルタリングしようとします：

• 虫
• 機能リクエスト
• ミスコミュニケーション

虫

何かが明らかに道に動作しない場合にバグがあり、あなたが期待する、また道ユーザーが期待します。たとえば、私の名前を尋ねられ、「Scott」と入力してEnterキーを押し、「Hi Joe！」と言いました。

機能リクエスト

これは、「これについては一度も話したことがないが、プログラムはマウスジェスチャから左利きだと推測し、[OK]ボタンを画面の左側に移動できますか？」のようなものです。これは、現在の動作があなたとユーザーの両方の期待に一致するが、期待を変えたい場合です。

ミスコミュニケーション

とき、これは、あなたがシナリオから1つの成果を期待するだろうが、ユーザーは、異なる結果を期待しています。期待を伝えていないだけで機能要求になった場合もありますが、そうだと思っていました。あなたの期待が間違っていることが証明された場合、これはバグになることがあります。

ただし、多くの場合、ユーザーにはないという知識があります。「この画面で、自分の姓と名が同じレコードを2回追加できます。これは明らかにバグです！」あなたの応答は、「同じ姓と名を持つ人が世界中にたくさんいるので、その組み合わせを一意にする必要はありません。カスタマーサービスは、類似した名前と住所の重複を検出したと判断し、手動で確認するように依頼します。」

そのため、すべてのバグレポートを読む必要がありますが、ほとんどの複雑なシステムには、実際には単なる機能要求であるか、要件の誤った伝達であるバグレポートがあります。現実の世界の根本的な複雑さを理解していないことが、おそらくこれらの問題の最大の原因です。

これはこれまでの回答では触れられていなかったため、無知なユーザーベースの兆候である可能性もあると付け加えます。私は、「無知」という言葉を軽con的または卑wayな方法で使用せず、彼らの領域またはソフトウェア自体の複雑さに関する適切な知識や教育がないことを単に表現する方法として使用します。

ほとんどのユーザーは、特定の要件を満たすためにソフトウェアがどれほど複雑であるかを認識していません。努力の80％の効果の一部は、機能の20％のみになります（フリンジおよび例外の場合）。

彼らは、ソフトウェアが本質的に特定の方法で動作する必要がある理由を理解していないことがあり、多くの場合、多数の欠陥やデータの破損などを防ぎます...

これは、明確で簡潔な文書化とコミュニケーションにより改善されるため、心配する必要はありません。

その分野の専門家であるユーザーがいる場合、大きな問題が発生する可能性があります。設計上、あなたのソフトウェアを見つける会計士が一般的な会計手順に従っていない、またはあなたが間違った式を持っていることを発見したエンジニアを想像してください。これが正しいかどうかを確認するために調査するのはそれほど難しくないはずです。必要に応じて、再設計して修正してください。

特定のUI機能や、通貨記号やその他の書式を設定する必要があると考えられるフィールドに関する意見は、少なくともフィードバックが得られるまで検討する必要があります。これを研究することはもう少し難しいかもしれません。

私の経験による設計上のバグは、ユースケースが実際のユーザーに適合しないことを意味します。ユースケースに実際のユーザーを使用することについて読んでみてください（名前とサムネイルの説明を与えるだけで、ユースケースの品質が向上します）。

著名なOSベンダーが「この動作は仕様によるものだ」と言うとき、彼らは一般に実装の容易さや商業的優位性を念頭に置いていました。そうでない場合は、ユーザーの実際のスキルセットとソフトウェアとの関係を調べてみてください。彼らは一日中それを使用していますか？楽しみですか？TPSフォームを置き換えたため、週に1回ですか？

UIは最小の驚きの原則に従う必要があります-設計どおりに機能する機能に関するバグレポートが繰り返されるということは、この原則が正しく守られていないことを示しています。

バグには2種類あります。機能がプログラマの意図と一致しないか、機能が要件と一致しません。プログラマは、前者に焦点を当てて後者を犠牲にする傾向があります。簡単に言えば、ユーザーが多くの「設計上のバグ」を報告している場合、あなたの要求はあなたが思っているものではありません。

必ずしも。報告されたバグは、最初に定義された範囲外のソフトウェアを使用している可能性があります。A、B、Cを実行するように設計されたソフトウェアを考えてみてください（簡単な例では、線、三角形、長方形を描画します）。Dが論理的な次のステップ（五角形など）である場合、ユーザーはDがそれを行うべきであると仮定する場合があり、そうしないことはバグです。しかし、これが元の範囲外であれば、それはバグではありません。代わりに、設計の見落とし（バグ）、仕様の灰色の領域、または開発者とユーザーが行った別の仮定のセットが考えられます。

（編集-@Marjan Venemaの提案に従って、答えに私のコメントを追加しました。

主にデザインが一般的ではなく、ユーザーの要件が完全に理解/分析されていないという事実による悪い兆候だと思います。

デザインには2つのカテゴリがあります-偶然のデザイン。-意図的な設計。

偶然の設計は、このような問題を頻繁に引き起こし、維持できません。

ユーザーの「無知」に関するmaple_shaftの回答に追加したいと思います。また、ユーザーの90％が自分の経験とシステムの使用方法のみを気にすることにも留意する必要があります。彼らは他のユーザーを気にしません、なぜ彼らはそうすべきですか？デザイナー/開発者としての私たちの仕事は、さまざまな種類のユーザーからの意見を取り入れ、すべての人にできるだけ適したものを作ることです。ほとんどの場合、誰にとっても最適なソリューションを作成することはできません。

しかしもちろん、ユーザーからのフィードバックを読んで評価する必要があります！結局のところ、彼らはあなたの創造物を使用する人々です！

バグリクエストを送信するユーザーは通常、設計について相談されなかったため、意図的に設計を決定したバグと見なすことは驚くことではありません。ユーザーにとって、期待どおりに機能しないものはすべてバグです。

多くの場合、問題はBAまたはPMが実際のユーザーではなくマネージャーからのみ要件を取得したという兆候であることがわかりました。多くの場合、管理者がシステムに期待することは、データを入力する人が実際に必要とするものとは大きく異なります。私は実際のユーザーから直接データを収集するように教えられましたが、最近出会ったほとんどのBAはマネージャー（そして一般的には比較的上級のマネージャー）にしか話しません。