ゲリラ戦術を用いたユーザーテストに頼っている、小さなプロダクトチームでいつも働いてきました。私たちはこれらのテストのために、最適な数の参加者を募集しようとします。私たちは、ターゲットとなるオーディエンスを反映したグループ層であることを確認します。私たちは、より自然な行動を促し、参加者たちが陥りがちな偏見の影響を減少させる、形式張らないアプローチを利用します。
しかし、私たちがほとんど話したことがないことが、何かわかりますか？ 私たち自身です。結局のところ、私たちは自分が個人的かつ感情的な要素を取り入れた仕事を査定していたのです。私は時折、私たちが発見したことは、本当に客観的なのかどうか、自分に自問自答していることに気がつきました。
結局、それらは客観的ではない可能性があることが判明しました。
「ユーザビリティの問題の概要と、ユーザビリティテストにおける査定者の影響」において、Miranda G. Capra氏は、ユーザーに注目したUXコミュニティにおいて、テストについては語られますが、査定者の役割についてはほとんど語られない傾向があることを突き止めています。同じユーザーが同じタスクを行う場合、報告された問題も、それを査定する人にかかわらず、同じであるべきだという前提があります。
しかし、Capra氏が44名のユーザビリティの実践者たちによる、あらかじめ記録されたセッションの査定を研究したところ、この前提は見られませんでした。経験豊富な研究者と大学院生から成る査定者たちは、重複した問題の割合は、予想外にも低く、わずか22パーセントだったと報告していました。異なる査定者は異なる問題を発見し、それらの問題に対して異なるレベルの重大性を割り当てていました。彼女は、査定者の役割はデザインとUXのコミュニティにおいて今までに認識されていたよりも、もっと重要であると結論付けています。
同じ記録データを査定しているユーザビリティの専門家でさえも、完全かつ客観的な結果をもたらすことができないとしたら、ユーザーテストを計画、実行及び査定をする、未熟なチームから何を期待すればよいのでしょうか？
偏見は避けられないもの
人々は完全にプロジェクトに没頭しているので、私たちは計画から分析まで、あらゆる研究段階における結果に影響を及ぼす可能性がある、たくさんの認知バイアスに影響を受けやすいのです。経験がない査定者の中にある確証バイアスは、一般的な偏見です。これによって、私たちは自分の考えを確認する、または無意識に特定の反応の優先順位を付けたり、無視したりする方法で疑問を投げかけるようになります。私は自分でそれを行っており、同僚の中にも行っている人がいます。例えば、私には以前、検索機能の導入に特に熱を入れていた同僚がいました。たった1人の回答者が検索の欠如についてコメントしたという事実にもかかわらず、「大部分の人々」が検索を求めていたと説得されたテストの工程を完了したのです。
私たちは皆、自分の研究に自分のチームにとって信頼できる手引きを提供してもらいたいと思っています。私たちの多くは、意図的にデータを曲解することはしないでしょう。しかし、偏見というものは知らないうちにもたらされることが多く、研究者たちはそれに気がついていないのです。最悪なシナリオは、曲解された、または誤った結果が製品の誤った管理の仕方を伝えたり、チームの決定に誤った自信を生む可能性があるということです。
Capra氏の調査やその他の研究によると、偏見は一般的に計画段階 （テストのタスクやシナリオの下書きを行う段階）、セッション自体 （参加者とやり取りを行い、彼らの行動を観察する段階）、及び分析段階 （データを解釈し、結論を引き出す段階） で起こることがわかりました。この点を承知の上、オンラインの学習プラットフォームであるFutureLearnの私のチームは、進める必要がある迅速かつ効果的な研究を行いながらも、研究における偏見が生じるチャンスを減らそうと努めました。私は、自分たちが確立した工程やテクニックを共有したいと思っています。
温存している自分の考えや仮説を活用する
研究を始める前に、特に自分が「強い思い」を持っているものに対する検証を行う際には、自分の個人的な信念や考えを正直に認めましょう。これらの考えや仮説を思い浮かべ、そして書き出してみましょう。
保存ボタンは、見ることができないフォームの一番下よりも、一番上に表示させたほうが良いと思いますか？ 崩壊してしまっているサイドメニューに、いつも苛立ちを覚えていませんか？ 自分がデザインしたスマートな新しいコントロールに対して特に満足しており、誇りに思っていませんか？ このラベルは混乱を招き、誤解されやすいものであると納得していますか？ これらを書き出すことで、その存在をより意識するようになるでしょう。もし可能であれば、これらの分野が検証される時は、他の誰かに陣頭指揮を取ってもらいましょう。
計画段階では、様々な批評者たちを参加させる
FutureLearnでは、私たちの研究は非常に強力的なものになっています。プロダクトチーム （そして多くの場合は他のチーム） の誰もが、積極的に参加しています。私たちは、デザイナーや開発者、プロジェクトマネージャー、コンテンツ作成者、サポート、及びマーケティングといった、様々な役割と略歴を持った異なる人々を、各研究プロジェクトに招待しています。
私たちは、有志で参加を希望した人全員に、Google Docで作成した２部門に分かれた検証計画を共有することから始めます。この計画には、以下の内容が含まれています：
・検証の目的：ここでは、私たちが検証によって答えが導き出されることを願っている、１～３個の質問を書き出します。私たちのテストは基本的に短く、特定の研究対象に重点を置いています。例えば、「人々が新しいカテゴリーのフィルター機能のデザインをどのように上手く操作しているかを見てみましょう」と言う代わりに、「カテゴリーのフィルター機能の存在が、コースリストにおけるソートタブの使用にどのような影響を与えているかを明らかにしましょう」のように、数値で測定できる結果を推奨するような、客観的な文言を選ぶことを目指しています。このような方法で目的を表現することは、私たちの査定者による （誤った） 解釈に着目するのに役立ちます。
・検証のシナリオ：この目的に基づいて、参加者たちとともに行う３～４つのタスクとシナリオを書き出します。タスクをできる限り実際の生活における行動に近い、行うことができるものにして、説明や指導が具体的なものとなっているようにします。各シナリオには、参加者たちのインターフェースとのやりとりをサポートするコンテキストを提供します。例えば、「６月開始のコースを探してください」と言う代わりに、「来月皆さんは休暇を取り、その時期に自分の興味のあるコースがあるかどうか探していると想像してください」のような台詞を言います。
過去に行われたあるセッションでは、参加者たちが特定のコースを見つけることを要求された時に、私たちは「探す」及び「検索する」といった動詞を最初の草稿で使用していました。ある同僚が「コースを検索してください」と参加者に依頼したことによって気がついたのですが、私たちは参加者たちがプラットフォーム上で自然にどのような方法でコースを見つけるのかを観察するのではなく、むしろ参加者たちに検索フィールドを探すように誘導していた可能性があるのです。今思うと、「検索」は誤った言葉の選択だったことは明らかのように見えますが、このような微妙な違いを見落としがちな、プロジェクトに関わっているシナリオの草稿作成者にとっては、この言葉の選択が容易なものなのです。この事態を回避するために、現在私たちは複数の人たちにそれぞれシナリオを読んでもらい、使用されている言葉が特定の方向に参加者の反応を誘導していないかどうか確認しています。
様々な査定者たちとともに検証を行う
Capra氏は自身の論文で、複数の観察者を検証に参加させることで、偏った結果が生じるチャンスを減らすことができ、また「より多くの査定者を参加させて少ない時間で検証を行う方が、少ない査定者によって長時間検証を行うよりもずっと効果的である」と述べています。また、彼女は以下の点を指摘しています：
２人目の査定者を加えることで、問題の発見率が30～43パーセント上昇する結果となりました…追加された査定者ごとのメリットは減っており、３人目の査定者からは12～20パーセントの上昇、４番目の査定者からは７～１２パーセントの上昇となっています。
私の経験では、同じような少数グループ （または１人） が、常にユーザーテストを担当していました。通常、彼らは検証中のプロジェクトにも携わっていました。観察者がデザインフローに対して参加者を避難するほど、これは査定者を守勢にさせることがあります。また、時には研究に参加していないチームメンバーを、望ましくない、または予想外の結果に対して懐疑的にさせることもありました。
この事態を回避するために、私たちは複数の人たちに、セッションの管理を含む、工程の全ての段階を監督してもらうようにしています。通常、私たちのうちデザイナー２名、開発者１名、そして他の分野 （プロダクトマネージャーまたはコピーライターなど） から２名、計４人が実際のセッションを行います。複数のデザイナーのうち１人だけがプロジェクトに実際に参加することは非常に重要であり、他の３人の査定者たちが新しい見解をもたらすことができます。
最も重要なことは、単に受け身な観察者としてではなく、誰もが積極的に関わることです。私たちは全員参加者たちに話しかけ、メモを取り、そしてセッションをひっぱていくのです。
セッション中、私たちは通常それぞれ独立して作用する２つのテスト「ステーション」を設置します。これは、２組の人たちが参加者たちにインタビューをすることができるため、私たちがより多様なデータを収集するのをサポートしてくれます。
複数の査定者たちが、これらのようなステーションで行われる各ユーザーリサーチセッションに参加します。
これらのセッションは短く、計画段階で決定された特定の目的を参考に構成されている傾向があります。全体のプロセスは２時間以内となっており、その間２つのステーションは10～12名の参加者たちとの話を組み合わせており、それぞれ約10分ほどかかっていました。
偏見は、無意識な提案を通した参加者たちの操作、または期待する行動を取りそうな人を選択するなど、様々な形態をとって現われる可能性があります。大英図書館のような、私たちの事務所の便利な立地となっている公共の場で検証を行うことは、学生や専門職、学者、そして一般的な学習者など、私たちがターゲットとしている層に当てはまる回答者の幅広い選択肢があることをサポートしてくれます。
複数の人たちに結果を分析してもらう
データの解釈もまた、偏見になりがちなものです。チェリーピッキングによる結果や、他の反応は無視して特定の反応に固執するといったものは、経験がない査定者によく見られる偏見です。
私たちが収集したデータの分析は、私たちのチームでは共同で行うタスクとなっています。少なくとも私たちのうちの２名がGoogle Docs上でメモを書き出し、私たちがSilverbackを利用して録画したセッションの動画を再度視聴します。
私たちのチームの大部分は、ユーザーテストの経験がありません。真っ白な紙を与えられて、自分の発見を理に適うものにするように依頼することは、脅威的であり、時間のかかる作業となるでしょう。なぜなら、皆何を探すべきか知らないのですから。よって、検証を担当しているデザイナーが、通常基礎となる、査定者たちに事実に基づいた質問を複数尋ねるGoogleフォームを作成します。私たちは以下の構成を活用しています：
・一般的な質問：参加者の名前、年齢層、技術的能力レベル、私たちの製品の精通度、そして職業。私たちはこれらの質問を参加者に一番最初に尋ね、それと並行して同意書に署名をしてもらいます。
・シナリオでのパフォーマンス：このセクションでは、各シナリオにおける参加者のパフォーマンスに関連した特定の質問を尋ねます。私たちは通常、いくつかの短い選択肢方式の質問を利用します。私たちのテストは短いので、複雑な評価スケールではなく、通常各回答に対して２～４つの選択肢を提供しています。そして査定者たちは、追加の情報やコメントを自由形式のテキストフィールドに提供することができます。
セッションの動画を視聴しながら、各査定者が記入したGoogleフォームからの引用。
これらのシンプルなフォームは、査定者による誤った解釈の可能性を減らし、経験のない査定者たちが自分たちの観察結果を共有しやすいようにサポートしてくれます。また、これらのフォームによって、どれくらいの人たちが問題に遭遇したか、どれくらいの頻度で遭遇したかといった、質的データの分析をサポートすることができます。ある特定のタスクを完了するのは、どれくらい簡単、または難しいのでしょうか？ ある特定の要素はどれくらいの頻度で期待、無視、または誤解されて使用されていましたか？
これらのフォームを使用して、査定者は通常各ステーションの参加者のうちの５名を、約１時間することができます。私たちはこの作業をできる限り早く、理想としてはセッションが行われた日に、観察結果がまだ私たちの記憶の中に鮮明に残っており、そしてその結果を過度に分析する可能性が生じる前に、行います。
査定者たちがフォームを提出すると、Google Docsは自動の回答要約を作成し、メトリクスや引用、各タスクのパフォーマンス、そしてその他の詳細情報を伴う生データが記載されています。
これらの回答と録画された動画、そして関係者全員のメモ書きに基づいて、担当デザイナーはチームの調査結果をまとめます。通常私は、別のスプレッドシートで全ての収集したデータを関連するテーマごとにグループ分けをしますが、これによって全てのデータを一目で確認することができ、また欠如していたり、無視されているものがないことを確かめることができます。
スプレッドシートにおけるデータのグループ分けと整理は、テーマとパターンの確認を容易にしてくれます。
この段階では、私たちは観察した行動における一般的なパターンを探しています。当然、異常値や矛盾も複数出てくるでしょう。私たちはこれらのデータを別に記録しておきます。私たちは定期的に調査を行っているので、時間の経過とともにこれらの異常値はつじつまが合うようになり、新しい、そして興味深いパターンを明らかにしてくれるのです。
その後私たちは、結果のまとめを書き出します。短い分量の文書で、これらのパターンとそれらがどのように私たちの研究の目的に対応しているかをまとめています。これには、タスクのパフォーマンスに関するメトリクスや記憶に残る引用、興味深い詳細データ、そしてチーム内で顕著となったその他の事項も含まれています。
結果のまとめは、それぞれのメモ書きが適切に含まれ、また解釈されていることを確認するために、研究チームと共有します。その後担当研究者は、全てをユーザーテスト報告書にまとめて、同社の他の部署と共有します。これらの報告書は通常、シンプルな構成となっている短いPDFファイル （12ページ以下） となっています：
・テストとタスク、そしてシナリオの目的：テスト計画からの内容。
・回答者：回答者層の短い概要 （一般質問セクションに基づく）。
・結果と観察：事前に記録されていた結果のまとめに基づく。
・結論：次の段階、またはの情報をどのように活用するべきかということに対する提案。
チームの中には報告書の作成に時間を費やすことを避けるチームもありますが、私たちはこの作業は有益であると思っています。私たちはその後の段階でこの報告書を見返すことが多く、このプロジェクトに関わっていなかった人々とこの報告書を共有することで、彼らが私たちの調査結果から多くを学ぶことができるのです。また、私たちはより短いプレゼンテーション用フォーマットによって、スプリントレビューで共有します。
シンプルながらも定期的に行う
短く、内容が詰まり過ぎていないセッションを定期的に行うことは、長く、詳細な検証をごくたまにしか行わないよりもずっと良いことです。また、セッションを迅速かつ繰り返し行うことで、１つの特定のアイデアに固執することを防ぐことができます。ある研究によると（PDF） 特定の手段に投資すればするほど、代替案を考えにくくなると言われており、これはユーザーテストを皆さんの意見の適切さの確認作業に変えてしまう可能性を高める可能性があります。
また、私たちはテストを効率的なものにするために学ぶ必要があり、そうすることでテストが進行中の工程に上手く適合するようになります。現在私たちは、2週間の期間の中で、２～３日以内に計画の作成、AxureまたはProto.ioでのプロトタイプの準備、検証、データの分析、そして報告書の作成を含むユーザーテストを行います。共同作業による協力的な研究は、研究に貢献している各個人の時間を重視し、成果物や引き継ぎ事項を通して情報のフィルターをかける作業に費やす時間を節約し、そして私たちの学びの質を高めるのに役立ちます。
研究に時間を費やす
研究を各スプリントに適合させることは、容易なことではありません。時には、私は誰かが研究結果だけを手渡してくれて、私はデータよりもデザインに集中することができればと願うことがあります。しかし、自分の仕事を定期的に検証することは、偏見を克服するための最も効果的な方法の１つでしょう。
後で判明する偏見は、興味深い例です。私たちは経験を積み、自分の過去の知識のレベルに対する認識が高まるほど、「自分は物事をはじめから知っている」と考えがちになります。これによって、デザイナーの中には経験が「ユーザビリティテストの必要性を減らす」と考えている人もいます。しかし、これに伴うリスクは、私たちのデザイン経験がターゲットオーディエンスとの共感的な繋がりを困難にし、彼らが私たちの製品を使用する時に直面する困難や問題に関連を持つことも困難にする可能性があるということです （そのため、自分が熟達している科目を誰かに教えるのがとても難しいものになっているのです）。
バース大学の経営科学の教授であるPaul Goodwin氏のおうな研究者たちによると、特に私たちが新しい知識を得ようと一生懸命取り組んでいる場合、<後で判明する偏見を克服することができる、最も効果的な既知の方法は、継続的な教育です （PDF）。
新しい知識を得るために努力をすることで、自分は「物事をはじめから知っている」と結論付けなくなります。対照的に、人々は新しい知識を受動的に、努力せずに受け取ると、自分は知識が豊富であると考えていました。
ユーザーテストに積極的に参加することは、私が知っている中で最も効果的な学習方法です。また、それは傲慢になることを回避し、私たちがデザインを構築する対象となっている人たちと関わりを持つ素晴らしい方法でもあります。偏見を最小限に抑える作業には、実践と誠実さ、そして協力が必要になります。しかし、それだけの価値があるのです。
