予約サービスのすべての画面についてチーム内で合意できていたとしても、それが本当に機能しているかどうかで見解が分かれることがあります。デザイナーは選択肢がグループ化されている理由を理解しており、エンジニアは送信後に何が起きるかを把握していますが、ユーザーはどちらの説明も持たずに訪れます。ユーザビリティテストは、チームがその様子を観察するなかで実際のタスクをユーザーに試してもらうことで、その「ユーザーの視点」を議論の場にもたらします。
有益な手がかりは、一見うまくクリックできた瞬間と、一見満足したような返答の間に隠れていることがよくあります。間違った日付で予約したことに気づかずに完了画面に到達する人もいれば、提示された価格に不信感を抱いて、完了できたはずのタスクを途中で諦めてしまう人もいます。その試行プロセスを観察することで、リサーチャーは完了を単なる「成功か失敗か」で片付けるのではなく、そうした差異を掘り下げて検証できます。
ユーザビリティテストでわかること
ユーザビリティテストは、特定の状況で人々が特定のデザインをどのように使うかを検証するものです。言葉の誤解、情報の不足、操作のしにくさ、そしてプロダクトの挙動がユーザーの期待とズレている箇所を明らかにできます。また、調査内で一貫した定義と記録が行われていれば、タスク完了率やエラー、主観的な使いやすさといった成果を測定することも可能です。
ただし、参加者がプロダクトをなんとか使えたからといって、それだけで需要があることの証明にはなりません。注意深く割り当てられたタスクを完了できたとしても、日常生活でそれを使いたいと思うとは限らないからです。根本的なニーズに関する問いは、ユーザーインタビューや既存の行動データ、その他のリサーチから得られるエビデンスとともに扱うべきものであり、インタラクションに関する問いこそがテスト自体で扱うべき領域です。
GOV.UKのモデレーター付きユーザビリティテストに関するガイダンスでは、その基本構造を「ユーザーがタスクを試し、リサーチャーがそれを観察する」と説明しています。この関係性を崩さずに維持することは、特に観察者がそのデザインの制作に関わっていた場合、想像以上に自制心が求められます。
デザインを使う「動機」を用意する
まずは、そのリサーチがどの意思決定に役立つべきか、という点から始めましょう。「新しいWebサイトをテストする」では、ほぼすべてが曖昧なままです。「たまに訪れるユーザーが、適切なチケットを選び、払い戻し条件を理解できるかを確かめる」と設定すれば、被験者選定、タスク作成、分析に共通の目的が生まれます。
架空の劇場で予約フローをテストする場面を想像してみてください。有効なタスクとしては、車椅子を利用する人を含むグループでの夜の観劇を、決められた予算内で、日程変更の可能性も考慮しながら手配してもらう、といったものが考えられます。このシナリオによって、どこをクリックすべきか指示することなく、アクセシビリティ情報やチケットの利用条件を確認する動機が生まれます。そのシナリオが適切かどうかは対象ユーザーによります。参加者に関連する経験があること、そしてサービスがサポートすべきアクセシビリティニーズを持つ人々がテストに含まれていることが重要です。
被験者を募集する前に、何をもって「成功」とするかを定義しておきましょう。単に何らかのチケットを購入することと、適切なチケットを購入し、総額を理解し、後から何を変更できるかを把握していることとは異なります。よく練られたタスクシナリオは、参加者に明確なゴールを与えつつ、そこに至るルートはユーザー自身に委ねます。
不確実性の性質に合わせて形式を選ぶ
モデレーター付きテストではリサーチャーがセッションに同席するため、追加の質問を投げかけたり、進行のサポートを行ったりできます。モデレーターなしのテストでは参加者が指示に沿って自力で進めるため、言葉遣いや技術的なセットアップの精度が特に重要になります。どちらの形式でも定性的な観察や定量的な測定は可能であり、モデレーターがいるかどうかによって、そのサンプルサイズが数値的な裏付けとして妥当かどうかが決まるわけではありません。
新しいインタラクションを検証する場合、小規模な探索的テストを行うだけでも改善すべき課題を特定できます。一方で、成功率を正確に見積もったり、複数バージョンを比較したりするには、適切なサンプルサイズと不確実性の統計的処理を含め、その目的に沿って設計された調査が必要です。「参加者5人中4人がここで手こずった」という結果を、安易に「全顧客の8割が同じ行動をとる」と捉えないように注意してください。
観察事実と解釈を切り離す
先ほどの劇場の例で言えば、参加者がアクセシビリティ情報を探す過程で、座席表を何度も開く場面があるかもしれません。ナビゲーションのラベルに原因があると決めつける前に、まずはその一連の操作手順と、参加者の発言を記録してください。座席のすぐ隣にアクセシビリティ情報があると思い込んでいるのかもしれませんし、別の場所の文言を誤解しているのかもしれません。あるいは、サイト上のどこにも掲載されていない情報を必要としている可能性もあります。
ファインディングが真に役立つのは、そのエビデンスが実際の影響や次の意思決定に結びついたときです。「ページがわかりにくかった」という報告では、チームは具体的にどう動けばいいかわかりません。「参加者は座席を選べたものの、そこに至るルートが段差なしで行けるかどうかを確認できなかった」と示せば、満たされていない具体的なニーズが浮き彫りになります。そうすれば、次のデザインでその課題に対処でき、その後のテストで変更が有効だったかどうかを検証できるようになります。