私は、ユーザビリティテストのバイアスに非常に敏感です。たとえば、私はタスク選択バイアスが問題であることを認識しているので、テストをよりオープン/ルーズに保ち、参加者が探索できるようにします。
ここに概説されているように、他のいくつかのタイプのバイアスがあることを知っています: http://www.measuringu.com/blog/ut-bias.php
ユーザビリティテストの偏りを減らすために、どのような実際的な手順を実行しましたか?
そのリストにあるものは別として、ユーザビリティテストを実施するとき、私は次のことを行います。
人々がリモートでテストを行っているときは、書面による指示を提供できるため、これを行う方が簡単です。しかし、実際には、私は「オフスクリプト」になり、誰かが私が望む可能性のある答えに導く可能性を避けるために、さらに一生懸命努力しています。
それ以外の場合は、リストの問題を回避する方法でテストも実施します。メモを取ることは避け(すべてを記録します)、特定のタスクを尋ねるのを避けます。または、特定のタスクを要求する場合は、それらの範囲を指定します。
私は制御された環境と制御されていない環境の両方でユーザビリティテストを実施しましたが、バイアスに対処するための特効薬はないと信じていますが、予防策を講じてテスト結果への影響を考慮する必要があります。
非常に影響力のある社会学者であったアービング・ゴフマン は、60年代にというタイトルの本を書きましたここでは、対面式の相互作用で行われる演劇について説明しています。長い引用で申し訳ありませんが、それはとても関連性があります:
個人が他の人と接触したとき、彼は自分の設定、外見、マナーを変更することにより、他の人が彼の形になるという印象を制御または誘導しようとします。同時に、個人が対話している人は、個人の印象を形成し、個人についての情報を取得しようとします…社会的対話の参加者は、自分や他人を困惑させないために、特定の慣行に従事します。社会は均質ではありません。異なる設定では異なる行動を取る必要があります。この認識は、ゴフマンを彼の劇的な分析に導きました。彼は人々が日常生活で行う「行為」の種類と演劇のパフォーマンスとの関係を見た。社会的相互作用では、演劇のパフォーマンスと同様に、俳優(個人)が観客の前に現れるオンステージエリアがあります。これは肯定的な自己概念と望ましい印象が提供される場所です。しかし、舞台裏–個人が自分自身であり、社会的役割とアイデンティティを落とすことができる隠されたプライベートエリアもあります。
すべてのテスト状況は固有であり、テストする相手によって異なりますが、原則として、たとえば次のような「オンステージパフォーマンス」に影響を与える可能性が高い状況を考慮する必要があります。
テスト参加者を準備して安心させる:これにより、ユーザビリティテストセッションは自分の能力をテストすることではなく、製品をテストすることをテスト参加者に通知して安心させることができますパフォーマンス(機密保持契約も持っている正式なテストプロトコルの一部である必要があります)。
ユーザビリティテスト環境の構成:これにより、テスト環境を評価し、テストを実施するための最適なレイアウトを決定できます。何が起こっているのかを明確に観察できるようにしながら、徐々に自分を緩和して、ユーザーが観察されていることに集中する必要がないようにします。
結果にはいくつかの段階的な問題があるため、自分とテスト参加者の両方にそれらを考慮に入れる必要があります。私がこれに取り組む方法は、各アクションポイントでユーザーアクションを常に質問することです。これは2つのリストに変換されます。1つ目は「ユーザーがこれを行っている理由」、2つ目は「理由」、そしてすべての可能性をすべて使い切るまで説明と一緒にすべての可能なトリガーをリストします。これにより、原則としてステージ上のパフォーマンスを見つけることができます。 Backstageのものにズームインしている間:)
これは少しトリッキーです、あなたは何らかの形のバイアスを疑うのは正しいと思うかもしれませんが、ユーザーの採用プロセス、人口統計、報酬のタイプ、ユーザーをチェックして取り戻すことでこれを軽減できます以前に多くのリモートテストセッションに参加したことがありますか?私の最後のポイント、彼らは専門家になり、したがって仕事に適していない:)
私が行った1つの初期テストでメタプログラミングの問題に遭遇しました。
私は次の質問をしていた:
Webページ上のフォームには、データをクリアまたは送信する方法が必要です。これは、従来、2つのボタンで処理されていました。 1つは「キャンセル」、もう1つは「送信」と言います。 2つのボタンのうち、1つは左側にあり、もう1つは右側にあります。 「キャンセル」ボタンはどれですか?
私は、プラットフォームに依存しない見解を得るために、コンピューターまたはスマートフォンに不慣れな候補者を選択しようとしました。結果は、キャンセルボタンを左側に置くことを支持するようです。
その後、結果を再確認したところ、いきなり質問の言い方に気づきました。 「1」という単語は3回表示され、「キャンセル」ボタンに関連して2回使用されます。キャンセルの概念は4回参照されますが、送信の概念は2回のみ参照され、2つのプロセスが言及される順序は一定です。 「クリア」/「送信」および「キャンセル」/「送信」。
数日後、私は再びテストに出かけましたが、今回は次の質問をしました:
Webページ上のフォームには、データをクリアする方法が必要です。これは従来、2つのボタンで処理されていました。 「キャンセル」ボタンはどれですか?
結果は、より密接にバランスが取れていました。 -最初の質問は候補者を導きましたが、2番目の質問は選択肢をより多く手に入れました。
テストを行う際に浮かび上がる問題の1つは、質問をしながら答えを与えない方法です。
たとえば、プロセスの次の部分を実行するためにユーザーが押すことになっているボタンがあります。何らかの理由でこれを取得できず、喜んでオフになってページ上の他のボタンをクリックしています。テスターとして、なぜクリックしないのかを知る必要があります。 「なぜ「ボタン」をクリックしないのかと言うと、それは彼らがやるべきことだと彼らに言ったはずです(そして、彼らはほとんどの場合、彼らは知らないとだけ言うでしょう)
...つまり、実際にあなたがする必要があるのは、彼らが正しく行っていないというヒントを彼らに与える方法を考えることですが、彼らは実際に問題を解決しておき、彼らが実際にどのように解決するかをThinking Aloudから理解できるようにしますそれ。
そして、このようなことがいつ起こるかわからないので、あなたはこれをライブで行わなければなりません。