ユーザビリティ評価プロジェクトの進め方
多くの方に先日書いた下記の記事を読んで頂き大変ありがたく思っておりますが、記事に対する反応を見ていると「そもそもユーザビリティ評価って具体的にどうすればいいの？」という声がちらほら。
なるほど、たしかにユーザビリティが大事とは多くの人が認識しているものの、それを実際にどう評価して、どう改善につなげて行くべきかについてはあまり知られていないのかもしれません。
そこで本記事では、弊社ANKR DESIGNがユーザビリティ評価（特にユーザテスト）を実施する際の標準的な手順についてご紹介したいと思います。ところどころノウハウが必要な部分もありますが、この記事を参考にして、何度か練習していただければ、どなたでもユーザビリティ評価ができるはずです。
【ユーザテスト当日までの準備】
1. ゴール設定
まずはユーザビリティ評価プロジェクトのゴールについて考えましょう。まず、あなたはなんのためにユーザビリティ評価を行おうとしているのでしょうか。代表的なものとしてはこのようなものが考えられるでしょう。
- 開発中の、あるいは開発しようとしているプロダクトの、あるいは特定の機能のUIが適切かつ妥当なものであるかを確認したい
- プロダクトの改善のために、現在のプロダクトあるいは特定の機能の抱える問題点を洗い出したい
あるいはもっと具体的にこのような課題からスタートする場合もあるかもしれません。
- 会員登録のコンバージョン率改善のために、ボトルネックとなっている部分を洗い出したい
目的がある程度見えてきたら、ユーザビリティ評価に利用できるリソース（期間や予算など）はどの程度なのかを確認しましょう。
例えば期間。様々な事情から新バージョンのリリース日程が決まっている場合は、特定の日までに開発するプロダクトの仕様がある程度決まっている必要があるでしょう。そうなると、それまでに現行プロダクトのUIを評価し改善点を抽出し、開発工数の見積もりや開発サイドとの調整等が必要になるはずですので、それを前提にスケジュールを立てる必要があります。
予算についても確認が必要です。使える予算が潤沢であれば様々なオプションが利用できますが、実際にはゼロか、そうでなかったとしてもそこまで多くの予算を使用することはできないでしょう。
さらに、ユーザビリティ評価を行う関係者の時間はどの程度確保できるでしょうか。残念なことにユーザビリティ評価専任のスタッフを置いている会社は殆どないどころか、ユーザビリティ評価のための時間を業務時間内に確保できている会社すら少ないでしょう。多くの会社ではデザイナさんが本業の合間を縫ってユーザビリティ評価の時間を確保しているのが実情ではないかと思います。
また、ある程度以上の規模の会社ではステークホルダーが誰なのか、どのような社内ルールがあるか、関連する法規制としてどのようなものがあるか、その他様々な前提条件を確認する必要もあるでしょう。例えば、せっかく問題点を抽出して改善提案を作っても、様々な理由からそれをプロダクトに反映させることができないのであれば、その作業はなんのためだったのか？ということになりかねません。
これらのポイントを抑えた上で、プロジェクトをスタートさせましょう。
2. 評価タスク設計
プロジェクトの前提条件を確認したら次にタスクについて考えましょう。ユーザビリティという言葉からは「使いやすさ」や「使い勝手」と言ったものをイメージされることが多いので、いきなり「タスク」と言われると面食らう場合もあるかもしれませんが「使いやすさ」と「タスク」は切り離す事ができません。
ひとつのプロダクトは複数のタスクのために使用されることが多々あります。例えばメルカリのアプリをイメージしてください。ユーザーはアプリを使って商品を出品したり購入したいすることができますが、出品する時と購入する時、つまりタスクによって使用する画面や機能って異なりますよね。
もちろんプロダクト全体でユーザビリティを高める事が重要であるのは間違いないのですが、多くのケースではプロダクトが使用されるシチュエーション等によって使われる機能やUIが異なるため、まずはタスクに分割して、あるいはいくつかのタスクにフォーカスをあてて、それぞれ評価を行います。
タスクの例としては例えば、このようなものが挙げられるでしょうか。
- 会員登録する
- 東京都内にある店舗の場所を探す
- ○○をショッピングカートに入れて購入する
- XXXX駅からYYYY駅まで行く方法を調べる
- 今いる場所にタクシーを呼ぶ
3. 評価手法の選択
ユーザビリティ評価には様々な手法があります。代表的なものとしてはユーザテスト、ヒューリスティック評価が挙げられるでしょう。費用をかけずに…という事であれば、ヒューリスティックで問題点を抽出する場合もありますし、ある程度のコストをかける場合はユーザテストをしたり、視線計測装置などを使う場合もありますし、実際に運用中のアプリであればログ分析等を行う場合もあります。
とはいえ、先日の記事の反響から多くの方が気になっているのはユーザテストだと思うので、本記事ではユーザテストを選択した場合について説明します。
4. ユーザのリクルーティング＆スクリーニング
ユーザテストに必要なのは、まずユーザーです。なお、ここでは説明のために「ユーザー」と言う言葉を使用していますが、テストに参加していただくのは必ずしもユーザーとは限りません。例えば、オンボーディングプロセスの検証をしたいのであれば、これまでアプリを触ったことがない人のほうが適切である場合もあり、彼らを「ユーザー」と称するのはやや混乱を招きます。
評価に参加してくださるユーザーを集めるためにリクルーティングを行います。ユーザーリクルーティングエージェントを使う場合もありますし、最近であればbosyu.meなどを使用する場合もあるかと思います。
この際に、適切な属性を持ったユーザーを集めることが非常に重要です。例えば農業に関するアプリであるにも関わらず、大都市に住んでいて、ここ数年、土に触ったことも無い方（もちろん、彼らが潜在的なユーザーになる可能性は否めませんが）にアプリを触ってもらっても適切な評価ができるとは限らないでしょう。
他にも様々な要素がユーザーテストの結果を左右します。例えば、普段使用しているスマートフォンはiOSなのか、Androidなのか。日常的に使用しているパソコンはMacなのかWindowsなのか。スマートフォンやパソコンの使用頻度はどの程度で、日常的にどのようなアプリを使用しているか、競合のアプリを使用しているかどうかなどを確認する必要があるでしょう。
参加していただく方が決まったら、ユーザーテストを実施する日時、場所を伝えましょう。善意でご協力いただく場合、やむを得ない事情などで当日までにキャンセルが出る可能性もあるので、最低限必要な人数＋αの方でテストを実施する計画を立てても良いかもしれません。
5. 会場＆備品確保
ユーザテストを実施するには場所も必要となります。社内あるいは社外の会議室を手配しておきましょう。後述しますが別室でテストの様子をモニタリングしたいと考えている場合は、そのための部屋も必要になります。
また、ユーザテスト実施のための物品も準備しておくべきです。被験者から調査に関する同意を取るための同意書や謝礼などが必要でしょう。
また、被験者に操作してもらうスマホやPCのほか、その様子を撮影するためのビデオカメラや三脚、ICレコーダーなどが必要です。スマホで操作している様子を明瞭に録画したい場合は書画カメラなどがあると便利ですね。書画カメラとは例えば下記のようなもので、アームでカメラを固定し、上から撮影するためのものです。
【ユーザテスト当日】
なお、はじめてのユーザテストに取り組む場合、ここから先の部分は、事前に社内でリハーサルをすることを強くおすすめします。
6.プロジェクトの概要説明＆調査への同意を取る
当日、被験者の方が会場に来られたら、プロジェクトの概要を説明した上で、ビデオなどで撮影することなど含め、調査への同意を取り付けましょう。「このプロジェクトは、○○にプロダクトの操作性改善のために、いくつかの操作を行っていただきます」などと言った感じです。なお、ユーザーテストは、ユーザーさんの能力をはかるものではなく、うまく操作できなかったとしても、それは製品が悪いのだということを強調しておくとしっかり伝えておくべきかなと思います。
また、収集した情報を今後製品改善のために社内で共有すること、ユーザテストの内容などについて口にしないこと（未発表製品を扱う場合もあるので）などに関しての同意をとっておく必要もあるでしょう。
7.インタビュー
プロジェクトの説明と、同意書への記入が終わったら、インタビューを行います。これには被験者の方にリラックスしていただくためのアイスブレイク的な目的もあります。
普段どのような生活をしているか、どのようにスマホやパソコンを使用しているか。評価対象のプロダクトあるいはその競合との関わりについて聞くのも良いでしょう。あるいは新しいプロダクトに関する情報をどこから入手しているか、購入の意思決定をどのようにしているかなど、今後のマーケティング活動に活用できそうな質問を盛り込むのも良いかと思います。
8. 思考発話法の説明
場がある程度あたたまったらユーザテストにフェーズを進めるわけですが、ここで思考発話法についての説明を行います。思考発話法を使用しない場合は読み飛ばしてください。
ユーザテストに参加、あるいは実施したことが無い人にとっては思考発話法はご存知でない方が多いかと思います。思考発話法とは、思った事、考えたことを口に出していただきながら操作する方法です。
例えば「まずはサイトにログインしないといけないんだけど、ログインのボタンはどこだろう。あ、これかな。メールアドレスとパスワードを入力するテキストボックスがあるけど、僕は以前Googleアカウントでログインしたような気がするんだよな。SNS認証を行うためのボタンはどこだろう。あ、あったあった。これを押してと。おっと、GoohgleのWebサイトに遷移したぞ。ここでGoogleにログインすればOKだな。」みたいな感じですね。
もちろん、いきなり思ったことを口に出せと言われても恥ずかしいですし、なかなか難しいところもありますので、まずは被験者がお手本を見せるのが良いでしょう。そして実際のタスクに入る前に、簡単なタスクで声に出す練習をしてみるのも良いかと思います。
9. タスクを説明する
次に、被験者の方に実施していただくタスクについて説明します。タスクはコンテクストとゴールで説明します。例えば、こんな感じでしょうか。
あなたは就職活動中の学生です。エントリーシートを提出したところ無事に通過して面接に呼ばれましたが、面接の場所まで距離があるため、前泊するためのホテルを確保する必要があります。面接日時は○月○日の午前10時から。面接場所はXXX県のXXXXXXです。予算は8000円以内で交通の便の良い場所のホテルを探し予約してください。
これらは口頭で説明しても良いですが、コンテクストや条件が複雑な場合は紙などで印刷して渡すと親切かもしれません。
10. タスク実施
タスクについて説明し終わったら早速、タスクに取り組んでいただきます。タスクに取り組む様子は、ビデオなどで録画できると良いですね。PCやスマホで操作するアプリであればスクリーン録画アプリを併用するのも良いでしょう。持参していただいたスマホを使用してテストする場合は、書画カメラなどで上から手元を撮影させていただくのも良いでしょう。
とはいえ予算や準備の都合などもあると思うので、斜め後ろからビデオカメラで撮影させていただくのでも良いと思います。また、被験者に思考発話法を実施して頂く場合は、音声が録音できていることも要確認です。また、多くの人がテストの様子を観察していると被験者にプレッシャーを与えてしまうので、被験者と同じ部屋には1人とか2人だけ残して、別室でカメラ映像を通してテストの様子を観察する。というのもよくある方法ですね。
11. 休憩
タスクが終わったら、5分程度の休憩を挟みます。テスト実施者はこの休憩を利用して、ユーザの操作などで気になった点などを軽く確認しておくことを強くオススメします。というか、そのための時間です。
12. 事後インタビュー
被験者が操作している様子をビデオで見て頂きながら、気になった点について確認します。例えば、ここでしばらく動きが止まっていますが何かを探していましたか？とか何を考えていましたか？など。前述した休憩時間は、このインタビューの準備でもありますので、気になった所があれば確認し忘れのないようにしっかり話し合っておきましょう。
【ユーザテスト実施後】
13. 問題点の抽出
ユーザテストが終わったら一安心、と言いたいところですが、むしろここからが本番です。テストの場で感じたことや、被験者が操作した様子を撮影したビデオや、インタビュー結果などから、問題であると思われる点を抽出します。
この抽出の方法には、評価者が問題であると感じた点を挙げていく方法ももちろんあるでしょうが、、初心者と熟練者の操作を比較するためにNEM ( Novice Expert ratio Method ) のような手法を使って課題を抽出する場合もあるでしょう。ユーザの行動を細かく分析して時系列上にプロットしたいというケースもあるかもしれません。このあたりは目的に応じて手法を選択するのが良いかと思います。
また、それぞれの問題点がどの程度、重大なのかも合わせて検討しておくのが良いかと思います。ちょっと戸惑うレベルなのか、タスクの実行を妨げるような支給改善すべきポイントなのかなど。
ログデータにアクセスできるのであれば、同様の行動がどの程度発生しているかを把握しておくのも良いでしょう。例えば、全ユーザーのうち、約半分がこの画面で同様の操作ミスをしている。あるいは100万人に1件程度の操作ミスである。と言った情報があれば、どの程度急いで改善するべきなのかを判断する材料になり得ます。
14. 改善案の作成
ある程度の課題が抽出できたら、改善案についても考えましょう。例えばボタンの色を何色に変えるべきであるとか、画面のレイアウトをこのように変更すべきだとか、具体的なところまで提案できると良いと思います。
なお、実際には改善案を作成した段階で再度ユーザテストを行うべきですが本記事では省略します。
15.ステークホルダーとの連携
ユーザビリティ評価は、プロダクトのユーザビリティを評価することそのものに目が行きがちですが、ユーザビリティ評価の目的は見栄えの良い報告書を作る事ではなくプロダクトを改善することです。
プロダクトを実際に改善するためには、社内の様々な方との協力が必要不可欠ですので、作成した改善案を元に、ステークホルダーとのコミュニケーションを行います。多くはプロダクトマネージャーやエンジニアに意見を求めたり、あるいは提案する。と言った形になると思いますが、改善案によっては、知財は法務、あるいは営業などその他の部門との相談が必要になるケースもあるはずです。
16. 効果検証
プロダクトを改善したらその効果を検証すべきです。ユーザインターフェイスを変更した事により、ユーザの行動にどのような変化が起こったのかを確認します。大規模なプロダクトであればA/Bテストを実施することもあるでしょう。
ユーザインターフェイスの改善はいわゆるWicked Problemを解くことにも似ています。つまり、何らかの問題を解決するために何らかの改善施策を行うと、新たな問題が噴出することが珍しくありません。
こんなユーザーがこんなタスクを行うときのコンバージョン率は確かにあがったけど、他のユーザーが操作する際のミスが増えたとか、あるいは操作に要する時間が伸びた、ってのもよくあるシチュエーションであり、これらのバランスを取る必要があります。
17. 習慣化する
スマホアプリであっても、Webサイトやサービスであっても、現代のプロダクトはサービスの運営に伴い新しい機能が追加され続け、UIは変わり続けます。それに伴いユーザビリティを定期的に評価し改善していくことが大切です。
大掛かりなユーザビリティ評価を1回やるよりは、簡易的なものでも良いのでユーザビリティ評価を開発プロセスの中に組み込むなどして回数をこなし、常に改善点がないか目を光らせ続ける姿勢が重要でしょう。
おわりに
以上、簡単にではありますが、ユーザビリティ評価の一連のプロセスについて説明させて頂きました。この記事を読んでいただいて、ユーザテストって思ったより簡単そうだな、うちでもできそうだからやってみよう。と思ってくださる方が少しでも増えると良いなと思っています。
最後に、ちょっとだけ宣伝
弊社ANKR DESIGNでは、お客様のプロジェクトの目的やフェーズに応じて最適なユーザビリティ評価やその他デザインリサーチプログラムをご提案・実施させていただいております。具体的なプロジェクトについてのご相談はもちろん、「こういったことって可能だろうか？」といった段階から、お気軽に下記のTwitterアカウントへのDM、または弊社Webサイトからお気軽にご連絡頂けますと幸いです。
この記事が気に入ったらサポートをしてみませんか？