こんにちは、分析チームの坂本です。テックブログ3回めの登場です。

ミラティブの分析チームは、もちろんBigQueryや機械学習を用いた定量的なデータ分析も行いますが、ユーザーを理解するための定性分析も行う「分析チーム」であることを掲げています。

※最近では、データアナリストとUXリサーチャーの境界が溶けつつあるという議論があると思いますが、弊社もその流れを採用しています。

突然ですが、ユーザビリティテスト = お金と時間がかかるという認識の方もいらっしゃると思います。ミラティブでは、ユーザビリティテストをやろう！と言ってから3日間&謝礼実費のみでユーザビリティテストが完了しました(被験者3名)。どんなことをやったのかという内容を書きながら、ハマりどころををシェアしようと思います。

ユーザビリティテストの一般論

まずは、ユーザビリティテストってなんやねんという話を書いて行きます。といいつつ、ここは巨人の肩に立たせていただきます(笑)。

ユーザビリティテストとはなんなのか？だったり、なんの目的で実施するのかなどは、グッドパッチさんの下記のブログが詳しいので、ぜひ読んでみてください。

goodpatch.com

ミラティブでは、ユーザビリティテストを実施する前に、ミラティブで言うとどういうことなの？的な記事をコンフルにしたためました。

f:id:sakamoto10423:20190714183346p:plain — 社内に投稿したユーザビリティテストの記事

ミラティブでユーザビリティテストが必要だった背景

ユーザビリティテストってどれくらいの頻度で実施したら良いのか？という質問がよくあります。理想的には週一くらいのスパンで定期的にやるのが良いと思います。

しかし、スタートアップにはそんな時間も余裕もないわけです。オススメとしては、

大きなリニューアル前に改善の方向性を確かめるために実施
大きなリニューアルのプロトができたときに、プロトタイプで実施

です。反対に、小さな変更であれば、ABテストやデータ分析で検証することが望ましいと考えています。大きな変更は、画面の構造や印象が大きく変わると同時に、コードの変更も大きく入ります。なので、小さく失敗するためにユーザビリティテストを行うのがおすすめです。大きくリリースして、「やっぱり仮説が間違っていた」となると、相当のコードが無駄になります。

Mirrativ は、直近1年間で様々な機能追加をしてきました。エモモ・ガチャ・ギフト・コイン・オーブ・ジェスチャーなどなど、は直近1年間で追加された機能です。それらがスモールテストとともに導入されたこともあり、UI/UX上わかりづらいところが散見されるようになってきました。

f:id:sakamoto10423:20190714200502p:plain — UI/UX上わかりづらいメニューの例

たとえば、上記であればヘッダメニューの中に

配信一覧のフィルタを変更する、タブ切り替え
自身のエモモ(アバター)を切り替える

という機能が混在しています。現在ミラティブでは、このような使いづらい箇所を大きく手直しするプロジェクトが始まっています。そのインプットの一環として、ユーザビリティテストを行ったというのが背景です。

事前準備のTips

ここからがこのブログの本編パートになります。もっといいやり方あるよーってあれば、ぜひTwitterやはてブなどでコメントいただけると嬉しいです。

中継用のカメラはMacのカメラで十分

まず、ユーザビリティテストでほぼ必須なのが中継用のカメラです。被験者の手元を写しながら、その映像を別室に中継するためです。

PCサービスの場合は、テレビ会議システムの画面共有機能で十分だと思います。しかし、Mirrativ はモバイルアプリなので、被験者の手の動きを撮影することが必須です。そのため、何かしらの撮影機材が必要でした。

f:id:sakamoto10423:20190722111801p:plain — Macのカメラでユーザビリティテストを行う

いろいろと試した結果、上記のようにMacを後ろから抱きかかえるようなスタイルで撮影したところ、うまく撮ることができました。その映像をテレビに映したものを写真に撮ったものが下記です。もろもろ経由しているので、下記の写真の解像度はそんなに高くないのですが、テストを行うのに必要十分な画質でした。

f:id:sakamoto10423:20190721130748p:plain — Macで動画撮影した映像をテレビに映す様子

カメラのセッティング時に注意すること

カメラが安価で済んだぞ！と意気揚々としていたのですが、実際のテストを行ったときにちょっとしたトラブルがありました。それは、「部屋の調光によっては、蛍光灯の光が画面に反射してしまう」ということです。

f:id:sakamoto10423:20190717014737p:plain — 蛍光灯が反射してしまう

我々は最近、自然光あふれる目黒のオフィスに引っ越しを行いましたが、ユーザビリティテストを行ったのは渋谷の旧オフィスの窓がない会議室でした。そのため、蛍光灯の明かりがばっちりスマートフォンに映ってしまいました。我々は一度、被験者さんに承諾をとった上で、(電気を消して)真っ暗な部屋で実施していただきました。

今後の学びとして、蛍光灯にカバーがついている部屋でテストを実施する・自然光が入ってくる部屋で実施するなどの工夫が必要だと感じました。

配信はGoogleHangoutがよかった

では、次はその映像を中継する方法です。Macのカメラで撮影しているので、ビデオ会議システムに通すと楽ですね。そこで下記の条件を満たすビデオ会議システムを探しました。

Macのカメラから受けた映像を共有(配信)することができる
できれば高画質
40分以上共有(配信)を行うことができる
録画をすることができる
追加料金なし

zoomなどのオンラインミーティングなどをいろいろと検討しましたが、最終的にはGoogleHangout(Google Meet)を選択しました。ただ、Google Meetで録画をするには、G Suite Enterprise (1ユーザー3,000円/月) のプランの契約が必要だったので、Google Meetで録画することは諦めました。

ちなみに今回は、Google Meetで共有した映像をQuickTimeで画面録画するという手法を行ってみましたが、1ファイルが20GBくらいになり、あとあと管理に困りました。これは要改善ポイントです。

被験者の集め方

では、被験者はどうやって集めるのが早いでしょうか？民間のリサーチ会社さんにお願いすると、やはり(やり取りも含めて)1週間程度かかります。そこで、ミラティブでは社員の友人の方に協力いただくことにしました。

そこで、「募集をするなら黄色に黒！」という定番をリスペクトさせていただき、募集画像をつくり社内のSlackに投下しました。するとその日中に目的にあった被験者の方を3名集めることが出来ました。

f:id:sakamoto10423:20190721132735p:plain — ユーザビリティテストの被験者を社内募集

ミラティブ社では、ユーザビリティテストを行うのがはじめて(少なくとも会社独立後ははじめて)だったので、ユーザビリティテストの意義や成果をメンバーが熟知している状態ではありませんでした。そのため、なるべくみなさまに協力いただけるように、目立つ方法で集客しました。

当日の事前注意 & アイスブレイクの工夫

さて、ここからは当日の話を書いていきます。

ユーザビリティテストは、被験者の方にプロダクトを操作していただくテストです。被験者の方は「自分がテストされている」気持ちになってしまうことがある、と事前に知っていたため、下記のようなスライドを用意し、ご自身のテストではないということをかなり強調しました。

f:id:sakamoto10423:20190721135228p:plain — ユーザビリティテストスライド：はじめに#1

f:id:sakamoto10423:20190721135331p:plain — ユーザビリティテストスライド：はじめに#2

また、アイスブレイクでは「普段どんなゲームをされていますか？」というMirrativ と関係ある内容でアイスブレイク出来たのはよかったです。※例えば、ウイルス対策ソフトなどのユーザビリティテストでは「ウイルス対策って普段されますか？」ってのは本題に近すぎて、アイスブレイクには使いづらい質問だと思います。そういうときは、「オフィスまで迷わずに来れました？」みたいなアイスブレイクが一般的なようです。

当日あたふたしたこと

当日のトラブルというか、あわわわってなったことをいくつか紹介します。Mirrativ ならではのこともありますが、「個々のアプリで考えることがある」という意味で共有しておきます。

配信をして頂く際、やめ時が難しい

f:id:sakamoto10423:20190721140811p:plain — ユーザビリティテストスライド：シナリオ#3

3つ目のタスクとして、上記のようなタスクを行ってもらいました。もう少し具体的に言うと、普段プレイしているゲームを配信してもらうというタスクです。

これはインタビュワーが「では終了してください」と声を掛けるタイミングが難しかったです。というのは、ゲームによっては途中で辞めるとスコアが下がったり、たまたまその時間にオンしているマルチフレンドと協力プレイが始まったり、そもそもの1試合が長かったり。様々な理由で、ゲームのやめ時が読めません。

パズドラやバンドリ！などは比較的短いほうかなと思いますが、マルチ対戦TPSゲームや麻雀ゲームは1試合が30分程度かかってしまうので切り時が難しいなと思います。

ということで、次回はゲームをプレイされる前に、「今回はテストなので、10分程度で一区切りできるゲームを選択いただけませんか？」とアナウンスするのがよいかなと思いました。

想定外の箇所で詰みが発生する

事前の想定外のところで詰みが発生することがあり、インタビュワーが被験者さんにお声がけすることがありました。その一例を紹介します。

例えばiOSで配信する場合、Mirrativ のコメントや情報(「視聴者が来ました」や「ギフトをもらいました」)はPUSH通知を通じて配信者に知らされます。

f:id:sakamoto10423:20190721143948p:plain — 配信者はPUSH通知でMirrativ のコメントなどを知る

ということは、PUSH通知を切っていると、視聴者さんが来たとか、視聴者さんがコメントしたことがゲーム中に全くわからないわけです。そのことにはじめて気づきました。なので、2人めの被験者以降は、配信を始める前にPUSH通知をONにしていただく設定をしていただくことにしました。

当日の様子

f:id:sakamoto10423:20190714182759j:plain — ユーザビリティテスト当日の様子

上記はユーザビリティテスト当日のエンジニアルームです。エンジニアルームにある大きなテレビに大きくテスト中の内容を映し、エンジニア・デザイナー・PM全員で注目して見ていました。やはり、自分たちが作成したプロダクトなので、注目度は高かったです。このように、エンジニアチームを巻き込んでテストを行うのが大切ですね。