初めてのユーザビリティテストで準備したこととその感想
こんにちは。
Product divのデザイナーの佐藤です。
昨今、プロダクト開発においてUXリサーチを導入する会社が増えてきていると思います。
私はデザイナー歴１年程度で、今まで実務でUXリサーチを実施したことはありませんでした。
しかし！この度、現在進行中の新規プロダクト開発でチャンスを見出し、ユーザビリティテストを初めて企画・実施・分析を経験することができました。
やってみた結果、開発に役立つ多くの示唆を得ることに繋がり、やってよかった〜〜〜と思っています。
ただ、今振り返ると、特に準備の期間が大変だったなと感じています。
テストの当日、時間を無駄にしないためにも入念な準備は不可欠ですが、スムーズに入念な準備を行うことは、タスクの効果の想像が付きにくい未経験者には難しいことでした…
そこで今回は、
・今回弊社の社内ユーザビリティテストを実施するに当たって行った準備タスク
・今回のテストの準備を経て気づいたこと
を紹介したいと思います。
「ユーザビリティテストやったことないけどどんな準備が必要なの？」「何にどのくらい時間かかるの？」という疑問をお持ちの方に、いくらか参考になりましたら幸いです。
（玄人の方は暖かい目で見ていただけますと…！）
初めに：当時の状況
2022年春〜夏頃、弊社のProduct divでは新規プロダクト開発の真っ只中でした。
フェーズとしては、PMが要件定義を大方まとめて、デザイナーがHi-fiのデザイン・プロトタイプを完成させたタイミングでした。
今回の新規開発は性質上、MVPと言っている割に規模が大きい開発です。
一般的な、小さいベンチャーのプロダクトのMVPリリースよりも、一定以上のクオリティを担保する必要がありました。
とはいえ、当然MVPのリリースは遅らせたくないので、開発スピードも求められる…という状況でした。
そこで
・主要ユースケースが、UIを見ただけで迷わず遂行できるかを確認する
という目的で、ユーザビリティテストの実施をPMに提案したところ、OKがもらえたので晴れて実施する運びとなりました。
実施した準備タスク
それでは、今回実施した準備タスクをご紹介します。
（）内の期間はご参考までに、未経験者１人が他タスクとも並行しつつ実施した場合に概ねかかった時間です。
一応、大まかに時系列順になっています。
テスト計画・スケジュール策定（１営業日以内）
テストを実施するために必要なタスクを洗い出し、それにかかる時間をざっくり見積もりました。
テスト計画書作成（約１〜２営業日）
目的・実施方法・場所・大まかなタスク設計などを記したドキュメントを作成。
これを使ってPMとシナリオの方向性の議論を行いました。
ちなみにシナリオは、主要ユースケースをPMと一緒に選んで設計しました。
タスク一覧の作成（約１〜２営業日）
・当日実施するタスクとして、シナリオを分解して操作を一覧化する
・タスクごとに被験者の感想・反応・経過時間を記録する
・インタビュワーのスクリプトを記す
という上記３つのためのドキュメントをスプレッドシートで作成しました。
（当日はこれを見てインタビュワーが進行するし、書記がここに記録していきました）
被験者選定・スケジュール調整（約１営業日）
スピードを重視するため、今回は社内のペルソナに近いメンバー（実際弊社アプリの利用者でもある）に声をかけ、具体的なテストスケジュールを組みました。
Figmaでプロトタイプ作成（約４営業日）
今回は１回のテストで４シナリオ実施したため、４つのフローを作成しました。
実機で動作確認をしながら、ユーザーがどこを触ってもいいように作成しました。
被験者向けドキュメントの作成・印刷
今回対面・リモート両方で実施したのですが、リモートの方はFigmaアプリ・Google Meetアプリなどを事前にインストールしていただく、Figmaはテストアカウントでログイン可能な状態にしておいてもらうなどの事前準備が必要だったので、そのドキュメントを作成しました。
また、対面の方は当日紙でシナリオを確認できるように、紙出ししたシナリオペーパー？を用意しました。（当日操作していると、被験者が途中でシナリオなんだっけ？と確認したくなる時があるので、紙があってよかったと思いました）
被験者向け事後アンケートの準備
SUS（System Usability Scale）に沿って事後アンケートをGoogle Formで作成しました。
機材の準備
対面で使用するテスト用端末の手配、顔と手元を録画する機材、脚立などを準備しました。
パイロットテスト
ここまでの準備ができてから、当日のリハーサルを実施。
１回のユーザビリティテストは60分想定でしたが、都度止めて議論しながら進めたのでパイロットテストは2時間くらいかかりました。
また、パイロットテストしてみて「ここの準備足りなかった…！」と気づくことが多かったので、テストの1日前に実施するのではなく、余裕を持ってスケジューリングした方がいいです。
以上です。
思ったよりやること多いな…！と思われた方もいらっしゃるかもしれません。
私たちも、最初からスマートに上記準備事項の運びを想定して計画できた訳ではなく、手探りで進めながら、必要になったことをこなしていった形でした。
手法や作業の取捨選択が難しい
初めてUXリサーチの準備に取り組んで一番感じたのは、手法を取捨選択するのが難しいという点です。
昨今、日本でもUXリサーチの潮流が一般的になってきて、UXリサーチの本やネット記事がたくさんあります。
読んでみると、「この手法はこの手順でこうやるべき！」と教科書的に書いてあることが多く、フルフルできっちり手順を踏まないと効果がないのかな？と思うことがあります。
しかし、十分なリソースが取れない実際の現場では、リソースや時間と相談しつつ、本に書いてあるような手法をいくらかカスタマイズして必要な作業だけ抽出する必要がある（そうせざるを得ない）と思います。
各作業について実体験のイメージがない未経験者にとっては、「ここの作業を切ったらテストする効果や意味がなくなっちゃうんじゃないだろうか？」と考える場面も多く、頭を悩ませました。
完璧にやろうとしなくてOK
とはいえ、完璧にやろうとしなくていいんだなと、実際に体験してみて分かりました。（たしか松薗美帆さんの『はじめてのUXリサーチ』にも似たようなことが書いてあった気がします）
今回のテストも、スピード重視のために社内メンバーに対するテストでしたし、手探りで荒削りでしたので、本や記事で語られるような「理想的なユーザビリティテスト」ではなかったかもしれません。
しかし、結果として、開発メンバーが想像ついていなかったようなユーザビリティに対する意見や、プロダクトの在り方について再考させるような意見をもらうことができました。
このように、やってみながらじゃないと想像できなかったり、手探りで不恰好に進めながらでも、開発者ではない他者にフィードバックを得る行為自体に大きな意味があり、必ずプロダクト開発に有効な示唆を得られると、今回の経験で実感しました。
（この実感を得られたのが個人的には大きいです）
なんなら、ユーザビリティテストというお題目でなくても、開発しているプロダクトに対してフラットに見れる隣の島のメンバーにちょっと時間もらってでもフィードバックを得る、みたいなことを今後はしてみようかなと思うくらいです。
ここまで読んでいただいた、食指が伸びず燻っている皆さんも、ぜひ不恰好でも、超小さくでも、「開発者ではない他者」にフィードバックを得ることを始めてみてはいかがでしょうか？
インフルエンサーマーケティングの
LIDDELL／リデル
サービスの詳細は…
様々な職種で一緒に働く仲間を募集しています。
この記事が気に入ったらサポートをしてみませんか？