初めに
今回は、データを分析する人間から見たユーザテスト(主に発話プロトコル法)についてお話したいと思います。
なぜ発話プロトコル法でユーザテストをしようと思ったのか。
私が発話プロトコル法でユーザテストをしようと思ったねらいとしては以下のことが挙げられます。
- アクセスログやアンケートだけでは読み取れない行動を知りたい。
例えば、ユーザの手の動きなどについては、アクセスログやアンケートではわからないため。
アンケートでは使いにくい部分が慣れてしまっていて表面化されない可能性がある問題点が、発話プロトコルだと発見できる可能性がある。
複数人のデータを扱う場合、統一的な観点で分析をすることができる。 - ユーザがどんな行動をしているとき、エラーのある行動なのかを知りたい。
発話プロトコルを取ることで何を考えながらアプリを触っているのかがわかるので、アクセスログ上遷移数が多い操作について、不本意な遷移であるのか、本当に使われているページなのかを考察するヒントになる。 - ユーザテストをすることで、今後取得すべきデータが見えてくるのではないか。
ユーザが実際に触っている様子を見ることで、重要な指標や取るべきデータが出てくる可能性がある。
今回やったアノテーション作業
今回はELANという音声動画アノテーションツールをつかってアノテーションを行いました。アノテーションと言っても、いまいちイメージがつかないと思うので、実際にやった画面の一部をお見せします。
以下の6つの観点でアノテーションしました。
- プロトコル
- 発した言葉をそのまま記入。もちろん、「あー」とか「えーと」のフィラーも書いていきます。
- 操作画面
- 今どの画面にいるのかを記入。
- 操作
- ユーザの動作を記入。
- 何を
- 何を操作したのかを記入。
- 端末・手の動き
- 持っていない手で操作したり、持つ位置が動いたり、端末が傾いたら記入。
- エラー
- ユーザが意図していないであろう動きをした場合に記入。
これは、項目の一例として考えていただければいいかなと思います。
他の観点で考えたほうが良ければ、他の観点でアノテーションしていきます。
アノテーション作業の利点
例えば、アノテーションを行うことで何ができるのかというと、定量的に評価を行うことができるようになります。
例えば、全タップ数のうち無反応だったタップ数の割合や、何らかのエラー率などを出すことができます。
数値を出すときは、ただ単に数値を平均で出すのではなく、何人のデータであったのかなど、算出した数値がどのくらい信頼できるものであるのかがわかるような情報も出すと良いでしょう。
また、どんな問題があるのかを分類し、その数をカウントすることで自然と改修する際の優先順位の参考になるかも知れません。
アノテーションの付け方は決まっているわけではないので、大いに個性が出やすいところです。気になった観点でアノテーションを行うことで、何かしら思わぬ発見があるかも知れません。
終わりに
アノテーション作業を行うこと自体は、地味で大変な作業なのですが、実際にデータ分析を行う人がアノテーション作業をする意味があるのかなと思います。理想を言えば、サービス関わっている人みんなにアノテーション作業を行ってほしいです。なぜならアノテーション作業を行うことでそのサービスをどういうふうに使っているのかをじっくり観察することができるからです。じっくり観察することでデータ分析としての視点はもちろん、UI/UXに活きてくる部分が見えてきます。
サービスに携わる上で思っても見なかった視点が発見できることはもちろん、今まで数値を見ずに当たり前だと思って進めていたことが正しかったというのも大きな発見の一つです。
ユーザテストを行う際に、より正確に精密にしたい場合はこういう風なやり方があるよという紹介でした。
この記事を書いた人
- 新米エンジニアです。
最近書いた記事
- 2019.12.04Data Gateway Talk vol.4をレコチョクで開催しました。
- 2019.10.24そのグラフ、インターラクティブにしたくない?
- 2019.10.16発話プロトコル法を用いたユーザテストとデータ分析
- 2019.04.17第二弾 その平均値、危険ですよ! ~直感に反する平均値~