吉田 真由美（ヨシダ マユミ）はじめに
en-chantはtoC向けの主にスマートフォン利用を想定したWebサービスですが、ローンチ以来ユーザビリティテストをほぼやらないまま走ってきました。しかし、新機能を追加する時や既存画面を改善する時に、これ本当に伝わる？、と議論になることが度々あったので、簡単なものでも絶対やるべき、との思いからユーザビリティテストを実施することにしました。
しかしスピード感は落としたくないので、大規模に一般ユーザを集めるのではなく、社内で協力者を集めてテストしました。
以前担当していたプロジェクトで、被験者にも出社してもらい対面でスマートフォン用のユーザビリティテストを実施した経験はあったのですが、出社制限がかかっていたタイミングだったこともあり、初めてリモートで実施してみようということになりました。
そのときに具体的にとった方法、実施して見えた課題について振り返ります。
具体的なテスト方法
- Web会議はMeetを使用
- テスト画面はFigmaで作ったデザイン中の画面
- テスト端末は被験者の社用iPhone。社用iPhoneにはslackインストール済み
- Figmaの画面共有機能を使うため、Meetに繋ぐのは被験者のPCのみ（詳細は後述）
準備
被験者の募集
被験者の募集は、予めテスト実施の枠を決めた上で社内で協力してくれる方にアンケートを取る形にしました。こういう時は全体にメール送って、こういうことやってるよを宣言し、協力してくれる人を巻き込んで行くのがスムーズで好きです。アンケート締め切り後は被験者の条件と予定を鑑みた上で個別にスケジュールを連絡しました。
こんなメッセージ↓（以後永遠に使えるので定型文化してます）
テスト画面の準備
テストするのはFigmaでデザイン中の画面です。Figmaのプロトタイプ機能を使ってテストします。プロトタイプはURLを共有できるので、そのURLを発行しておきます
プロトタイプのURL発行方法
右上メニューの再生ボタン押す
右上メニューの Share prototype を押す
右上メニューの Options の Show hotspot hints on click のチェックを外す(こうしておくとヒントが現れないので誘導になりにくい)
モーダルの左下にある Copy Link を取得
手順３がポイントです。ヒントが現れるのはチーム内で共有するのにはとっても便利ですが、ユーザビリティテストでは誘導になってしまうので、この機能はオフにします。
このURLから操作すると、リモートで見ている他の人からも操作者の動きが見えます。リモートユーザビリティテストの際は、被験者に画面共有してもらわずとも操作が見えるので、被験者にスマホをMeetに繋いで画面共有してもらう、という煩わしい手間が省けます。また、対面でのテストの場合もテスト機の様子を手元のPCに大きく映すことができて便利です。
スクロールや画面遷移だけではなく、タップしたところがふわっと光るのも素敵です。
当日
被験者の方には普段通りMeetでのミーティングに参加してもらいます。
いつもと違うのは手元に社用iPhoneを用意いただくのみです。
※この被験者の手間の軽減はユーザビリティテストにとって大事なポイントと考えています。お互いの、できるかな、できてるかな、の不安はストレスになりますし、その確認のコミュニケーションは結構な手間になります。
アイスブレイクが終わればテスト本番です。slackで被験者にFigmaの共有URLを送って社用iPhoneから開いてもらいます。
テストする側はFigmaの操作を画面共有します。
この後はテスト計画通りにテストするだけです。
課題
被験者の準備もほとんど不要、テストする側の準備もとっても簡単ですが実際やってみて見えた課題もあります。
画面内の操作がほとんど見えない
前述の通りタップしたところがふわっと光る素敵な機能がFigmaにはありますが、実際やってみると残念ながらあんまり見えないです。ネットワーク越しだとネットワーク環境が不安定になるともう意味をなさないです。（でも全くないよりはいい） 被験者の操作が早いと、どこをタップして移動したかが全然わからないことも多々あります。
スマートフォン操作にとって重要な指の動きは一切見れないのはなかなか辛い
特に親指の動きが見れないのはスマートフォンでのテストではなかなか厳しいです。PCの画面でいうところのカーソルが一切見えない状態です。迷ってる感じもわからないことが多いです。
また、被験者もスマートフォンの操作をしているため、下を向いていることがほとんどなので表情も読み取りづらかったりします。
例えば被験者の動きが止まった時、何かを探して止まっているのか、読み込んでいるのか、考え込んでいるのか、がわかりにくいです。この理由がわからないと問題が何なのかを誤認してしまう可能性があります。この場面で止まっていたように見えましたが何をしようとしてましたか？、は必ず聞くようにしました。
リモートでのスマートフォンユーザビリティテストは情報がかなり削ぎ落とされるという前提で観察し、テスト終了後のインタビュー時にしっかり質問する必要があります。
対面の場合、その辺どうなの？
目の前でユーザの操作を実際に見ると情報量が全然違います。臨場感もそうですが単純に、そうやってスマホ持ってそうやって操作する人いるんだ、という発見もあります。自分のバイアスにも気付きやすいです。それでも100%伝わる訳はなく、一切質問要らない、とかではありませんので、こう見えたけど本当にそうかな？という場面があればしっかり質問するべきです。
それでもやらないよりはやった方がいい
テストをしてみて、これ全然伝わってないやん、問題めちゃくちゃあるやん、という発見がありました。社内なのでITリテラシーが一般より高いのにこれだけ伝わらない、ということは一般ユーザー向けだとほとんど伝わらないな、ということがわかりました。これは本当にやってよかった。
もちろん大きな問題が出ないテストもありましたが、それはそれで次に進んでもいいという指針にはなります。大きな問題がなくても必ず改善点は見つかるので、テストをやらないより良いプロダクトにできると考えています。
社外ユーザビリティテストに向けて
en-chantでは（というか、私は）ユーザビリティテストを社内だけではなく、一般のユーザーの方を対象にもやっていきたいと考えていますが、その場合にリモートでテストするのはまだまだ壁があります。
一番大きな壁はテスト中の画面をどうやって見せるのか？
まだ世に出てないものなので当然社外秘になります。簡単に共有URLを渡すことはできません。適切なアクセスコントロールをしようと思ったらFigmaのアカウントを作ってもらわなければなりません。ユーザの方にそれをやっていただくのは負荷が高すぎます。許諾を取るだけで良かったらそれでいいのですが、本当にそれでいいの？というところから考えないといけません。
その辺を整備することを考えると一般ユーザーの方を対象にしたテストでは対面でのテストが一番手っ取り早いなと今は考えています。対面テストも定期的に実施できる体制を整えて、ケースバイケースでテスト手法を選択できるようにしていきたいです。
