アーム代表の伊藤です。
現場から「使いにくい」と言われて直す側に回った。ただどこを直せば正解なのかが分からない。勘で作り直してまた「使いにくい」と言われるのが怖い。
ユーザビリティテストのやり方は突きつめれば一つです。対象に近い人を隣に座らせて黙って操作を見る。5人で足ります。大掛かりな調査の予算も専用の道具も要りません。ヤコブ・ニールセン氏の調査では、5人でおよそ85%の問題が見つかるとされています。
今日から回せるユーザビリティテストの5ステップ
- 手順は仮説→設計→被験者→実施→分析
- 意見を聞かず行動を見る
- 一度で終わらず直してまた回す
画面ごと作り直す前に、まず一人に操作してもらってください。原因が分からないまま作り直しても、詰まりは形を変えて残ります。ユーザビリティテストの手順は次の5つで、この順に回します。
「何を確かめたいか」を一文にする
目的が曖昧なテストは、見たいものが見えないまま終わります。「使いやすくしたい」ではなく、どの場面の何を確かめるかを一文にします。あわせて「たぶんこのボタンが分かりにくい」という仮説を立てておくと、当日の観察の焦点が定まります。
曖昧な目的 | 一文にした目的 |
|---|---|
使いやすくしたい | 登録途中の離脱原因を知る |
管理画面を良くしたい | 保存操作で迷わないか見る |
「登録してください」ではなく場面で渡す
ユーザビリティテストで被験者にやってもらう作業は、実際の利用状況に近い場面として渡します。「右上の登録ボタンを押してください」のように答えを含んだ指示を出すと、確かめたかった詰まりが消えます。タスクは3〜5個に絞ります。
渡し方 | 例 |
|---|---|
場面で渡す | 初めて使う人として申し込む |
場面がない | 登録してください |
答えを含む | 右上のボタンを押す |
対象に近い人を社内外から5人集める
ユーザビリティテストの理想は実際の想定ユーザーですが、最初の一歩なら対象に近い社内外の人で構いません。避けるのは、その画面を作った本人や仕様を知っている関係者です。フォームや入力周りを確かめるなら、入力フォームのUIデザインで挙げた観点をそのままタスクの確認項目にできます。
集める相手 | 判定 |
|---|---|
実際の想定ユーザー | 本番の精度 |
対象に近い社内外の人 | 最初の一歩なら十分 |
作った本人・関係者 | 詰まりが見えない |
意見を聞かず隣で黙って行動を見る
ここが本番です。意見を求めるのではなく、行動を観察します。頭に浮かんだことを声に出しながら操作してもらう「思考発話法」が向いています。沈黙や、マウスが宙で迷う数秒こそが何よりの情報になるので、可能なら画面と声を録画しておきます。
進行役がやる | 進行役がやらない |
|---|---|
考えを声に出してもらう | ヒントを出す |
画面と声を録画する | 答えを教える |
詰まった場所をメモ | 詰まっても手を貸す |
目の前で人が困っているのに黙っているのは、気まずいものです。それでも、助けた瞬間にテストは自分の答え合わせに変わります。
「誰が・どこで」つまずいたかで整理する
詰まった場所を「どのタスクの、どの画面で、何人が」で整理します。全員が同じ場所で止まったなら、それは個人差ではなく設計の問題です。見つかった詰まりを全部同時に直そうとせず、優先順位の高い1点だけ直して、また5人で試します。
5人のうち | 見立て |
|---|---|
4〜5人が止まった | 設計の問題。最優先 |
2〜3人が止まった | 次の回で再確認 |
1人だけ止まった | 個人差の可能性 |
今日揃えられる最低限の準備物
- 操作してもらう画面（本番でも試作でも可）
- タスクを書いた紙、または進行台本
- 画面と発話を録画できる端末（PCやスマホでも可）
- 進行役1人（できれば記録役をもう1人）
試作段階の画面でも、紙に印刷した画面でもテストはできます。アームの経験では、1回15分のユーザビリティテストでも改善点が見つからなかったことはありません。テストが怖いのは失敗ではなく、見つかった問題をどう活かせばいいか分からないからだ、という指摘もあります。
ユーザビリティテストは5人で足りるのか。その根拠
- 5人で使いにくさのおよそ85%が見つかる
- 15人1回より5人3回の方が多く潰せる
- 出典はニールセン氏2000年の調査
「たった5人で足りるのか」は最もよく聞かれる疑問です。答えは、5人で使いにくさのおよそ85%が見つかるから、です。ヤコブ・ニールセン氏の調査で示された数字で、被験者を増やしても同じ問題を何度も見つけるだけで、発見の効率は急激に下がります（出典: Nielsen Norman Group「Why You Only Need to Test with 5 Users」（2000年））。
だから、15人で一度だけ調べるより、5人で3回に分けて間で直しながら回すほうが多くの問題を潰せます。人数を追わず、回数で追う。これが小さく回すユーザビリティテストの核心です。
目的 | 人数の目安 |
|---|---|
問題を見つける（層が1つ） | 5人 |
ユーザー層が複数ある | 層ごとに3〜4人 |
カードソート | 15人 |
数字で優劣を比べる | 20人 |
5人で見つからない問題もある
ただし5人で見つかる85%は、同じユーザー層を前提にした推定値です。実務では、5人で十分だった案件と、5人で見つけたはずの問題が本番では様子が違っていた案件の両方が起こり得ます。「5人で足りる」は万能の数字ではなく、対象ユーザーが1つの層にまとまっているときの目安です。
テストが怖いのは失敗ではなく結果の扱い方
- 怖さの正体は見つかった問題の活かし方
- 直すのは優先順位の高い1点だけ
- 管理画面やフォームの改善と相性が良い
「テストが怖い」という声の多くは、設計ミスが見つかるのが嫌だからというより、見つかった問題をどう活かせばいいか分からないという不安から来ている、という指摘があります。作り直す側にとって、問題が増えるだけのテストは怖くて当然です。
対策はシンプルです。全部同時に直そうとしない。「誰が・どこで」つまずいたかで整理し、優先順位の高い1点だけ直して、また5人で試す。この往復を1回でも回せば、次に何を確かめればいいかの感覚がつかめます。この身軽さが、管理画面やフォームのような地味だが確実な改善と相性の良い理由です。
種類の選び方
- 軸は性質・場所・進行役の3つ
- 原因は定性、比較は定量で見る
- 小さく回すなら定性・リモート・進行役あり
ユーザビリティテストのやり方は一つではありません。目的と手元の予算で3つの軸から選びます。
軸 | 原因を知りたい | 数字で比べたい |
|---|---|---|
データの性質 | 定性 | 定量 |
実施の場所 | 対面・リモート | リモート |
進行役 | あり | なし |
小さく回す段階では、定性・リモート・進行役ありの組み合わせが最も始めやすいです。理由を深掘りでき、場所を選ばず、道具もほとんど要りません。細かい表情や手元まで見たいなら対面、数字で優劣を比べたくなったら定量や進行役なしを足していきます。
よくある失敗と誤解
- 誘導した時点で問題は隠れる
- 一度きりでは改善効果を確認できない
- 感想でなく手が止まった行動を記録
口を出すと問題が隠れる
被験者が詰まると進行役は助けたくなります。しかし「そこは右上ですよ」と言った瞬間、テストは自分の答え合わせに変わります。黙って見る勇気が何よりの技術です。
一度で終えると測れない
ユーザビリティテストは、作って試して直す往復で価値が出ます。一度やって満足すると、直した結果が良くなったのかを確かめられません。改修の節目ごとに小さく繰り返すのが前提です。
「良かった」は使えない
見るべきはどこで手が止まったかという行動です。良い評価に安心せず、詰まった数秒を記録します。
よくある質問
社内の人に頼んでも意味がありますか？
本番の精度は実ユーザーに劣りますが、明らかな詰まりは社内の一人でも見つかります。まず回すことを優先し、重要な意思決定は実ユーザーで確かめます。
アンケートやアクセス解析とどう使い分けますか？
アクセス解析は「どこで離脱したか」は分かっても「なぜか」は分かりません。理由を知りたいときにユーザビリティテストの出番です。
ユーザビリティテストのやり方は、5人で小さく回し今日の一人から始まる
- 対象に近い5人を隣に座らせて黙って操作を見る
- 目的を一文にしタスクは答えを含まない場面で3〜5個渡す
- 全員が止まった1点だけ直してまた5人で試す
