GLITにおけるUXリサーチの立ち上げ
こんにちは、Carat中井です。
今回は前回のnoteの続きとしてUXリサーチの立ち上げをした話を書いて行きたいと思います。
前回のnoteはこちら
背景
当時の課題感としては、下記のような状態でした
イシューアナリシスからどのあたりに課題があるかは分かっていた
定量的なデータからどの程度の課題があるかは分かっていた
なぜ課題があるかは分かっていなかった
ユーザーの声をほとんど拾えていなかった
そのため当時のプロダクト開発は下記のようなプロセスで進んでいました。
定量分析で課題を特定する→改善しそうな打ち手を考え開発する→振り返りをする
結果、数値が改善したりしなかったり。。
このような状況から、下記のような考えを持ち、UXリサーチの仕組みの構築を開始しました。
数値的な課題のWHYまで深掘りし、施策の精度を高めたかった
PdMとしてユーザーの解像度を上げたかった
各開発の当たり確率を高めたかった
UXリサーチの立ち上げ
リサーチの立ち上げについては、外部のUXリサーチャーの方に副業でお手伝いいただきました。
主に私の方で、やりたいことやインタビュー項目を考え、レビュー・質問・アドバイスいただく形で取り組みました。
リサーチャーの方にインタビュー自体をお任せせず、このような進め方を取ったのは、「PdMとしてユーザーの解像度を上げたい」という課題感からでした。
立ち上げ初期はリサーチャーの方に伴走いただきつつ
リサーチの設計(目的や進め方、実現したいこと等)
質問項目の設計
リクルーティングの設計
などを進め、インタビューを行いました。
インタビュー後は、録画データを見てもらいインタビュー実施のフィードバックをもらう形で進めました。
この形は副業稼働いただく上で、非同期で支援いただくには非常に良い形だったなと思います。
ちなみに下記のようなフィードバックをもらいました。
割とあるあるのはずが、やってしまっていたので、第三者的に見てもらいフィードバックいただけたのはとても良かったです。
自分の話をしすぎる
誘導するケースがある
説明しすぎる
etc…
そして一連のプロセスを体験する意味で、分析フェーズも伴走いただきました。
まずは、リサーチャーの方に数人分を分析していただき、それに倣って私が分析し、最後のフィードバックをもらう形で進めました。
出現回数と影響度で定量化することで、課題の大小の判定し、深掘りすべきイシューの設定をしていました。
影響度の大小は離脱要因になったかどうかや、ユーザーのエピソードとの紐付きで判別していました
(エピソードに紐づいている場合は影響度が強い、紐づいておらずアイディアベースのものは影響度が低いとしていました)
下記の書籍を並行して読み込むことでかなり学習に役立ちました。
こちらは実務事例も載っており、具体例で理解するのにとても良かったです。
オペレーションの構築と自動化
ここまででUXリサーチの一連の流れが体験・学習できたので、オペレーションの構築に取り掛かりました。
PdMというロールをしているものの、他にもCOOロールの仕事があったり、定量分析も自分でクエリを書いていたりと、他業務もそれなりにあったため、なるべく工数をかけずUXリサーチのオペレーションを回せる必要がありました。
現状は下記のようにオペレーションを組むことでかなり省力化できています。
上記に加えて特定の期間内に特定の人数にインタビューしたい場合は、メールやプッシュ通知を併用することでリクルーティングを進めています。
現在の形
現状は下記のような２種類に分けリサーチを行なっています
定常リサーチ
PJリサーチ
定常リサーチ
週に1回〜を目安に定常的に実施しているリサーチ
ユーザー理解の深化と課題の探索が目的
リサーチ・質問の設計は常に一緒
インタビューの振り返りを通して、アップデートは行う
PJリサーチ
不定期に実施しているリサーチ
開発PJに紐付き、必要があれば実施する
課題の確認や解決策のコンセプトリサーチやUIの操作性の確認等が目的
リサーチ・質問の設計はその都度行う
直近PJリサーチがなかなか出来ておらず課題ではありますが、定常リサーチは常に実施することでチームのユーザー理解が深くなり、イシューの優先度設定に強く影響があるため、継続して行きたい取り組みとなっています。
最後に
Caratでは転職活動における負をいっしょに解消してくれる仲間を絶賛募集中です。
以下の募集ポジションを現在積極募集しています。
募集ポジションに当てはまらない方でも、少しでも興味を持っていただけた方は中井のTwitterまでお気軽にご連絡ください。
この記事が気に入ったらサポートをしてみませんか？