
ユーザーの課題を発見しよう!ユーザービリティテストの具体的なやり方を解説します
2021.05.20新規事業立ち上げには数多くの課題にぶつかります。そもそもニーズがなかったり、開発の進捗が思わしくなかったり、そうこうしているうちに資金が枯渇したりと。
ぼく自身も数多く新規事業にチャレンジしていますが、いまだに確実に成功する方法はなく、少しでも可能性をつかむために奮闘しています。
「ユーザビリティテスト」を実施することで、ユーザーの離脱要因や、ユーザー定着施策のインパクトの大きいポイントを仮説立て出来るようになります。例えば新規事業の課題の一つ、「ユーザーの定着」についても有効なアプローチです。
今回は、実例をもとに具体的なやり方を紹介していきます。
もくじ
「ユーザーが定着しない」という課題
この課題は多くの新規事業立ち上げでぶち当たる壁の一つで、いわゆるPSF(プロブレムソリューションフィット)を達成を評価するために、越えなければならない問題です。
ユーザーが定着しない問題は、よく「穴のあいたバケツ」と表現されます。いくら広告宣伝予算を投じても、穴が空いたバケツに注いだ水はほとんど流れ出てしまいます。新規ユーザーを獲得したところで定着しなければすべて無駄になってしまうのです。
ユーザビリティテストを実施することで、この穴がどこにあるのか見つけ出す助けになります。
ユーザービリティテストとは何か?
簡単に言えば、プロダクトを実際にユーザーに利用してもらい、その様子を観察し、プロダクト改善の手掛かりを得ることです。「ユーザーは目的の操作をストレスなく実行することが出来るか?」を評価します。
一般的に、プロダクトがWEBサービスやモバイルアプリの場合には、ユーザーが使っている様子を見ることは出来ません。何かユーザビリティ上のストレスを感じたユーザーはいとも簡単に使用を諦めてしまいますが、作り手はそれを知る由もありません。
そこで、実際にユーザビリティテストを通して、ユーザーが操作のどこにストレスを感じているか?などを顕在化し、ユーザーの離脱理由を仮説立て出来るようにするのがユーザビリティテストです。
実際のユーザビリティテストの事例
今回は、ぼくが個人的に開発しているRicetta(リチェッタ)というWEB上のレシピをまとめて管理できるモバイルアプリで実際に行ったユーザビリティテストの事例をもとにやり方を説明していきます。
実際にユーザビリティテストを実施すると、面白いくらいに意図した通りに使ってくれないシーンを目撃します。良かれと思って実装した機能がまるで気付いてすらもらえていなかったなんてことが起こります。
Ricettaでは、レシピのURLをアプリに登録する際にクリップボードから1タップでURLを貼り付けられる機能があるのですが、誰一人としてこの機能に気付いてもらえていませんでした。
あとあとヒアリングしてみると「クリップボードと言われてもなんだか分からない」という意見もあり、自分にとって当たり前だと思っていたものが、実はユーザーにとっては当たり前でないということがあることにハッとさせられました。
ユーザビリティテストの事前準備
では、具体的にユーザビリティテストを実施するためには何をすべきか説明していきます。まずユーザビリティテストを実施するにはいくつか事前準備が必要です。
- テスト対象者のリクルーティング
- テストシナリオの設計
- インタビュワーと観察者の分担
テスト対象者のリクルーティング
リクルーティングとは、テストやインタビューを実施する際の対象者を見つけてくる作業のことです。これがなかなか骨の折れる仕事なんですが、RicettaのようにtoCで比較的誰でもユーザーになりうるようなプロダクトの場合はあまり苦労しないで済みます。例えば、TwitterやFacebookなどで友人に呼びかけるだけで数名は確保出来ることが多いです。
一方で、toBで特定分野に特化したプロダクトの場合は非常に困難を極めます。例えば「医師専用のSNS」と立ち上げていると仮定すると、医師がメインユーザーとなるので、どうにかして医師の協力を得なければなりません。
この場合、SNSで募るのには限界があるので、下記リンクのようなリサーチ会社に外注することが出来ます。実際に利用したことがないので詳しくは述べませんが、1インタビューあたり2,3万円くらいの単価で実施出来るケースもあるようです。
またビザスクという専門家に1時間単位でスポットコンサルを依頼できるサービスを活用して、専門的な職業の人にインタビューを実施している例も多くあります。
テスト対象の人数は、十分に確保できれば望ましいですが、ユーザビリティの第一人者として知られているヤコブ・ニールセン氏によると「5人のユーザでテストすれば、ユーザビリティ問題の大半(約85%)を発見できる」と言われており、最低5人を目安に確保するとコストパフォーマンス良く実施出来ます。
テストシナリオの設計
テストシナリオはテスト対象者に実際に操作してもらう内容を定義します。仮にアプリやWEBサービスを渡して、「一通り操作してみてください」と言っても、目的のない操作を行うだけなので、得られる学びが小さくなります。
プロダクトのどの部分に課題があるかを仮説立てて、その部分を含めた操作を行ってもらう必要があります。Ricettaではユーザーの定着に課題があると感じたので、アプリ起動からレシピの登録し、材料でレシピを検索するという部分にフォーカスしてシナリオを作成しました。
実際のテストシナリオ
- シナリオ1: 今あなたの家には○○(好きな食材)が余っています。明日それを使って料理しようと思っています。その食材を使うレシピを調べてアプリに保存してください。
- シナリオ2: トマト、たまねぎ、にんにく、の食材が余っているので、それぞれを使用するレシピを3つ登録してください。レシピ登録するときは、あとで食材で検索出来るように登録しておいてください
- シナリオ3: にんにくが余っているので、にんにくを使うレシピを検索してください
- シナリオ4: ねぎ、牛肉、きゅうり、の食材が余っているので、それぞれを使用するレシピを3つ登録してください
- シナリオ5: 週末に作るこんだてをアプリ上で組み立ててください
インタビュワーと観察者の分担
インタビュー実施はインタビュワーと観察者で役割を分担するのが一般的です。インタビュワーは出来るだけテスト対象者にリラックスしてもらい、率直な姿勢でテストを受けてもらうことに集中しなければならないので、テスト実施中の気付いたことをメモするのは別の人に任せるのがベターです。
と言いつつもRicettaのように個人的なプロジェクトの場合、複数人用意できないこともあるので、少しいそがしくなりますが一人で両者を兼ねることも可能です。
ユーザービリティテストの実施
まずは、テスト対象者へテストの目的や注意点を説明します。Ricettaでは以下のように説明しています。
- (録画する場合)録画したデータはアプリサービスの質を向上させる目的のみで利用し、許可なく第三者に公開しません
- 今回のテストはユーザーがアプリをどのように操作して使うのかをテストし、アプリの改善に生かす情報を集めるためのものです
- 特に操作がうまく出来なくてもそれはアプリの問題であり、個人のリテラシーの問題ではありません。分からなくて詰まってしまっても落ち着いて続けてください
- 基本的にテスト中、操作に関する質問にはお答えできません。質問されても回答しないので予め承知ください
- テスト中はこれからどんな操作をしようとしているか、何につまづいているかなどを、思ったことをそのまま言葉にしながら操作してください
コロナ禍もあって、今回はZoomを利用して実施しました。通常は対面で実施する方が望ましいですが、オンラインでも問題なくできます。
テスト中は質問に回答しない
上記4番の通り説明していても、質問されてしまうことが多々あります。「これって〇〇ってことですか?」「どうやってやったらいいですか?」のように聞かれることがあるのですが、原則回答してはいけません。
実際にアプリを使うシーンでは、ほとんどの場合一人で操作しているはずなので、その状況と同じでなければユーザビリティテストにならないからです。誰にも聞けない状況でどうやって目的の操作を行うかを観察しなければならないのです。無視せざるを得ないので少し気に病む部分はあるのですが、ぐっと堪えて黙って観察しましょう。
また、シナリオのゴール達成時に、こちらから完了をアナウンスせず、テスト対象者の合図を待ちましょう。操作完了していないのにも関わらずテスト対象者が「完了した」と誤解してしまうケースを拾うためです。
テスト後のヒアリング
テストシナリオを一通り実施したら、操作を振り返ってヒアリングしていきます。
- 設計意図に反する操作を行っていた箇所について、なぜその操作を行ったかを深堀りする
- 「うーん」「わからないな」「どうやるんだろう」のようにつぶやきながら操作していた部分を深堀りする
- 使ってみて不便だった点を自由に回答してもらう
- 使ってみて他に欲しい機能がないか自由に回答してもらう
テスト結果の分析
実施からヒアリングまでの間、観察者は気付いたことを付箋にメモしておきます。Ricettaでは一人で実施だったため、省略してしまいましたが、複数人で付箋に記録したら、ホワイトボードに貼りだして、似たようなものをグルーピングして整理・分析します。
気付きを整理して、課題が見えてきたら、それを解消するアイディアを出していきます。それぞれのアイディアを吟味し、取り組む価値があると判断されたアイディアは仕様化して開発チームに連携していくという流れになります。
まとめ
ユーザビリティテストに関しては「ユーザービリティエンジニアリング」という書籍が良書です。ユーザビリティテストに関わる全工程とやり方詳細が網羅的に書かれているので、これからユーザビリティテストにチャレンジする人は必ず読んでおくことをおすすめします。
mofmof inc.では決まった通りに作るのではなく、ユーザーニーズに合わせてプロダクトを随時進化させていく、月額制の開発サービス「開発チームレンタル」を提供しております。
ユーザビリティテストで発見した課題の改善も随時プロダクトに取り込んでいけます。興味がありましたらお気軽にお問い合わせください。