ビズリーチ事業部デザイナーの長尾です。「ビズリーチ」の企業様向けプロダクトを担当しています。
今回は今年の2月から進めている「ユーザーヲタクプロジェクト」を紹介します。このプロジェクトは名前の通り、「ユーザーについてヲタクのように詳しくなろう」という目的で始めた、チームのユーザー理解を促進する取り組みです。
プロジェクトのアウトプットは、プロダクトを利用いただいているユーザーを4つのセグメントに分類したペルソナと、各ペルソナに紐づく日次業務です。チーム内でユーザー像の共通認識をつくり、意思決定の速度を上げることで、ユーザーとなるお客様の本質的課題解決を加速させていきます。
ペルソナ設計に悩んでいる、チームの共通認識となるユーザー像をつくりたいという方は、当記事に実際の進め方やアウトプットを載せているので、1つの進め方として参考にしていただければ嬉しいです。
プロジェクトが始まったきっかけは、今年1月に行われた企業様向けプロダクトのリニューアルでした。
リニューアルを終え、デザインチームは「リニューアル完遂に向けた機能の反映」と「ユーザーの改善要望を解決する」2つの動きを行うことになりなりました。後者のプロダクトの改善要望に応えていくうちに、ユーザー課題や仮説の根拠を持てていないことに気づきました。
企業様向けプロダクトのユーザーは、ヘッドハンターの方々です。私自身転職経験がないので、そのような方と接したことがありませんでした。そのため、日頃どんな業務をしているのか、どんな課題感を抱えているのか、高い解像度で理解できていませんでした。
この課題は私だけが抱えているのか、チーム全体が抱えているのか。それを確かめるため、エンジニアやプロダクトオーナー、マネージャーにヒアリングしました。すると、「ユーザー理解の解像度が低いので体験の良し悪しを判断しづらい」「明確なユーザー像がないので機能の必要性が理解しづらい」などの課題が浮き彫りになりました。
これらの課題を解決するために始めたのが「ユーザーヲタクプロジェクト」です。
まずは普段からユーザーであるヘッドハンター様と接しているビジネスチームの1人をプロジェクトに引き入れ、ヒアリングしながら、ユーザー像やヘッドハント業務の仮説立てを始めました。
次にアウトプットを4種類のユーザーペルソナに決めました。具体的には、ヘッドハンターの「転職支援スタイル」と「担当求人数」の2軸を組み合わせた4象限です。
ビジネスチームのメンバーにヒアリングを重ねていくと、ヘッドハント業務は多岐に渡っており、1人のペルソナでは、すべての業務を網羅できないと気づいたためです。
ヘッドハンターが支援するのは、求職者と企業に分かれます。どちらか片方に特化した「転職支援スタイル」は「片面」、1人で求職者も企業も対応する方を「両面」としました。この「転職支援スタイル」によって、普段の業務が異なるためです。
例えば、求職者とやりとりする「片面」の方はスカウト送信の作業が多いですが、「両面」の方はスカウト送信以外の機能も使います。それによりプロダクトの使用ルーティーンや、利用実態が異なると考えました。
また、幅広い求人を扱っていて「担当求人数」の多いヘッドハンターと、希少性が高い求人を扱っている「担当求人数」の少ないヘッドハンターでも、業務内容が違う仮説を立てました。
仮説立てした4つのペルソナごとの業務フローを検証するため、各ペルソナに当てはまるヘッドハンターのみなさまにヒアリングしました。
ヒアリングは、ビジネスのメンバーの協力なしには実現しません。「ユーザーについてもっと詳しくなりたいので、いろいろ教えてください」と伝え、リニューアル後の2ヶ月で4, 5回デザインチームとビジネスチームでランチ会を企画し、そこで課題感を話していたおかげで快く協力してもらえました。
今回のヒアリングは2つのフェーズに分けました。
フェーズ1では、ヘッドハンターの繁忙期や1日のスケジュールなど、業務の全体像を把握するため「広く浅く」聞きます。そこで得た情報をもとに、業務の仮説をより強固にしていきました。
続くフェーズ2では、フェーズ1で得た情報や業務の仮説をもとに、スカウト送信やメッセージのやりとりなど、タスク単位で業務について「狭く深く」掘り下げていきました。
ヒアリングを進めていくと、事前に設計した「担当求人数」のセグメントでは、そこまで業務差分が出ませんでした。
各ペルソナでなるべく差が出るようにしたいと考え、ビジネスチームに相談したところ、「プレイヤー/プレイングマネジャー」のセグメントを提案してもらいました。ヒアリングしたデータを見返したところ、提案通り利用機能や業務の差が大きく、途中から「転職支援スタイル」と「プレイヤー/プレイングマネジャー」のセグメントに変更しました。
ヒアリングで得た情報や気づきはスプレッドシートに書き込み、特筆すべきところは随時Slackで開発メンバーに共有します。また、私がヒアリングのファシリテーションを担当していたのですが、書記を他のデザイナーに任せて、なるべく多くのデザイナーが一次情報に触れられるよう工夫しました。
一通りヒアリングを終えた後、ペルソナごとにヘッドハント業務の流れをまとめました。アウトプットには、読んだメンバーが疑問を持ちそうなポイントをまとめた、業務にまつわるQ&Aも掲載します。
しかしアウトプットをまとめる段階で、ペルソナを読んだ人が議論に参加できるようにしたいと考えました。そこで業務の流れを重視したまとめ方から、プロダクトを利用する業務にフォーカスしたまとめ方に変更。完成したアウトプットには「虎の巻」と名付けました。
「虎の巻」をチームメンバーに共有したことで、開発メンバー間で共通のユーザー像ができ、議論が早くなりました。またそれまでは改善を提案する際、ビジネスチームから補足がありましたが、共有後は補足なしに根拠のある意見を出せるようになりました。
当初の目的だった、高い解像度でユーザーを理解し、ユーザー体験に関する判断ができるようになったと思います。
しかし今の「虎の巻」は完成したとは言えません。足りない情報を埋めるのはもちろん、ユーザー像の解像度を上げ続けるため、ヒアリングは続けていきたいです。そして新たにチームに加わった人がこの「虎の巻」を見れば、すぐにユーザーを理解でき、議論に参加できるまで解像度を高めていきたいです。
プロダクト開発では、最初につくった仮説やプロトタイプにとらわれず、それらを更新していく「作って壊す」を繰り返す姿勢が重要です。今回のプロジェクトでも目的達成のため、最初に決めたペルソナのセグメントやアウトプットのまとめ方を変えました。
これからも「作って壊して」の姿勢を変えずに、チーム全員が「ユーザーヲタク」になって、ユーザー課題を解決するプロダクトをつくっていきたいです。