CLOSE

リクルートUX組織のナレッジシェア(全2記事)

2020.03.13

Brand Topics

PR

SUUMOの大規模リニューアルにおける、UXデザインの考え方・進め方

提供:株式会社リクルートテクノロジーズ

多種多様なマーケットで、SUUMO、ホットペッパーグルメ、ゼクシィなどのプロダクトを運営しているリクルート。こういった数多くのプロダクトを支えているUX組織は何を信条とし、何を実践してきたのか? 各プロダクトのUXとビジネス価値を高める案件を企画・実行しているリクルートの担当者にこれまでの事例やナレッジを語っていただきました。本記事では、「成果につながるリニューアル」として、株式会社リクルート住まいカンパニー SUUMO 新築マンション/注文住宅領域 プロダクトデザイングループマネージャー・片山雄介氏が、SUUMO注文住宅の大規模リニューアルの道のりを振り返りました。(注:この記事は2020年2月18日に開催予定で、新型コロナウイルスの影響を勘案し中止したMeetUPイベント向けに用意していたコンテンツを紹介するものです)

SUUMO注文住宅の「成果につながるリニューアル」

片山雄介氏:「成果につながるリニューアル」というテーマで、リクルート住まいカンパニーの片山からご説明させていただきます。よろしくお願いします。

簡単に自己紹介させていただきますと、私は今リクルート住まいカンパニーの「SUUMO」というサービスの中で、新築マンションと注文住宅の領域のマネージャーをやっております。学生時代はもともとエンジニアでしたが、リクルートに入社してからはずっとUXデザインに関わる業務を行っています。

業務の内容としては、SUUMO内の複数のプロダクトにおけるUXデザイン・ディレクションや効果改善チームのプロダクトオーナー、VRを使ったモデルルーム案内の技術の企画開発のチームリーダーなどをやっていました。最近は大規模リニューアルのUX責任者を経た上で、現在の部署のマネージャーをやっております。加えて、リクルート横断のナレッジシェアの推進にも携わっています。

今日は、注文住宅の領域で2019年7月17日にリリースしたSUUMO注文住宅のリニューアルを例に、大規模リニューアルで成果につなげるためにはどのように課題設計やIA設計をするのかを、具体的な事例を交えて紹介します。

今回は課題設定やIAに関する話をメインにさせていただきますが、リクルート内では、この内容のほかにIA・UI・デザインのより具体的な話や、リニューアルで発生するさまざまなリスクに対してどう対処していくのかといったリスク対策の話も、ナレッジシェアを行っています。

それでは、今回のテーマについてお話します。お伝えしたいことはこちらです。UX関連のブログや本、世の中の記事ではいろいろな手法やフレームワークの話が語られているものが多いと思います。これらはもちろん知ってることに越したことはないものの、大事なことは、いかにそれを組み合わせてやるか。そして目的・状況に合わせて「仮説思考」で最善の手段を考えることが大事なので、その内容がみなさんにお伝えできればと思います。

ポテンシャルは大きいが、「不」もとても大きい領域

アジェンダはこちらです。

SUUMOは全国のマンションや一戸建て・土地などの販売/売却情報から賃貸やリフォームまで、住まいに関するあらゆる情報が満載のポータルサイトです。

ビジネスモデルは、家を借りたい、購入したい、建てたい、リフォームしたいといったカスタマーと、それらの情報を提供するクライアント様をマッチングするモデルです。

基本的には広告課金モデルで、今回ご説明するSUUMO注文住宅は、家を建てたいカスタマーとハウスメーカー・工務店と呼ばれる、家を建てるクライアント様をマッチングするメディアです。

注文住宅の背景を簡単にご説明すると、みなさんの認識とちょっとズレがあるかもしれませんが、実は住宅を購入したいという検討者のうち、注文住宅は全国的に見るとニーズが一番高い領域になっているんです。

にもかかわらず、82パーセントというかなりの多くのカスタマーが途中で検討を離脱をしてしまう、不のとても大きい領域でもあります。

次に、カスタマーの注文住宅検討の流れを簡単に説明させていただきます。、大きくは、実現したい暮らしや建てたい家のイメージを形成することと、その形成したイメージを実際に建てられ、信頼できる会社がを見つけること。これをぐるぐるしながら家のイメージと会社に求める条件が具体化していき、最終的に成約に至ります。

その検討の過程で、会社のカタログをもらったり、展示場やモデルハウスで実物を見に行くなどの行動をします。こういったカスタマーをサポートするために「SUUMO注文住宅」というメディアがありまして、機能としては、会社を探せる導線、施工実例が見れる導線、モデルハウスを探せる導線、住宅イベントを探せる導線があり、それぞれに対して、必要なアクションを用意しています。

なぜリニューアルという選択肢をとったか

この注文住宅のサービスを7月17日にリニューアルしたのですが、そもそもなぜリニューアルという選択肢をとったかについてご説明させていただきます。

ここでは、リニューアルをすべき、リニューアルは良い手段である、ということを伝える気はないです。むしろリスクも大きいため、リニューアル以外の手段があるなら、やらないほうがいいと思っています。ただし、リニューアルをやらざるを得ないタイミングもあると思いますので、そういうときには今回の内容はとても参考になるのではと思います。

注文領域において、事業を今後大きくグロースしていくためには、UXの改善やマネタイズの方法も含めて、サイトを構造的に変更する必要がありました。UXの構造的な改善とマネタイズの設計を「同時に」実施しなくてはならない状況があったので、今回は大規模リニューアルという選択肢をとりました。

ここで質問なんですが、みなさんがリニューアルのUX検討を進めることになったら、どんなプロセスで進めようと思いますか?

1つ目は、何が正しいかわからないから、まずは網羅的に調査をやって、そこから仮説を構築して進めていく方法。2つ目はまずは仮説を置いて、裏づけを行って間違ってたらピボットするのをクイックに行っていく方法。どちらの方法で進めますか?

やり方としては後者の仮説思考で進めることが大切です。仮説思考で進めることでスピーディかつ確実にゴールに向かうことができます。

僕らのリニューアルではこういうプロセスを歩みました。まずKGI/KPIを設定し、その上でカスタマーの課題を初期仮説を設計しました。そして、調査やログ分析などを行い、設定した仮説が正しいかを裏づけし間違っている部分は修正する。仮説の精度が高くなるまで、これを繰り返します。ある程度正しいとなったら、得た情報をもとに改めてユーザーモデリングを行いました。

ユーザーモデリングの後は、どこのユーザーセグメントをターゲットにするのか、どのシナリオをターゲットにするのかを決めた上で、そのユーザー・シナリオにマッチするよう機能設計・IA設計を行います。そして、本当にそのターゲット設計、機能設計、IA設計で合っているのか、その仮説が正しいのかをユーザーテストや調査、A/Bテストをしながら検証し、精度を高めるプロセスを歩んでいます。

このプロセスを経て、仮説が確からしい状態に仕上がり、最終的に詳細設計に入っていった、というのが私たちのリニューアルになっています。

どうやって初期仮説を設定したか

まずリニューアルのゴール、KGI・KPIを決めます。注文住宅では、カタログ請求やモデルハウスの見学予約、住宅イベントの予約、電話での問い合わせが用意しているアクションになっております。

KGIが何か、どのアクションが大事なのかについては、戦略に紐づくお話なので、ここでは説明を省かせていただきますが、要はこの4つのアクションを伸ばすことがリニューアルの目標になっています。

KGI・KPIが決まった後は、それらを伸ばすための初期仮説の構築を行います。僕らも最初、注文住宅のカスタマーがどんなプロセスで家を探して会社を探し決めるのかがまったく想像がついてなかったんですね。なので、「こういうふうに検討するんじゃないか?」みたいな仮説をチームで話ながら、検討プロセスの仮説をまず作ってみました。

作ってみると、「本当にここって正しいのか?」という疑問点がどんどん上がってくるので、これらを仮説検証していきます。このように仮説で良いので一度描いてみると、検証すべき論点が見えてきます。これがカスタマーの行動に関して描いた仮説の話です。

そのほかにも現状のサイトの課題出しも行っていきます。例えばログ分析しながら、「この画面ってこう変えたほうがいいんじゃないか」というリニューアルの方向性を探っていきました。

例えば、トップページに会社の条件が出ていて、ここから会社を探せるのですが、もっと条件の種類を充実させたほうがユーザーのニーズを拾えるんじゃないか、そもそも導線の強弱が間違っていて別の導線を画面上に持ってきたほうがいいんじゃないか。そういった仮説をログ分析や定性情報をベースに積み上げていきます。

これらを元に、リニューアルをどういう方向性でやれば成功するのかの仮説を描きました。

カスタマインタビューやログ分析で仮説を確かめる

初期仮説を描いた後は、「本当にそれが正しいのか?」という材料をしっかりと集め検証するフェーズに移ります。

まず、カスタマーの検討フローが本当に合ってるのかがわからなかったので、これを明らかにするために定性調査、カスタマインタビューを行いました。

例えばこのように、あるカスタマーが実際に検討を開始してから成約に至るまでに、どんな検討プロセスで、どんな行動をし・その時のインサイトはどんなものかを何人ものカスタマーにヒアリングし可視化しました。

調査は、エリアが異なるとニーズも変わるかもしれなかったので、東京だけでなく関西などのほかのエリアにも出張して実施したりしていました。

ここまですると、最初に描いた仮説とカスタマーから聞いた内容で違ってるもの・合ってるものがわかるので、仮説を少しずつ修正しながら、最終的にカスタマーのことが明確化できます。

また、ヒューリスティックに出したサイトの課題が本当にこれで正しいのかは、ログ分析やアンケート調査をしながら検証しました。

このようにして、カスタマーの行動や、今のサイト上の課題が明確になりました。もちろんこれだけじゃなくて、そのほかにもいろいろな材料の集め方をしています。

例えばサイトの各ページのボリュームがどれぐらいなのか、その画面からのコンバージョンレートってどれぐらいあるのか。白地の多い画面に当たりをつけるのはもちろんのこと、「各画面からどの導線に流せばアクション率が高まるんだろう?」という分析もこのタイミングでしっかり行っています。

また、さまざまな競合サイトを調査し、SUUMOの劣位ポイントがあるのかという観点や、情報誌や世の中にある注文住宅のカタログなどからエッセンスを探りに行ったり、自分で展示場に足を運んでカスタマーになりきってみたりしました。いろいろな手段をやりながら仮説を確かめにいくこともこのタイミングで行っております。

行動の共通点を見つけ、検討プロセスを体系化する

ここまでくれば、カスタマーをモデリングできます。

ここでは、カスタマーの行動の共通点を見つけて体系化・抽象化することをユーザーモデリングと言っています。

先ほど一人ひとりを調査した結果をスライドでお見せしたと思うんですけれど、それをこういうふうにホワイトボードでガンガン貼っていきました。

時系列で、左の方の漠然期から契約に至るまでに一人ひとりがどんな行動をしたのか、そのときのインサイトは何なのか、そのときにどんな情報を得たのかをマッピングしています。こういうふうにマッピングすると、例えばここにPattern A・B・Cと書いてあるんですけど、いくつか共通の動き方・パターンみたいなものが見えてきました。

それらをうまくまとめて抽象化すると、いわゆるカスタマージャーニーみたいなかたちでカスタマーが一般的にどういうプロセスで検討をするのかがわかってきます。

各フェーズに対して、「ユーザーがどんな気持ちなのか」「どういう目的で注文住宅を検討しているのか」といったインサイトも定性調査や定量調査ですでにわかってるので、それらをマッピングしていきます。

さらに、その人たちがアクションをするためには、つまりKGI・KPIを伸ばすためにはどういうことをやればいいかを明らかにしたかったので、アクションする目的や理由も並べています。

ここまでで、各カスタマーの行動とそのときのインサイト、アクションする理由がまとまったので、最後にここに対して僕らはどういう打ち手を打てばいいかの施策出しを行っていきました。

このタイミングでは、実現難易度や工数などは気にせず、とりあえずありえる施策はすべて出す気持ちでブレストしきったのがポイントです。ここからは、どこをターゲットにするかを決めていくフェーズになります。

ターゲットユーザー・シナリオを作成し優先度をつけることが大切

注文住宅では大きく5つのフェーズにカスタマーを分けていて、この中からアンケートの定量データ、定性調査の結果やログの分析結果から、どんなフェーズをターゲットとすれば一番KGIが最大化するかという観点で、メインのターゲットとサブのターゲットを決めています。

ターゲットを決めた上で次にやることは、そのターゲットがどういうシナリオで入り口からアクションまでに流れるかというシナリオを作成していきました。

このように、セグメントに対してどんなユースケースがあるか。そのユースケースにおいてはどういうふうに流入して最後までアクションするためにはどんなシナリオを描くかを細かく書いていきました。

そして、どのユースケースに注目すれば一番KGIに寄与するかで優先度をつけて、優先度の高いユースケース向けに機能設計・IA設計をしていきます。

例えば、会社検索をするシナリオと建築実例を探すシナリオがあります。会社検索シナリオを簡単に説明すると、例えば平屋やローコストなどのざっくりとカスタマーが持ってる希望条件でまずは会社を検索します。複数の会社候補が一覧で並ぶので、建築画像とか会社の参考価格帯などの情報を見ながら、気になる会社を見つけていきます。

会社が気になったらその会社の強みや特徴をもっと知りたい。その会社はどんな家を実際に立てているのかを知りたい。この会社では実際にいくらぐらいで建てられているのかの具体的な金額が知りたい。

これらが自分の希望条件を満たし「いいね!」となった上で「信頼もできそうな会社だね」となるよう、最後の後押しがあった上でアクションにつながるシナリオを描いています。

このシナリオに対して、どの画面が対応するかをサイトストラクチャにマッピングする形で表現しているのがこちらです。ここでは簡単に会社詳細のIA設計について説明します。

リニューアル前はこんな画面で、画面の上から順に会社の特徴を表すような注文住宅の画像があって、会社の特徴を表す文章が続きます。

そして、会社の特徴が詳しくわかるようなコンテンツと会社名・住所・従業員の数など、詳細な統計データが載っているコンテンツがあった上で、カタログの情報、アクションエリアが並びます。リニューアル前はこんなシンプルな画面でした。

しかし、カスタマーはこれだけでは会社の良し悪しを判断できないので、リニューアルではもっとカスタマーが判断できるようなコンテンツを追加しました。

追加したコンテンツと、もともとあったコンテンツを含めてどんなコンテンツがあるのかを並べたのがこの表です。この追加・削除という左から2番目の列の空白のところがリニューアル前からあったコンテンツで、黒丸がついているところがリニューアルで新しく追加したコンテンツです。

差分で言うと、会社の参考価格がわかるコンテンツを入れることと、会社の強みやこだわりがわかりやすいコンテンツを追加したこと。あとは、「なぜこの会社がカスタマーに選ばれてるのか?」「なぜ選ぶのか?」というような、カスタマー目線のコンテンツを新しく入れています。

さらに、実際に建てた人の選んだ理由を口コミみたいな形で入れていたり、会社のスタッフ様のインタビューも今回新たに加えています。そのほかにも、実際に建てた人の価格と広さが一覧化されているコンテンツや、おすすめの建築実例が出るコンテンツといったように、カスタマーが知りたい情報が追加しました。

これらのコンテンツをどうやって画面に落とし込んでいくかを次に説明します、左から4つ目の列を見てください。この列は、この会社の強みや特徴を詳しく理解したいという文脈で会社詳細に入ってくるシナリオを想定し、そのシナリオではカスタマーは「どういう順番でコンテンツを見るのか?操作するのか」という思考や操作の順番を記載しています。複数のシナリオが想定される画面では、シナリオの数だけこれを行い、それをもとにコンテンツの優先度を決めます。

この発表ではシナリオは1つだけで説明しているので、先程の思考・操作順通りの優先度になっていますが、実際には複数のシナリオを想定して優先度をつけています。

その優先度に沿ってコンテンツを並べてリニューアルをしたものが次のページになっています。

リニューアル後はこうなりました。まず画像がとても大事なので、画像を大きくTOPで見れます。その上で会社の参考価格や、会社の特徴の文章を見た上で、会社の強み・こだわりを一覧として知ることができます。詳しく見たい人はリンクをタップすることでより詳しい内容が見られる流れにしています。

次に、「施主がこの会社を選ぶ3つの理由」のコンテンツでより会社に興味を持ったら、次は実際にどんな家を建てているかを知るために、おすすめの実例を見に行きます。

ここまで来たら会社に対して興味を持っているはずなので、最後に信頼感を得るために、スタッフインタビューの情報を確認し、最後に自分のしたいアクションを選ぶ。こういった形でIAを設計しました。

シナリオやIA・UIも仮説。しっかりと仮説検証を!

最後に作成したシナリオ・IA・UIの検証の話を簡単にすると、今回詳細画面はほぼすべてのコンテンツを一新しました。この会社のコンテンツはクライアント様から情報をいただいて入稿する関係上、A/Bテストで簡単に検証することはできませんでした。

なので、ユーザビリティテストでこのシナリオ・IA・UIで本当に問題ないのかを丁寧に検証したというのがこの詳細画面の検証方法です。

ここでは、一般的にリニューアルをするにあたって、こういう検証方法をするとリスクが減るよ、というのを簡単にまとめてみました。

例えば、リニューアルの検討プロセスを①ユーザーの課題・タスクの抽出、②提供価値・ソリューション設計、③シナリオ・IA設計、④UI・デザインという4つのステップで捉えたとき、課題が本当にあるか、提供価値やコンセプトが正しそうかは、ユーザーインタビューで検証できます。簡単にコンセプト検証したい場合は紙芝居レベルの成果物でも検証ができます。

より具体的なソリューションの内容や、シナリオIA、UIの話になってくると、実際にプロトタイプを使って検証することも。ここは検証する内容によって、すごく粗いプロトタイプからデザインを作り込んだプロトタイプまでいろいろな粒度があると思います。「どこの論点を検証をするのか?」を明確にし、検証手法をうまく使い分けながら検証を進めていくことが大事です。

IAや、UI・デザインの論点に関しては、リリースして検証するのが確実なので、A/Bテストで検証することができれば安心です。このように、さまざまな検証方法を組み合わせながら、リスクをどんどん削っていきます。

実際に注文リニューアルでも、多くの変更を実施しようとしたので、すべての変更点や仮説をリスクとして洗い出しました。その上で個々のリスクの大きさを見立て、どのリスクから潰さないといけないのかの優先度をつけ、リスクの判断方法を考え実行していきました。リクルート内では、どんなリスクがあって、どう対処したかを具体的にナレッジシェアしています。

最後にまとめです。大事なことは、まず仮説を置いてその裏づけをする仮説思考で進める。

そして、このようなプロセスで検討すると良いというのが今回のナレッジでした。ありがとうございました!

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

株式会社リクルートテクノロジーズ

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • “放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!