ユーザビリティ調査の規模を決定する4つの方法と、5ユーザールールが破られる場合

ユーザビリティ調査の規模を決定する4つの方法と、5ユーザールールが破られる場合

チームの誰かが、ユーザー5人で十分だと言っています。彼らは1993年のモデルを引用していますが、そのパラメータについては言及していません。ローラ・フォークナーの2003年の研究では、60人の参加者から無作為に5人を選んだところ、同じインターフェース、同じタスク、同じモデレーターで、既知の問題の55%から99%が見つかりました。得られる人数は、誰が参加するかによって変わります。

このガイドは、研究開始前に被験者募集人数を説明する必要のある研究者、プロダクトマネージャー、CROリーダーを対象としています。このガイドを読み終える頃には、4つの被験者数算出方法から1つを選び、その根拠となる仮定を述べ、その人数でどの程度の課題解決が見込めるかを説明できるようになります。このガイドは、被験者数を増やすよう指示するものではありません。5人という人数が妥当な回答なのか、それとも単なる推測なのかを判断するのに役立ちます。

5ユーザーという数字の由来

ニールセンとランダウアーは問題発見を次のようにモデル化した。 N x (1 - (1 - p)^n): と N 設計上の問題、 p いずれかの参加者が特定の問題に当たる確率、そして n 参加者の皆様、見つけた問題の割合は 1 - (1 - p)^n彼らはデータセット全体で平均p値を0.31と測定しました。p=0.31の場合、5人の参加者で84.4%のカバー率に達します。これが「5人のユーザーが問題の85%を発見する」という表現の由来です。

言い換えると、2つの点が抜け落ちます。まず、四捨五入です。p = 0.31 の場合、85% を達成するには 5 人ではなく 6 人の参加者が必要です。次に、より重要な点として、p は自然界の定数ではありません。Virzi は 0.32 を測定し、Lewis は別のシステムで 0.16 を測定しました。また、Spool と Schroeder は、自由形式の e コマース タスクに数十人の参加者が参加した後でも、深刻な問題が依然として発生していることを発見しました。この主張の正直なバージョンは条件付きです。5 人、10 人、20 人の参加者が、4 つの問題発生率で発見した内容は次のとおりです。

問題発生率(p)5個見つかりました10個見つかりました20個見つかりました
0.31 (ニールセンとランダウアーの平均)84%98%99.9%
0.16(ルイス)58%83%97%
0.10(まれな問題)41%65%88%
0.05(まれに発生する、重篤な問題)23%40%64%

次の企画会議の前に、一番下の行を読んでください。レジ業務を台無しにする問題は、たいてい5人中4人がつまずくようなものではありません。それらは何年も前に解決済みです。

方法1:固定5回を頻繁に繰り返す

5人の参加者で実行し、見つかった問題を修正し、次のビルドでさらに5人実行します。ニールセンの主張は、5人で統計的に十分だということではありませんでした。限界ユーザーの価値は限界ユーザーの価値よりも低いということです。 研究.

次の場合に使用します: あなたは毎週変更されるデザインを反復的に改善しており、インターフェースは十分に新しいため、ほとんどの問題は共通しており(発生率が高い)、実際にラウンド間で修正をリリースすることができます。

次のような場合に失敗します。 この調査は一度限りの監査であり、繰り返すことはありません。調査結果は関係者に渡され、「他に問題は見つかりませんでした」という結果が品質の証拠として扱われるか、あるいは製品が成熟しており、残りの問題は定義上まれである、ということになります。

方法2:発見目標に基づくサイズ決定

モデルを反転します。必要なカバレッジ (P) と期待される発生率 (p) を選択し、次に解きます。 n = ln(1 - P) / ln(1 - p).

カバレッジ目標p = 0.31p = 0.16p = 0.10p = 0.05
85%6111937
90%7142245
95%9182959

次の場合に使用します: この調査は、コンプライアンス、法的、またはローンチゲートの目的があり、対象範囲を文書で明記する必要があります。また、エラー回復パスなどの特定の種類の低頻度障害を調査する場合にも、同様の手順が必要です。

次のような場合に失敗します。 pには根拠がありません。公表されている平均値だからといって0.31を選ぶのは、数式を衣装として身に着けて5を選ぶのと同じことです。

方法3:最初のラウンドからpを推定し、その後サイズを変更する

これは私たちがデフォルトで採用している方法です。なぜなら、推測値をユーザー自身のデータに置き換えるからです。

  1. まず5問のラウンドを実施する。それぞれの問題を記録し、どの参加者が正解したかを記録する。
  2. 観測されたp値を、すべての異なる問題における(問題に当たった参加者数/走った参加者数)の平均値として計算します。
  3. 過大評価を避けるべきです。初期サンプル数が少ないと、pの値が体系的に過大評価されてしまいます。なぜなら、たった一人しか遭遇していない問題は、まだ遭遇していない問題だからです。ヘルツムとヤコブセンはこの過大評価を実証しました。実際的な修正策としては、再推定時に、たった一人しか遭遇していない問題を分子から除外することです。
  4. 圧縮されたp値を上記の表の目標カバレッジ値に入力し、その差を求めます。

判断ポイント:デフレートされたpが0.25を超える場合は、5~8人で調査を終了し、残りの予算を別のフローに関する2回目の調査に充てます。0.10~0.25の間であれば、12~18人に拡大します。0.10を下回る場合は、タスクが広すぎるか、セグメントが広すぎる可能性があり、参加者を追加してもどちらも解決しません。再募集する前に、調査範囲を再検討してください。

次のような場合に失敗します。 段階的に被験者を募集することはできない。また、研究の進行役がラウンドごとに異なる人物になると、記録される問題が変わってしまう。

方法4:行動セグメント別サイズ

このモデルは単一の母集団を想定しています。しかし、この地域のほとんどの製品には単一の母集団は存在しません。トルコ国内、EU、湾岸諸国に越境販売を行う小売業者は、少なくとも3つの異なるメンタルモデル、異なる支払い期待、そして湾岸諸国の場合は右から左へのインターフェースを持つグループを抱えています。ニールセンのガイダンスでは、2つのグループでは1グループあたり3~4人、3つ以上のグループでは1グループあたり3人の参加者が推奨されています。これは最低限の人数であり、目標ではありません。つまり、3つのセグメントにわたる「5人のユーザーによる調査」は、実際には検出力の低い3つの調査ということになります。

スクリーニングテストを作成する前に適用すべき2つのルール:

  • 人口統計ではなく、行動に基づいてセグメント化する。 初めて住宅を購入する人と、買い直しをする人は、それぞれ異なる問題に直面する。25歳から34歳、そして35歳から44歳の年齢層は、通常、そうした問題に直面しない。
  • EUで販売する場合は、支援技術の利用者を独立した顧客層として扱うべきです。 欧州アクセシビリティ法は2025年6月28日から消費者向け電子商取引サービスに適用されており、視覚障害者のみを対象としたサンプル調査では、自社のサービスが同法に準拠しているかどうかを判断することはできません。スクリーンリーダーやキーボードのみを使用する参加者は、視覚障害者の参加者をどれだけ増やしても明らかにならない種類の問題を発見します。

あなたの研究にはどの方法が最適ですか?

これが本当なら 典型的なn
毎週の反復作業、デザインはまだ進行中方法11ラウンドにつき5
書面による保険適用請求を伴う単発監査方法211-29
段階的に採用することができ、最も安価で防御可能な数を求めることができる方法35、次にサイズを変更します
2つ以上の異なる行動グループ方法41グループにつき最低3~4名
問題リストではなく、信頼区間付きの指標が必要です。どれでもない20歳以上(下記参照)

実例

この例は説明のためのものであり、クライアントの事例ではありません。たとえば、中規模のトルコのファッション小売業者(国内トラフィックのみ、リデザインは既に稼働中)のチェックアウト調査の規模を決定するとします。方法1はデザインが既に出荷されているため除外され、方法2は必要なアプリがないため、方法3は方法4によってシードされます。

ゲストチェックアウトとログインリピーターの2つの行動セグメントに、それぞれ4人の参加者がいます。第1ラウンドでは19の異なる問題が発生し、そのうち11はちょうど1人の参加者によって確認されました。生のpは0.28です。分子から単独の参加者を除外すると、約0.17に低下します。90%のカバレッジ目標とp = 0.17の場合、表では14となっています。8人が参加しているので、発見が少ないセグメントに重点を置き、さらに6人を募集します。

合計:14名(人数の理由を記載した書面あり)。 [INTERNAL DATA NEEDED: observed p values from Switas's own e-commerce checkout studies, to replace the illustrative 0.17 with a benchmark range by vertical.]

これが破綻するところ

二項モデルは、問題が独立しており、p が参加者間で安定していると仮定しています。しかし、どちらも正しくありません。1 つの紛らわしいラベルが 3 つの下流障害を引き起こし、マーケットプレイスの UI パターンに精通している参加者とそうでない参加者では、直面する問題が異なります。上記の数値は、測定値ではなく、計画ツールとして扱ってください。Woolrych、Cockton、Caulton は皆、単一の p ではサブグループで構成される母集団を誤って表現してしまうと主張しています。

このガイドでは以下の内容は扱っていません。

  • 定量的なベンチマーク。 信頼区間付きのタスク成功率を求めたい場合は、別の質問に答えることになります。少なくとも20人の参加者を計画し、信頼区間を狭くする場合はさらに多くの参加者を確保してください。
  • カードの分類とツリーテスト。 ニールセンは、ユーザーグループごとに少なくとも15人を推奨している。問題発見の数学は適用されない。
  • 視線追跡。 安定したヒートマップを作成するために、約39名の参加者が必要でした。
  • A/Bテスト。 サンプルサイズは、コンバージョン指標における統計的検出力に関わるものであり、問​​題発見に関わるものではありません。計算式も論理も異なります。

もう一つ、指摘しておくべき限界点があります。それは、タスク設計によってpの成果がnの成果を上回るということです。明確で現実的なタスクであれば、5人の参加者は、曖昧なタスクであれば12人の参加者よりも多くの成果を上げることができます。タスク作成に関する話し合いよりも、参加者数の規模決定に関する話し合いの方が長引く場合は、この比率が間違っていると言えるでしょう。

FAQ

5人までという制限は間違っているのだろうか?
いいえ、それは条件付きです。問題発生率が0.31付近、カバレッジ目標が85%付近の場合に有効です。これらの条件以外では期待を下回り、元の論文でもそれとは異なる主張は一切されていません。

何も実行する前にpを推定するにはどうすればよいですか?
ほとんどの場合、正確な値は得られません。だからこそ、方法3が存在するのです。どうしても推測する必要がある場合は、新規または大幅に変更されたインターフェースには0.30、成熟したインターフェースには0.15を使用し、1回目のラウンド後に修正してください。

審査ありのテストと審査なしのテストでは、受験者数に違いが出るのか?
数学的な意味ではなく、何が問題としてカウントされるかが変わります。モデレートされていないセッションでは、失敗の背後にある原因が見落とされがちで、個別の問題の数が膨らみ、観測された p が小さくなります。

もし5人しか採用できなかったらどうすればいいですか?
5回実施し、問題リストが完全であると報告するのではなく、網羅範囲を正直に報告してください。網羅できなかったセグメントを明記してください。制限を明示した小規模な調査は有用ですが、網羅的であるかのように提示された小規模な調査は有用ではありません。

アクセシビリティテストには、もっと参加者が必要ですか?
異なる参加者が必要です。支援技術の利用者は、既存のサンプルに追加するのではなく、3~4人程度の独自の最低人数を持つ、独立した行動セグメントです。

AIが生成した合成参加者は、このサンプルの一部を置き換えることができるだろうか?
これらは、タスクやスクリーニングの練習に役立ちます。しかし、問題発生率を算出することはできません。なぜなら、pは実際の集団における実際の行動特性だからです。合成セッションを分母に含めないでください。

同じ計算方法は、B2B製品や公共部門向け製品にも適用できるのでしょうか?
計算上はそうなりますが、採用活動はそうではありません。狭いB2Bセグメントや公共部門では、接触可能な参加者が6人または8人に制限されることがよくあります。その場合は、人数が意図的に選ばれたかのように装うのではなく、調査上の制約として上限を明記してください。

次の研究でこれを実行してください

これから説明する研究について、使用する4つの方法のうちどれを使用するか、また想定するp値を書き留め、両方を研究計画書に記入してください。どちらも書き留めても残らない場合は、それが結果です。サイズ計算、スクリーニング、セグメント設計を代行してもらいたい場合は、 次の調査ラウンドについては、Switasにご相談ください。.

ソース


関連記事

スウィタス

Magnify: Engin Yurtdakul によるインフルエンサー マーケティングの拡大

Microsoft Clarityのケーススタディをご覧ください

Microsoft Clarityは、Switasのような企業が直面する課題を理解している、実際のプロダクト担当者によって、実用的で現実的なユースケースを念頭に構築された製品として高く評価されました。レイジクリックやJavaScriptエラー追跡といった機能は、ユーザーの不満や技術的な問題を特定する上で非常に役立ち、ユーザーエクスペリエンスとコンバージョン率に直接影響を与える、的を絞った改善を可能にしました。