「誰も取り残さないUX」の実現のための取り組みの話
この記事はリクルート プロダクトデザイン室 アドベントカレンダー 2022 8日目です。
こんにちは！リクルートのプロダクトデザイン室で、『カーセンサー』のプロダクトマネージャーをしている眞下です。私は、2020年に新卒でリクルートに入社し、カーセンサーのプロダクトデザインを2年半ほど担当してきました。
私自身もそうですが、所属のプロダクトデザイン室で大切にしているのは、「ユーザー中心のスタンス」です(※1)。そのスタンスの一つの、「誰も取り残さないUX」の実現のために、どのような考え方、取り組みをしているかを紹介したいと思います。
はじめに
私が担当している『カーセンサー』は日々多くのユーザーがサイトやアプリを訪れます。ユーザーのニーズは、「愛車が故障したので、今すぐ手に入る中古車が欲しい」、「コスパの良いクルマが欲しい」「街中で見た気になるクルマの相場を知りたい」など多種多様です。
そんな多種多様なユーザーを抱えているプロダクトの、理想のUXの一つに、「ユーザー一人ひとりの利用ニーズを満たし、ユーザー’’全員’’がストレスなくサービスを利用できている状態 」があるのではないでしょうか。
私個人としても、プロダクトのUXに携わるからには、使ってくれるユーザー全員のニーズに応えたいという思いで日々プロダクトデザインに向き合っています。デジタル庁の目標(※2)に「誰一人取り残されない、人に優しいデジタル化を」と掲げられているように、ユーザーの一人ひとりのニーズに応え、誰も取り残すことのないUXは大きなテーマだと思っています。
そんな理想のUXを目指し、担当している『カーセンサー』や、リクルートの他プロダクトでも、ユーザーニーズを満たす機能開発のA/Bテストを継続的に実施しています。
そしてA/Bテストを実施し、目標指標が上昇する機能を実装していく、というプロセスを繰り返しながら、プロダクトの磨き込みを行っています。
しかし、プロダクトの磨き込みプロセスにおけるA/Bテストで短期の目標指標が向上したとしても、必ずしもユーザー一人ひとりが使いやすくならずに、一部ユーザーを取り残してしまうケースがあることがあります。どんなケースでユーザーを取り残してしまうのか、またそれはどのように防げるのか、私なりに日々業務で考え、取り組んでいることを話したいと思います。
KGI/KPI管理における機能開発
我々は、ユーザーニーズに応えられるよう機能開発をしますが、多くのプロダクトでは、それと同時に事業の目標指標を設定しているのではないでしょうか。例えば、リクルートのプロダクトではKGI/KPI管理のもと、その機能開発がKPIへどれだけ寄与するのかで機能開発優先度や機能の実装有無を判断することがしばしばあります。
事業の性質/フェーズなどによって例外はあると思いますが、プロダクトをKGI/KPI管理しているITサービスはKPIへの寄与度が高い機能の開発を優先して進めていくことが多いのではないでしょうか。
合理的に見える機能開発の指針ですが、短期的なKPI達成に主眼が置かれすぎたり、KPI達成に寄与するかだけで実装有無を判断してしまうと、「一人ひとりのニーズを満たしストレスなく利用できる」といった理想のUXから遠ざかってしまうことがあると考えています。
短期視点のKPI達成のみを優先してしまう場合
短期の目標達成に目が向きすぎたまま機能開発を進めてしまうと、効率的にKPIへ寄与する機能の開発のみ優先してしまいがちになると考えています。それは、KPIへ寄与しやすくインパクトが大きく、マスのニーズを捉えた機能の開発が中心となることにつながると思っています。結果的に、目先の短期目標達成に対しては寄与度が下がる、ユーザーの細かなニーズや要望に応える機能の開発の優先度が下がり、先延ばしにして着手しない、というサイクルになってしまいます。ニーズのボリュームがたとえ小さく、短期的なKPI達成に対しては寄与度が低くとも、ユーザー目線で見ると重要度が高い場合もあり、一人ひとりのニーズに応えられなくなる懸念があると思っています。
私自身、「ニーズとしてのボリュームが小さいが、ある一定のユーザーにとっては重要そう、だけど短期目標達成観点では他の機能開発と比較し優先度があまり上がらないかもしれない...」と頭を抱えたことが何度かあります。このような短期目標の達成との狭間で悩んだ方は少なくないのではないでしょうか。
KPIの数値改善のみで機能の良し悪しを判断してしまう場合
達成すべきKPIが存在するとはいえ、KPI至上主義となってしまっても、理想のUXから遠ざかってしまうことがあります。KPIを達成すべきだからといって、その数値が改善したかどうかのみで機能の実装有無を判断してしまうと、時に「裏で起きているユーザーの心理変化を考慮しきれない」ということが起き得ると思っています。
例えば、あるA/Bテストを実施し、KPIの上昇を確認したとしましょう。さらに、その他ユーザーログを確認しても離脱が多くなったり、マイナスな数値変化がないのに、以下の2ケースのようにユーザー体験が悪くなっていることがあります。
ケースA：大多数のユーザーα群は体験向上、一方で少数のユーザーβ群は体験悪化
ケースB：ほぼ全てのユーザーの体験悪化(体験悪化にユーザー自身気づいていないケースもあり)
ケースAについて、ユーザーログ集計時も、全ユーザーの平均として各指標を集計することも多く、ユーザーβ群の体験悪化が定量指標に現れず、体験悪化に気付けないケースです。
ケースAは、サービス側から一方的に特定の情報をプッシュした際(キャンペーン情報を何度も訴求する、大量のメールを送付するなど)に起きることが多いように思います。
またケースBについては、簡単に会員登録できるけどもキャンセルや退会の方法が難しいといった例がわかりやすいかもしれません。この場合、会員登録は簡単に出来るため会員登録率も上昇(退会率も減少)しますが、ユーザーにとっては体験悪化が起きていることがあります。これは一般的には、ダークパターン(※3)に分類されるケースのことを指しています。
※3： Darkpatterns.jp
誰一人取り残さないUXに向けた取り組み
前段で挙げたような行きすぎた短期KPI達成思考にならず、一人ひとりのニーズに応えるために、以下ではどのような取り組みをしているかお話できればと思います。沢山の方法(KPIの再定義、NPSの活用、ユーザーのログを細かく見る等々)がすでに世の中にあると思いますが、個人でのスタンスや取り組み内容を紹介できればと思います。
一つ目の「効率的にKPI寄与する機能開発のみ優先し、ボリュームは小さいかもしれないが重要度の高いニーズに応えられなくなる懸念」については、短期的なKPIのみに寄与するものだけでなく、ユーザー目線や長期で重要性の高そうなニーズに目配せしておくことが重要だと思っています。それらは短期的なKPIに対して寄与するかだけで言うと、中にはその時点で機能開発の優先度は上がらないものもあるかもしれません。しかし、日々多くの機能開発をしている中で、細かなニーズへの対応箇所と被る画面や機能の開発予定が入り、トレードオフなく実装できるチャンスがあったり、当初は優先度が低いと思われていたが調査を進めていくと重要度が高く、優先度を上げて取り組む必要が出てくるケースもあります。普段から細かなものを含めユーザーにとって重要度の高いニーズを見逃さないよう目配せしておくからこそ、その時点では一時的に優先度が低いと見なされている対応の重要性も社内で説明することができ、最終的に関係者を巻き込んでニーズや要望への対応ができると思っています。
実際の事例を紹介すると、とあるサービスのクチコミ投稿時にユーザーがニックネーム欄に異なる情報を誤入力してしまうケースがありました。これらの情報はユーザーにとっては公開を意図しない情報となる為早急に解決したいと考えていました。しかし、発生頻度はかなり稀なケースだったため、その時点ではなかなか優先度を上げて対策を取れていませんでした。そんな中、別のクチコミ投稿画面周りにおいてボリュームが大きいニーズ対応の改修をする際、必要性を社内で説明し、合わせて改修対応をしたことがありました。
日々ユーザーからの意見を聞き、どんな細かなニーズも把握する。そしてチャンスがある際は周囲に必要性を説明し、一時的に優先度が下がっていた改修も着々とやっていくことで一人ひとりのニーズにも応えられるプロダクトになっていくと考えます。
また目標指標のみで意思決定をし、機能開発を進めていく場合は以下二つのケースが起こりうると説明しました。それぞれのケースにどのような考えで対峙すべきか紹介できればと思います。
ケースAに対しては、サービス側から押し付けてしまうような機能をリリースした際に起きる傾向にあるかと思います。
使う人は喜んでヘビーユースしてくれますが、使わない人にとっては邪魔になって体験が悪くなってしまうということが起きます。
正直なところ、機能をリリースしないとユーザーの反応は見られませんし、行動分析もできません。そのため、企画担当者が事前にどれだけその機能をリリースしたときのユーザーの反応を想像できるかが大事になってきます。
どんな反応をするかを想像する際には、以下の2点を個人でもチームでも常に考えることにしています。
Point1：実装する機能のターゲット’’ではない’’ユーザーがその機能を見た時に何を思うのか
Point2：ターゲット’’ではない’’ユーザーにとって邪魔にならない方法はあるか
機能を追加したい企画担当者は「機能を追加すること」が目的になり、ターゲットのみを考えがちです。Point1で一度メインターゲットではない人のことを想像するというのが大事なポイントだと思っています。
Point1で大きな懸念がなければ機能実装を進めますし、そうでなければPoint2を考えます。Point2でターゲットではない人にとって邪魔にならないタイミングで機能を出したり、そもそもターゲット以外に機能を出さなくて済む方法を検討します。機能リリースした時、ユーザー体験が悪化してしまうのを避ける方法を取れないかよく検討します。
ポップアップ型のUIを搭載する事例で考えてみます。サイト内でユーザーに特定アクションを促したい時、どうやらポップアップ型のUIでアクションメリットを伝えるのが効果的だと仮説を立てたとします。
さらにユーザー全員にポップアップを出すとした場合、Point1に沿って、ターゲットユーザーではない人を想像するとどうでしょうか。まだサイトに来て間もない人や、情報をもっとよく見たかった人にとっては邪魔になってしまうことが想像できるかと思います。
その場合、Point2に沿って、ターゲット以外に対して邪魔にならない方法を考えます。
例えば、特定アクションをするユーザーは、サイト内の滞在時間や訪問回数が多いかもしれません。その場合、「滞在時間が長い」「何回以上サイト訪問している」といった表示条件を検討することで、ターゲットとしたいユーザーにはポップアップが表示され効果的に情報を伝えることができ、ターゲット以外のユーザーには邪魔にならないといった状態を両立することができます。
ケースBについては、サービス側の都合でユーザーを意図的に騙すことにもつながってしまうため、そのような機能は検討段階で機能開発候補から削除し、機能実装しません。
例としては、ダークパターンと呼ばれることもある、「登録は簡単だが、退会が難しい会員登録導線」や「ユーザーに伝えるべき情報を意図的に隠すUI」などあるかと思います。
チーム内でも、このような、「KPIは上がるが、ユーザーの不利益になる機能」には目を光らせています。
さいごに
個人やチームとして、ユーザー中心で誰も取り残さないUXのためにどう向き合っているかを話させていただきました。
今後もどんなに小さなニーズ・声も逃さず、一人ひとりのニーズに応えられるようプロダクトの改善を続けていきたいと思います！
最後までありがとうございました！
