こんにちは、QAエンジニアのEnnです。
Ubieでは職種にとらわれず、自分が挑戦したいことには積極的に取り組める文化があり、QA以外の業務にもチャレンジできる環境が整っています。
以前の職場でユーザーリサーチの研修講座に参加したことをきっかけに、この分野に興味を持ち続けてきました。Ubieでは、各チームがユーザーのインサイトを把握するために、定期的にユーザーインタビューとユーザービリティテストを実施しています。今回、モデレーター[1]として所属しているチームで合計4回のユーザビリティテストを実施しました。この記事では完全に素人である私が、そこから得た経験をシェアしたいと思います。
ユーザビリティテストとは
前置きに話したユーザビリティテストですが、一般的にはWebサイトやアプリの最適化を目的とした評価・検証方法を指します。このテストでは、実際のユーザーにWebサイトやアプリの画面を体験してもらい、使いやすさについてのフィードバックを収集します。
有識者に相談
ユーザビリティテストを進めるにはさまざまな準備が必要ですが、チーム内に専門家がいないため、まずは社内の専門家にヒアリングを行いました。最終的な目標は、チームが自立してユーザビリティテストを実施できるようになることです。
社内の専門家に相談したことで、全体の流れややるべきこと、進め方などが明確になり、経験のない私たちでも、どのように着手すればよいかある程度イメージできるようになりました。
やることの洗い出し
今回ユーザビリティテストの主な流れは以下の通りです。
- プレテストを実施する
- ターゲット条件を設定し、リクルーティングする
- 本番のユーザビリティテストを実施する
- テスト終了後にラップアップを行う
プレテストを実施する
テスト設計の検証のため、プレテストを実施しました。その際、社内の専門家に進行を担当してもらい、チームメンバーは同席してその様子をお手本として学びました。
プレテストのおかげで、進行の流れや雰囲気がより具体的にイメージできるようになり、本番に向けてスライドの構成や進行のしやすさを改善することもできました。
ターゲットの条件を設定し、リクルーティングする
ターゲットはチーム内で議論して以下のように明確な条件で設定し、社内のモニターリストをもとにリクルーティングしました。
- 40代/50代 女性
- インタビューOK
- 持病がある or 体調に不安がある
- 類似サービスの利用経験あり or 関心がある
- Ubie の検証対象機能を使ったことがない
本番のユーザービリティテストを実施する
ユーザビリティテストの構成は以下のように実施しました。
そして、事前にユーザーにスマホから参加するようにお願いしました。
※ユーザー向けには、わかりやすさのためインタビューと案内しました。
| セッション | 時間 | 内容 |
|---|---|---|
| 冒頭説明 | 10分 | - 自己紹介 - スマホで参加する場合、共有画面を全画面にしてもらう - Ubie の紹介 - インタビューのお願いとお知らせ |
| 事前設定 | 10分 | - スマホの通知をOFF - 画面共有の練習 - チャットの練習 |
| 操作の観察 | 20分 | - 操作中に発話をお願い - 発話のお手本 - 症状チェック〜結果画面を操作してもらい、発話の練習 - 検証対象機能の操作観察 |
| 操作後のインタビュー | 20分 | - 画面ごとに質問する - 検討中のプロトタイプを見せてフィードバックをもらう |
初回は非常に緊張していましたが、チームメンバーがMeetのライブストリーミングを通じて一緒に参加し、発話を記録してくれたうえに、Slackで即座にフィードバックやリマインドを送ってくれたので、とても心強く感じました。初回で少しコツを掴むことができたため、2回目以降は楽しみながら進行することができました。
ユーザビリティテストの実施後にラップアップを行う
実施直後には、チームでラップアップを行いました。この場で、メンバー全員が発見したことを共有し、次のアクションを決定しました。ただ実施して終わるものではなく、プロダクトの改善に直結する形で効果を発揮していると感じています。
プロダクト改善の効果
今回のユーザビリティテストを通じて、以下の改善点を明らかにしました。
- サービス概要が十分に伝わっていない
- 質問文に選択に関する説明文の追加が必要
- 入力フォームがスルーされやすい可能性
- 無料と誤解されるケース
これらの課題に対し、UIの変更やフローの修正などの施策を立案・実行しました。施策の実装後、A/Bテストを実施し、定量的なデータ分析を行った結果、今回のユーザビリティテストで生み出された施策は有意義であることが確認されました。そのため、実装内容を全て本番環境に展開しました。
今回のユーザビリティテストを通じて、施策の成功率が向上し、該当機能における事業KPIの大幅な改善がみられました。また、定量的な結果と定性リサーチで得たインサイトを組み合わせて意思決定を行うサイクルがチームに定着しました。
気づきと学び
プライバシーの考慮
ユーザーにスマホ画面を共有してもらう際、操作前に通知をOFFにしてもらうことで、不適切な通知が表示されるのを防ぐことができます。
シチュエーションは細かく分けず、大まかに伝える
ユーザーには、今回操作してもらうサービスの内容と仮のシチュエーションを伝えてから操作を始めてもらいました。当初は画面ごとに達成してほしいことを伝えていましたが、その結果、ユーザーがキーワードを探すように操作してしまう傾向がありました。
これを改善するため、操作に入る前に大まかなシチュエーションを伝え、3～4画面を一つの区切りとして「〇〇をしたい」という目的を伝える形に変更しました。その結果、ユーザーはキーワードを探すのではなく、自分の考えに基づいて選択するようになり、より深いユーザーインサイトを発見できるようになりました。
発話例とリマインドを提示する
ユーザビリティテストで発話しながら操作してもらうのは、ユーザーにとって難しいことだと思います。ユーザーは「どう発話すればいいのか」「何を話せばいいのか」をイメージしにくいため、操作に入る前に発話のお手本を示しました。また、操作中に沈黙が続いてしまった場合には、「考えていることを口にして操作してみてください」軽くリマインドを行うようにしました。
操作中の質問には質問で返す
ユーザーが操作の途中で、指定したミッションを達成するために何を押せばよいのか戸惑うことがあります。このような場合、シチュエーションの設定が不明瞭だったり、サービスのUI/UXが誤解されている可能性が考えられます。こうした場面では、「〇〇のボタンを押してください」と直接指示を出すのではなく、「なぜ戸惑ったのか」「どうして進めなかったのか」などを質問し、ユーザー自身の考えを引き出すようにしました。
Open Question を意識する
1回目では、「はい」や「いいえ」で答えられる質問をしてしまい、十分に深掘りができませんでした。2回目以降は、「〜どう思いましたか？」「どうして〜しましたか？」といったOpen Questionを意識して質問するようにしたところ、いくつかの改善点を深掘りすることができました。
サービス画面を表示しながら進める
今回はユーザーはスマホから参加しているため、画面をなるべく大きく表示したほうが見やすいです。スライドにスクショを貼るより、直接サービスの画面を映すほうが効果的でした。
そして、ユーザーは「その画面」「あの画面」と言いながら回答する時が多いので、実際のサービス画面を映したほうが画面遷移がスムーズでした。
QA エンジニア x ユーザーリサーチ
ユーザーリサーチは主にデザイナーやPMが対応することが多いと思いますが、今回の経験を通じて、チーム内でユーザビリティテストを実施する際には、QAエンジニアが同席したり、モデレーターとして進行を担当したりするのも適していると感じました。
QAエンジニアはプロダクトを最も触れており、仕様を最も深く理解している職種と言っても過言ではありません。この特性を活かすことで、ユーザビリティテストの構成を作成し、スムーズに進行するためのプロダクトのナレッジを提供することができると思います。
QAエンジニアは、受動的にプロダクトの価値を受け取る立場になりがちだと思います。しかし、今回の経験を通じて、QAエンジニアでもさまざまな手段を活用して、主体的にプロダクトやチームに価値を生み出せることを実感しました。その一つの手段として、ユーザーリサーチはとても効果的だと思います。
終わりに
以上が今回のユーザビリティテストを通じて学んだことです。日本語が母語ではない私がモデレーターに挑戦したいと言い出したとき、正直なところチームに拒否されるのではないかと思っていました。しかし、チームメンバーからの信頼と、Ubieの職種にとらわれないという文化のおかげで、外国人である私、そしてQAエンジニアとしての私がユーザビリティテストに挑戦し、成長することができました。
Ubieではさらなる改善をすすめるため、QAエンジニアやその他職種の採用を積極的に行っております。ユビーのQAエンジニアに少しでも興味を持っていただけましたら、ぜひカジュアルにお話しましょう！
-
モデレーターとは、ユーザーとやり取りをしながら、ユーザビリティテストを進行する役割のことです。 ↩︎
Discussion