神話1：ユーザビリティはGUI
多くのテスターの認識では、相互に排他的な2つのタイプのテストがあります。
- 機能的（宣言された機能が機能するかどうか）
- GUIテスト（ボタンの配置方法、ボタンのサイズと色）
この部門での機能テストはより重要と思われ、GUIテストは追加オプションであり、単純であり、あまり重要ではありません。 そして、多くの人がユーザビリティテストを呼ぶのは彼女です...
OK、同意しましょう： GUIテストとユーザビリティテストはまったく異なるものです。 ユーザビリティは、ユーザーのニーズを満たす製品の特性であり、グラフィカルインターフェイスはユーザビリティのコンポーネントの1つにすぎません。
製品の使いやすさは、さまざまな要因によって決まります。
- ユーザーが必要とする機能とそのパフォーマンス
- 製品の使いやすさとトレーニングのスピード
- 誤解によりユーザーが犯すエラーの数。
したがって、高いユーザビリティを実現するには、ボタンの色を変更するだけでは不十分です。ユーザビリティには、機能コンポーネント、GUI、ヘルプ、さらにはユーザーサポートが含まれます。
神話2：ユーザビリティテストは簡単
どんなに！ ユーザビリティテストをシンプルであると考え、必要な技術を適用せずにそれを実施する人は、ユーザビリティテストの概念自体を信用しません。
有用で成功したユーザビリティテストを行うには、十分な量の知識とスキルが必要です。
- ユーザビリティとインターフェース設計の原則を理解する
- 同様のプラットフォームで製品を使用した幅広い経験
- 製品のビジネスコンポーネントを理解する：なぜ必要なのですか？ どのタスクを解決しますか？
- ユーザーとの知り合い：彼は誰ですか？ 製品でどのような条件下で機能しますか？ 彼はどうやってそれをしますか？
さらに、この知識を単純に適用して言うことはできません。ここでは、これを変更する必要があります。 ユーザビリティテストでの推測や前提は、ユーザーでテストする必要があります。 実際のユーザーに！ そして、ここで次の神話に移ります。
神話3：誰でも製品のユーザビリティを評価できる
あなたの子供が5キログラムのお菓子の誕生日プレゼントを要求し、あなたがこれに同意したと想像してください。 しかし、彼はどんなキャンディが好きですか？
それらを選択する方法には2つのオプションがあります。
- 子供が自分で選択できるように、さまざまなキャンディーを試してもらう
- 自分で試してみて、あなたの意見で最もおいしいものを選んで、そのようなお菓子を5kg買ってください。
もちろん、2番目のケースでは、あなたが推測する可能性がありますが、それは悲惨なほど小さいです！
ユーザビリティテストでも同じことが言えます。製品を毎日テストし、テクノロジーとプログラムをよりよく理解し、平均的なユーザーよりもコンピューターリテラシーがはるかに高い（他のIT担当者向けのソフトウェアを作成しない限り）。 注意、質問は次のとおりです。あなたが会計士でない場合、最初にプログラムを立ち上げた会計士にとって何が便利かをどのように評価できますか。
ユーザビリティの原則を理解すると、サードパーティの製品ユーザーから有用な情報を取得できますが、自分で生成できます-いいえ！
神話4：使いやすさはすべてのもの
ユーザーの1人をよりよく認識し、その期待に応えるために製品を慎重に開発しているとします。 しかし、実際には、1人のユーザーのみが製品を使用することは非常にまれです！
会計士は経験豊富で初心者、グラフィックエディターは子供やデザイナーが使用し、アンチウイルスは大規模な組織や主婦の管理者がインストールします。 異なるタイプのユーザーの相互に排他的なニーズを満たそうとすると、誰も満足しません！ MSペイントには単純な形状とブラシがあり、Photoshopには無制限の機能があります。 企業のウイルス対策ソフトウェアはドメインポリシーを介してインストールされ、集中管理サーバーを備えていますが、ホームのウイルス対策ソフトウェアには1つの大きな「保護」ボタンがあります。 そして、もちろん、多くの製品には、初心者を怖がらせないように、経験豊富なユーザー向けの「高度な設定」があります。
あらゆるタイプのユーザーを知っていますか？ さまざまな製品オプションを提供していますか？
神話5：顧客は気分を良くする方法を知っている。
製品がカスタムメイドの場合、多くの人がリラックスします。クライアントに何かをするのに最適な方法を尋ねると、そうなります。
いくつかの「しかし」がなければ、すべてがうまくいくでしょう：
- クライアントはインターフェース設計について何も知らず、しばしば完全に非論理的なアイデアを提供します！
- クライアントは、実装オプションが何であるかを常によく理解しているわけではなく、複雑すぎるものを思いつきます。
- クライアントの要望に応じて作成されたリクエストごとのリクエストは、製品をキルトに変えます。キルトは一貫性と全体的なユニークなスタイルを失います。
ユーザーを知り、シナリオを調べ、問題を見つけて分析することが重要です！ しかし、インターフェース設計の専門家は、ユーザーではなく、あなたと私でなければなりません。
神話6：ユーザビリティはそれほど重要ではなく、機能はより重要
私はこれについて特に頻繁に耳にしますが、...しかし、いつものように、いくつかの「しかし」があります：
- ユーザビリティも機能です。 また、詳細なユーザビリティテストを実施する際に、一部の機能を削除したり、別の機能を開発したりする必要が生じることがよくありました。 そして、これらのケースでは、この機能の拡張はこの世界にうまく取り入れられ、ユーザーのニーズを満たしました。アナリストが発明したのは「追加するのが良い」からだけではありませんでした。
- クライアントが製品を使用しない場合（方法がわからない、望まないなど）、機能にアクセスできません。
99％のケースで、新しい機能を追加した最新の製品は、使いやすさを向上させるだけです！ これはすぐに目立つものではありませんが、よく見てください。過去のリリースで開発したすべてのことは、イノベーションなしで実行できます。 しかし、それらがなければ、さらに困難になります。 たとえば、電子メールクライアントは、ルールに従って文字をフォルダーに分類する方法を学びました-以前は、これを手動で行うことができました。 銀行プログラムに新しいレポートが追加されました-テキストエディターで入力される前。 グラフィックエディターの新しいフィルター-手で同様のレタッチを実行する前に。 製品が行うほとんどすべてのことは、使用せずに、ソフトウェアをまったく使用せずに実行できます。 しかし、製品が快適になると、カスタムタスクを完了することの利便性は、すべての製品の主な目標です！
結論
ユーザビリティは、ソフトウェア開発において活発に発展している分野です。 そして、上記の神話（および他の神話はまだたくさんあります！）
ユーザビリティテストの詳細については、次のリンクをご覧ください。
- 「 象を洗う方法は？」 "-便利な製品の設計に関するVlad Golovachによる優れた入門書。
- 「 ユーザビリティテストの数値手法 」-SQA Daysカンファレンスでのユーザビリティテストに関するレビューレポート