ユーザーリサーチ推進室の実績大公開！Vol2.ユーザビリティテスト 自律駆動編
この記事は SmartHR AdventCalendar2022 の23日目です。
こんにちは、SmartHRプロダクトデザイングループの@oremegaです。
2本目のアドベントカレンダー用の記事を泣きながら書いています。
今回は、ユーザビリティテスト（以下、「テスト」）の実績vol2としてユーザーリサーチ推進室（以下、「推進室」）で支援してきた開発チームが自律駆動でテストを実施できた話を紹介します。
従業員サーベイの開発チームがユーザビリティテストを主導できた
推進室では定期的にテストを実施できる体制を整えてきました。定期的に実施することで、開発チームにいつでも使えるリサーチ手法の提供を目指しています。開発チームがリサーチに触れる機会が増え、リサーチに対する理解・関心が増していくことが狙いでした。
現在では、社内で一定の認知を得てテストの依頼よりもテストの設計レビューやヒアリング内容の壁打ち、実施のサポートなどで支援するようになってきました。
そんな中で推進室を複数回利用していたのが従業員サーベイチームでした。
事例:継続サーベイグループ
「従業員サーベイ」は、SmartHRに登録している従業員に対してアンケートを配信し、その結果とSmartHR内に蓄積された従業員情報を掛け合わせて分析できるサービスです。
近年ではエンゲージメントの計測として使われることが多く、定期的にサーベイを実施したい要望が高まりました。
しかし、同じサーベイを繰り返し実施して、回答の推移を分析する際は、任意のサーベイを選択して、分析を作成する必要がありました。
「継続サーベイグループ」では、複数のサーベイを一つのグループにまとめて管理し、回答結果の推移を確認できるようになりました。
継続サーベイグループのリリース判定のひとつの基準として、ユーザーに受け入れられるかを検証するテストを実施しました。今回、推進室は設計レビューとテスト実施のオブザーバーとして参加しました。
検証内容
継続サーベイグループで設計したインターフェースがユーザーに受け入れられる難易度なのか
ユーザーにとって推移の可視化は旧推移分析より使いやすくなりそうか
過去サーベイの質問コードの修正の難易度をどこまで下げればユーザーは許容できるか
継続サーベイグループというオブジェクト名は適切か
対象ユーザー
継続サーベイグループの価値を届けたいターゲットとして、複数回サーベイを送信しているユーザーを想定。特にパルスサーベイ（社員の状況をリアルタイムに意識調査する）用途で使用しているSenseiユーザーと、条件に合致しているSenseiユーザー以外も対象としてスクリーニングしました。
計画
継続サーベイグループを認識して各サーベイの質問を紐付けるために、質問コードに同じ文字列を設定して推移で見れるようにし、そこからサーベイの傾向が読み取れるかの一連の流れのなかでタスクを適切に切っていく方針で設計していました。
シナリオ
あなたはSmartHRの人事担当者です。
人事部でこれまで実施したテレワークサーベイの回答結果の推移を確認していくことになりました。
新しくリリースされた、サーベイの結果を推移で見れる機能を利用し、テレワークに関する社内の傾向を確認していきます。
タスク1
サーベイ結果の推移が見れるように設定してください。
タスク2
回答結果の推移で、各質問ごとの結果が改善しているか、悪化しているかを確認してください。
タスク3:
14問目の結果のグラフに、3月と4月のサーベイの結果が表示されるように修正してください。
設計で良かったポイント
検証内容を明確にし、タスクに落とし込めていた
基本的なことですが検証内容を明確にし、タスクに過不足なく落とし込むというのは難しいです。特に過不足なくというところで、タスクを設計している間に余計な肉付けをしてしまいがちですが、それがまったくなくタスクの数も抑えられていて良かったです。
タスクの設計には、「タスク完了の定義」、「検証内容」、「設計時メモ」が3点セットになっている
証跡を残しておくことは、レビュー時に設計意図を汲み取るのにとても役立ちます。
特に被験者の行動を予測して、うまくタスクが進行できないときにどういうサポートをすれば良いかまで考えられていました。
テストが必ずしもうまく思ったように進行するとは限りませんが、想定できることは前もってやっておくのは良いと思います。
タスクに使うサーベイはダミーではなく本物の内容と思えるような結果を用意している
今回はサーベイの結果を確認して傾向や良し悪しを判断してもらう中で、ちゃんと読み取ること、読み取りやすいことを重視します。サーベイのデータがダミーでは、被験者の普段の業務に近い操作を観察できないことをちゃんと理解しているところが見れました。
自分たちでレビューしあっている
これはテスト設計の体制になるんですが、自分たちでちゃんとレビューをする様子が確認できていたので安心しました。推進室でテスト設計するときも、複数の観点でレビューを行い、なるべく自然な操作を見れるように調整していきます。
開発チームでも同じ状態を作れており、周りを巻き込んでテストに向き合えているのが良い状態だと思います。
推進室でもテスト設計レビューを行いましたが、致命的な部分はなく結局些細なフィードバックだけをさせてもらいテスト設計レビューを完了しました。
結果/分析
タスク1
「継続サーベイグループ」がAppNavi（ヘッダーメニュー）の「サーベイ」配下にあり、迷ったり、「分析」に遷移してしまう被験者の様子が観察できた
「継続サーベイグループ」自体に違和感なく受け入れられてた
リード文に「継続サーベイグループ」の説明があったが、読まずに画面上で押せるボタンを探していた
改善ポイント1
AppNavi（ヘッダーメニュー）に「継続サーベイグループ」の動線を配置する
これまで「分析」を使うことが多かったのでユーザーの認知が得られにくい可能性があるのでインターフェイスだけでなくユーザーにお知らせする方法を別途考える
タスク2
全被験者でグラフの傾向を正しく読み取れた
「継続サーベイグループ」のグラフから傾向を読み取れた。これにより旧分析よりも使い勝手が良さそうな手応えを得た
タスク3
質問コードが同一であれば継続サーベイグループとして推移で確認できることは学習できそうであることはわかった
改善ポイント3
質問コードが同一であればよいというユーザー認知を高める
なぜ自律駆動できたのか？
推進室は従業員サーベイの開発チームを自律駆動できる状態に持っていこうという強いモチベーションがあったわけではなく、従業員サーベイの開発チームからも特別な要望があったわけではありませんでした。特に変わったことはしていので、推進室でもわかりませんでした。
そこで昔のやり取りをSlackから探しているとこんなコミュニケーションがありました。
やり取りを見ていると最初から依頼しているPMの熱量が高かったことです。
やはり、誰か一人の熱量が周りを引っ張っていけるのがとても強いですね。
開発チームの一人ひとりがユーザーはどんなふうに操作するだろう？と考えている結果と、これまでの推進室の啓蒙活動がうまく噛み合った結果だと思いました。自分たちでどのようなリサーチをすればいいかを考えているので、適切なシナリオとタスクが作れるようになるんですね。
現在は推進室でレビューすら実施しておらず開発チームだけで完全自律駆動でテストを実施しています。さらに、自分たちの独自マニュアルを用意して運用されていて感動で涙が止まりません。
テストを身につけた従業員サーベイの開発チームからは目的に合わせたユーザーリサーチの方法を知りたいとリクエストをもらっているので、推進室として全力で支援していこうと思います。
おわりに
推進室の目標は「リサーチを当たり前とする文化の醸成」です。
そのために定期的なユーザビリティテストの機会を作り、開発チームを支援できる体制を整えました。従業員サーベイの開発チームは、これまで支援してきた複数回のテストの設計や実施における細かいフィードバックから学習して、最適なテストを実施できるチームになりました。
これを推進室の実績というには、従業員サーベイの開発チームメンバーの意識の高さがあまりにも大きいです。それでも推進室の目標に一歩近づけたことにはちがいないので、ほかの開発チームでも同様にユーザーリサーチが当たり前となるような体制の再現性を得るために支援をすすめていきます。
SmartHRのプロダクトデザイングループでは、ともに完成のないプロダクトを作る仲間を募集しております。
