新しい画面を公開したあと、サポートに「どこから登録すればよいのか分からない」という問い合わせが続く。商談で画面を見せると、相手の手が止まる。社内では誰も迷わなかったのに、なぜ伝わらないのかが分からない。
こうした場面で役に立つのが、ユーザビリティテストです。ただ、調べてみると、専用の部屋や録画の機材、専門の担当者を前提にした説明が多く、「うちの人数ではできない」と感じて手をつけないままになっていることも少なくありません。
実際には、ユーザビリティテストは少人数の体制でも十分に回せます。必要なのは、確かめたい場面を1つ決めること、5人前後の協力者、そして、相手が迷っていても手を出さずに見ていることの3つです。
本記事では、専任のリサーチャーやデザイナーがいない体制で、プロダクトの判断を担っている方に向けて、作った画面が使えるかを自分たちで確かめる方法を、5つのステップで解説します。
ユーザビリティテストとは何か
ユーザビリティテストとは、利用者に近い人に実際に画面を操作してもらい、その様子を見て、つまずく場所を見つける方法です。意見を聞く場ではなく、行動を見る場である点が特徴です。
よく似たものにユーザーインタビューがありますが、確かめる内容が異なります。
| ユーザーインタビュー | ユーザビリティテスト | |
|---|---|---|
| 確かめること | 相手が何に困っているか | 作った画面で、目的を果たせるか |
| 主に使うもの | 質問 | 画面と課題 |
| 見るもの | 相手の話と、その背景 | 相手の操作と、止まった場所 |
| 向いている時期 | 何を作るかを決める前 | 作っている途中から、公開したあと |
インタビューで「この機能があれば使いますか」と尋ね、「使います」と答えてもらっても、実際の画面でその機能にたどり着けるかどうかは分かりません。反対に、ユーザビリティテストでは、その機能がそもそも必要とされているかどうかは分かりません。2つは代わりになるものではなく、確かめたいことに応じて使い分けます。
作った本人には、つまずく場所が見えない
社内で確認したときには問題がなかったのに、利用者は迷う。これは、確認が甘かったからではありません。
画面を作った人は、その画面に何があるのかを知っています。ボタンの名前の意味も、次に何が起こるのかも、知ったうえで見ています。知っていることを、知らなかったことにして画面を見るのは、誰にとっても難しいことです。
プロダクトの判断を自分で担っている場合は、この傾向がさらに強まります。画面の構成を決めたのが自分であれば、その構成は自分にとって最も自然なものだからです。
だからこそ、初めてその画面を見る人に操作してもらい、その様子を見る必要があります。つまずく場所は、考えて見つけるものではなく、見て見つけるものです。
少人数の体制でも回せる3つの理由
1. 協力者は5人前後で足りる
ユーザビリティテストは、アンケートのように多くの回答を集めて割合を出すものではありません。目的は、つまずく場所を見つけることです。
大きな問題は、最初の数人でほぼ出そろいます。5人前後に見てもらえば、主な問題の多くが見つかるという目安は、この分野で広く知られています。3人目あたりから「また同じ場所で止まった」という場面が増え、5人を終えるころには、直すべき場所がはっきりしてきます。
20人に1度見てもらうよりも、5人に見てもらい、直して、また5人に見てもらうほうが、画面は良くなります。
2. 特別な設備は要らない
必要なものは、操作してもらう画面と、それを映す手段だけです。対面であれば、パソコンかスマートフォンを1台用意し、横に座ります。離れた場所にいる相手であれば、ふだん使っているオンライン会議の画面共有で足ります。
録画は、相手の了承を得られれば残しておくと便利ですが、なくても進められます。記録の担当が1人いれば、その場のメモで十分です。
3. 完成した画面でなくてもよい
確かめるのは、開発が終わった画面である必要はありません。デザインの案をつなげた試作や、紙に描いた画面でも、「次にどこを押すと思いますか」と尋ねることで、多くのことが分かります。
むしろ、早い時期に確かめるほど、直すための手間は小さくて済みます。開発が終わってから構成の問題が見つかると、作り直しの範囲が大きくなるためです。
少人数で回すユーザビリティテストの5つのステップ
ここからは、具体的な進め方を5つのステップで説明します。
ステップ1：確かめる場面を決める
最初に決めるのは、「どの画面を見てもらうか」ではなく、「誰が、何をできればよいか」です。
「設定画面を見てもらう」と決めると、相手は画面を眺めて感想を述べることになり、使えるかどうかは分かりません。「初めて利用する経理の担当者が、請求書を1件作って送れるか」と決めると、見るべきことがはっきりします。
1回のテストで確かめる場面は、1つか2つに絞ります。選ぶ目安は次のとおりです。
- 初めての利用者が、最初に必ず通る場面
- 問い合わせが多い場面
- 売上や継続に直結する場面
- 近く公開する予定の、新しい場面
あれもこれもと欲張ると、1人あたりの時間が長くなり、協力者も見る側も疲れます。1回は小さく、回数を重ねる前提で考えます。
ステップ2：課題を作る
次に、協力者にお願いする課題を作ります。課題とは、「この画面で、これをしてみてください」という依頼のことです。
ここで最も大切なのは、操作ではなく目的で頼むことです。
| 避けたい頼み方 | 望ましい頼み方 |
|---|---|
| 「右上の『新規作成』から、請求書を作ってください」 | 「取引先のA社に、10万円の請求書を送ってください」 |
| 「メンバー招待の機能を使ってみてください」 | 「同じ部署の同僚にも、この画面を見られるようにしてください」 |
| 「絞り込みを使って、先月分を表示してください」 | 「先月、いくら請求したのかを調べてください」 |
左の頼み方には、画面に書かれている言葉がそのまま入っています。これでは、協力者は同じ言葉を探すだけになり、その言葉が利用者に通じるのかどうかを確かめられません。右のように、相手の仕事の中で起こる状況として伝えます。
課題は、1つの場面につき3個から5個に絞ります。あわせて、課題ごとに「何ができたら達成とするか」を決めておきます。「請求書が送信済みの状態になっていること」のように、見て判断できる形にしておくと、あとで結果を整理しやすくなります。
課題ができたら、社内の誰か1人に試してもらいます。課題の文が分かりにくい、用意したデータが足りない、といった準備の不備は、ここで見つけておきます。
ステップ3：5人前後に頼む
協力者は、実際の利用者に近い人から選びます。優先する順は次のとおりです。
- 既存の顧客：関係のある顧客に、改善のために30分ほど時間をもらえないかとお願いします。サポートや営業の担当者から声をかけてもらうと、応じてもらいやすくなります
- 見込みの顧客に近い立場の人：同じ職種や業種の知人、取引先の担当者などです
- 社内で、その画面に関わっていない人：開発にも設計にも関わっていない、管理部門や営業の担当者です
3は、利用者そのものではないため、仕事の流れに関わる問題は見つかりにくくなります。それでも、ボタンが見つからない、言葉の意味が通じないといった問題は見つかります。誰にも頼めないからと何もしないよりも、社内の人に見てもらうほうが、はるかに多くのことが分かります。
お願いするときは、次の3点を伝えます。
- かかる時間（30分から45分が目安です）
- 試されるのは画面であり、相手ではないこと
- 録画や記録をする場合は、その目的と、社内での改善にのみ使うこと
お礼は、相手との関係に応じて決めます。既存の顧客であれば、改善した結果をあとで報告することが、何よりのお礼になることもあります。
ステップ4：黙って見る
当日は、進行する人と、記録する人の2人で臨むのが理想です。1人しかいない場合は、相手の了承を得て録画し、進行に集中します。
始める前に、次のことを伝えます。
- 「画面が使いやすいかを確かめるためのもので、あなたを試すものではありません」
- 「うまくいかない場所があれば、それは画面の側の問題です」
- 「考えていることを、できるだけ声に出しながら操作してください」
そのうえで課題を渡し、あとは黙って見ます。5つのステップの中で、ここがいちばん難しいところです。
相手が迷っていると、「そこではなくて、こちらです」と言いたくなります。自分で作った画面であれば、なおさらです。しかし、手伝った瞬間に、その場面で利用者が1人で進めるのかどうかは分からなくなります。実際の利用者の横には、作った人は座っていません。
相手が止まったとき、あるいは助けを求められたときは、答えを伝える代わりに、次のように尋ねます。
- 「いま、何を探していますか」
- 「この画面で、次に何が起こると思いますか」
- 「もしここに誰もいなかったら、どうしますか」
数分たっても進めない場合は、「ここはいったん飛ばして、次に進みましょう」と切り上げます。進めなかったという事実が、そのまま結果になります。
記録するのは、次の3つです。
- 止まった場所：どの画面の、どの操作で止まったか
- そのときの言葉と行動：何と言ったか、どこを押そうとしたか
- 課題を達成できたか：1人でできた、迷ったができた、できなかった、の3つに分ける
「分かりにくいと感じているようだ」といった解釈は、この時点では書きません。見たことと聞いたことを、そのまま残します。
最後に5分ほど、「いちばん迷ったのはどこでしたか」「ふだんの仕事では、ここをどう進めていますか」と尋ねて終わります。
ステップ5：直して、もう一度確かめる
全員のテストが終わったら、その日のうちか翌日に、記録をまとめます。日がたつと、細かな様子を忘れてしまうためです。
まとめ方は、止まった場所ごとに、何人が止まったかを数えるだけで足ります。
| 止まった場所 | 止まった人数 | 課題への影響 |
|---|---|---|
| 請求書の作成を始めるボタンが見つからない | 5人中4人 | 2人が達成できず |
| 「下書き」と「保存」の違いが分からない | 5人中3人 | 迷ったが達成 |
| 送信後に、送れたかどうかが分からない | 5人中2人 | 達成したが、不安の声あり |
| 取引先の検索で、略称が使えない | 5人中1人 | 迷ったが達成 |
直す順番は、止まった人数が多く、課題を達成できなかったものからです。1人だけが止まった場所は、記録に残したうえで、次のテストでも起こるかを見ます。
直し方を考えるときは、協力者が口にした「こうしてほしい」をそのまま採用するのではなく、止まった理由に戻って考えます。「ボタンを大きくしてほしい」という声の背景が、「請求書を作る入口が、一覧の中に埋もれていた」ことであれば、直すべきなのは大きさではなく、置き場所かもしれません。
デザイナーに直しを依頼する場合は、止まった場所と、そのときの協力者の言葉や行動を、あわせて伝えます。
そして、直したあとに、別の3人から5人でもう一度確かめます。直したつもりの場所で、新しいつまずきが生まれていることがあるためです。同じ人にもう一度お願いすると、前回の記憶で進めてしまうため、協力者は入れ替えます。
1週間で回す場合の進め方
5つのステップは、ほかの仕事と並行しながら、1週間ほどで回せます。次の表は、その一例です。
| 日 | すること | かかる時間の目安 |
|---|---|---|
| 1日目 | 確かめる場面を決め、協力者に依頼する | 1時間 |
| 2日目 | 課題を作り、社内の1人で試す | 1時間から2時間 |
| 3日目 | 2人から3人に実施する | 1人あたり45分 |
| 4日目 | 残りの2人から3人に実施する | 1人あたり45分 |
| 5日目 | 記録をまとめ、直す場所と順番を決める | 1時間から2時間 |
協力者の都合で日程が空く場合は、3日目と4日目を翌週にずらします。大切なのは、実施から記録のまとめまでの間を空けないことです。
慣れてくると、準備にかかる時間は短くなります。課題の文や、始める前の説明、記録の表は、一度作れば次回も使えるためです。
よくある失敗
- 迷っている相手に、使い方を説明してしまう：最も起こりやすい失敗です。説明した時点で、その課題の結果は使えなくなります。どうしても口を出してしまう場合は、進行をほかの人に任せ、自分は記録に回ります。
- 「この画面、どう思いますか」と感想を尋ねる：感想を尋ねると、相手は気を遣って「見やすいです」と答えます。確かめたいのは、好みではなく、目的を果たせるかどうかです。
- 課題の文に、画面の言葉を入れてしまう：ステップ2で述べたとおり、ボタンの名前を課題に入れると、言葉が通じるかどうかを確かめられません。
- 協力者の提案を、そのまま仕様にする：協力者が教えてくれるのは、どこで困ったかです。どう直すかは、困った理由をもとに、作る側が考えます。
- 1度きりで終わらせる：大がかりな1回よりも、小さな繰り返しのほうが効果があります。新しい画面を出す前の習慣にできると、公開後の問い合わせや作り直しが減っていきます。
- 見つかった問題を、すべて直そうとする：1回のテストで、10個以上の問題が見つかることもあります。多くの人が止まり、課題を達成できなかったものから順に、手をつける数を絞ります。
具体例：問い合わせが続いていた画面を見直したケース
従業員12名、小規模な事業者向けの予約管理サービスを提供するスタートアップを想定した例です。プロダクトの判断は経営者が担い、エンジニア3名、業務委託のデザイナー1名、サポート1名という体制でした。
導入した店舗から、「予約の受付を始める方法が分からない」という問い合わせが、月に十数件届いていました。経営者は、ヘルプページに手順を書き足して対応していましたが、問い合わせは減りませんでした。
そこで、「初めて利用する店舗の担当者が、登録から予約の受付開始までを1人で進められるか」を確かめることにしました。課題は、「あなたは美容室の店長です。来週の月曜日から、インターネットで予約を受け付けられるようにしてください」など4個です。協力者は、導入して間もない顧客2名、経営者の知人で店舗を運営している2名、社内の管理部門の1名の、あわせて5名でした。
経営者は進行を担当しましたが、1人目で、相手が迷うたびに説明を始めてしまったため、2人目からは進行をサポートの担当者に任せ、自分は記録に回りました。
5名の結果をまとめると、次のことが分かりました。
- 5名中4名が、営業時間を登録したあと、「これで受付が始まった」と考えて手を止めた。実際には、別の画面で「公開する」を押す必要があった
- 5名中3名が、「メニュー」という言葉を、画面の案内のことだと受け取り、提供するサービスの登録だとは気づかなかった
- 5名中1名が、定休日の設定を見つけられなかった
ヘルプページに書き足していた手順は、いずれも正しい内容でした。ただ、利用者は「まだ終わっていない」と気づいていなかったため、ヘルプページを開く理由がありませんでした。
直したのは2点です。営業時間を登録したあとの画面に、「受付の開始まで、あと1つです」という案内と、公開の画面へ進むボタンを加えました。また、「メニュー」を「提供するサービス」に改めました。定休日の設定は、1名のみであったため記録に残し、次回に確かめることとしました。
2週間後、別の4名で同じ課題を試したところ、全員が受付の開始まで1人で進めました。翌月、同じ内容の問い合わせは3件に減ったという想定です。準備から最初のまとめまでにかかった時間は、関わった3名の合計で、およそ10時間でした。
よくある質問（FAQ）
Q1. 協力してくれる顧客が見つかりません。
まずは、社内でその画面に関わっていない人にお願いするところから始めます。あわせて、サポートに問い合わせをくれた顧客に、「改善のために、30分ほど画面を操作する様子を見せていただけませんか」と声をかけてみてください。困った経験のある方は、協力してくださることが少なくありません。
Q2. 自分が進行すると、どうしても口を出してしまいます。
作った本人ほど、そうなりやすいものです。進行をほかの人に任せ、記録に回るのが確実です。1人で行う場合は、「止まったら10秒待つ」「答える代わりに『いま何を探していますか』と尋ねる」と、あらかじめ決めておくと抑えやすくなります。
Q3. 5人では少なすぎるのではないでしょうか。
「利用者の何割が迷うのか」を正確に知りたい場合は、5人では足りません。しかし、「どこでつまずくのか」を見つける目的であれば、5人前後で十分に役立ちます。利用者の層が大きく異なる場合、たとえば管理者と一般の利用者がいる場合は、層ごとに3人から5人ずつ見てもらいます。
Q4. 開発が終わる前に行うのと、公開したあとに行うのと、どちらがよいでしょうか。
どちらにも意味がありますが、1度だけ行うのであれば、開発に入る前の、デザインの案の段階をおすすめします。構成に関わる問題が見つかったときに、直す手間が最も小さく済むためです。すでに公開している画面については、問い合わせが多い場面から順に確かめます。
Q5. 1人目のプロダクトマネージャーを迎えたあとは、誰が行うのがよいでしょうか。
準備と進行は、プロダクトマネージャーに任せやすい仕事です。そのうえで、経営者も年に数回は、記録の役や見学の立場で同席することをおすすめします。利用者が実際に迷う様子を自分の目で見ておくと、その後の報告や提案を受けるときに、判断がしやすくなります。
まとめ
ユーザビリティテストは、利用者に近い人に画面を操作してもらい、その様子を見て、つまずく場所を見つける方法です。作った本人には、つまずく場所は見えません。だからこそ、初めて見る人の操作を見ることに意味があります。
専任の担当者や特別な設備がなくても、(1)確かめる場面を決める、(2)操作ではなく目的で頼む課題を作る、(3)利用者に近い5人前後に頼む、(4)手伝わずに黙って見る、(5)多くの人が止まった場所から直して、もう一度確かめる、という5つのステップで、1週間ほどで回せます。
まずは、いま問い合わせが最も多い場面を1つ選び、社内でその画面に関わっていない人に、課題を1つだけ試してもらってみてください。その10分で、これまで見えていなかった「止まる場所」が、見つかることが多いものです。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。
「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。
おおむね2営業日以内にご返信します。
