ラボなしでできるユーザビリティテスト：初心者向けガイド

FabricLoopチームによる  ·  2026年5月  ·  4分で読めます

ユーザビリティテストには、「高くて時間がかかる」という不当な評判があります。「ユーザーリサーチ」と聞くと、多くの人はマジックミラー越しの観察室、クリップボードを持つモデレーター、2週間にわたるスケジュールを思い浮かべます。そうしたテストも存在し、用途もあります。しかし、ほとんどの製品チームが、ほとんどの場面で必要としているのは、そちらではありません。

多くのチームに必要なのは、もっとシンプルなやり方です。5人のユーザー、Figmaのプロトタイプまたはステージング環境、ビデオ通話、1セッション45分。これをうまく実施すれば、リリース前に深刻なユーザビリティ上の問題の大半を洗い出せます。そして、スプリントごとに1回でも継続して行えば、製品の品質が複利的に向上します。これはリリース後のどんな分析でも再現できません。

ゼロから実施する方法を紹介します。

テストセッションの4ステップ

ステップ1：リクルート——何人かより、誰をテストするかが重要

ほとんどのユーザビリティテストでは、参加者5人が適切な人数です。Jakob Nielsenの研究では、5人のユーザーでユーザビリティ上の問題の約85%が見つかり、それ以降は得られる効果が逓減することが示されました。デザインの過程の異なる時点で5人ずつ3回のセッションを行うほうが、15人を一度にテストするよりも価値があります。

募集の基準は、人数よりも重要です。ターゲットユーザーによく合致する5人のテストなら、実際の問題が見えてきます。合致しない15人のテストでは、ノイズが生じるだけです。役割、利用状況、技術への慣れ具合などから、スクリーニング基準を2～3個決め、それを守りましょう。

多くのチームにとって最も早い募集方法は、連絡を許可している既存ユーザーにメールを送ることです。謝礼は控えめで構いません。45分のセッションなら、£20のギフトカードで十分です。募集からテストまでの間隔が空くほど、無断欠席率が上がるため、同じ週のうちに日程を組むことを目指しましょう。

ステップ2：台本——指示ではなく、シナリオで

台本づくりで最もよくある間違いは、タスクを指示として書いてしまうことです。「設定をクリックして、通知に移動し、設定を...に変更してください」。これではユーザーに何をすべきかを教えているだけで、テストしているのは指示に従えるかどうかです。インターフェースが直感的かどうかではありません。

代わりに、タスクをシナリオとして書きましょう。「通知が多すぎるので、自分が直接メンションされたときだけ通知を受け取りたいとします。どうするか見せてください。」これならユーザーに現実的なゴールを与えられ、実際にどう操作するかを観察できます。どこで迷うかも含めてです。

ステップ3：実施——あなたの役目は見ること、助けることではない

ユーザビリティテストの進行で最も難しいのは、手を貸したくなる衝動を抑えることです。ユーザーが戸惑っていると、本能的に割り込んで、どこをクリックすればよいか教えたくなります。しかし、戸惑いこそがデータです。苦労しているユーザーは、インターフェースに何か問題があることを教えてくれています。介入した瞬間に、そのシグナルは失われます。

セッション中は、ずっと考えていることを声に出してもらいましょう。「進めながら、見ているものと考えていることを話してください」。これで、ユーザーのメンタルモデルに関するデータが途切れず得られます。エラーだけでなく、ためらいも記録してください。正しいボタンを押す前に3秒間止まったユーザーは、最終的に成功したとしても、デザイン上の問題を示しています。

ステップ4：分析——引用ではなく、パターンを見つける

分析のステップは、価値の大半が生まれる場面であり、多くのチームが手を抜く場面でもあります。5回分のセッションの生のメモは、まだ調査結果ではありません。チームで振り返り、観察内容をテーマ別に整理し、深刻度を割り当てて初めて、調査結果になります。

セッションと同じ日の、観察の記憶が新しいうちに振り返りを行いましょう。問題は3つに分類します。重大（ユーザーがタスクを完了できなかった）、中程度（完了したが、かなりの困難やエラーがあった）、軽微（完了は妨げなかった摩擦）。重大な問題はリリース前に修正する必要があります。中程度の問題は次のスプリントで優先的に対応します。軽微な問題はバックログに入れます。

調査結果は1ページにまとめます。重大な問題の上位3つについて、それぞれ少なくとも2人の参加者の根拠と、デザイン変更の提案を添えます。それ以上のスペースが必要な内容は、別のドキュメントに分けます。