CASE STUDY 02

HouseeS

Smart Phone Apps
Yahoo!不動産 新築マンション検索アプリプロジェクト
フォーデジットデザインの仕事について、実例を通してご紹介するケーススタディ。今回は、2013年に手がけた「心地よい、マイホーム探しアプリ HouseeS」です。「Yahoo!不動産」(ヤフー株式会社様)の本格的なスマホアプリ展開に弊社がどう取り組んだかを、現場の制作者視点でお届けします。
クレジット
PRODUCE : 田口 亮
PMO:藤原 正平
CD : 西垣 伸之
AD / DESIGN : 石田 康太
DEVELOP:futurek INC.
クライアント
ヤフー株式会社

与件整理

はじまりの六本木ミッドタウン

2013年春、まだ肌寒い3月末にやってきた、熱い想いを帯びたプロジェクトへの誘い。それは、日本全国の住まい探し情報を提供する「Yahoo!不動産」の本格的なスマホアプリ展開だった。さっそく六本木のヤフー株式会社を訪ねての打ち合わせ。フォーデジットデザインからはプロジェクトリーダーの田口亮、プロジェクト管理担当の藤原正平、クリエイティブディレクターの西垣伸之、またすでにYahoo!不動産とお付き合いのある僕らのグループ会社・イーサグラムの間宮真介も参加していた。まずは先方から企画コンセプトやプロダクトイメージ、ビジネスゴール(KPI: Key Performance Indicators=重要業績評価指標)などの与件を頂く。

企画コンセプト
スマホならではの心地よさ、使い勝手を重視した未来のマイホームアプリ
プロダクトイメージ
  • ・「新築マンション探し」専用のスマホアプリ
  • ・従来の類似アプリとはひと味違うもの
  • ・いま風なインターフェイスを提供したい
  • ・物件画像をより豊富に見せたい
ビジネスゴール
  • ・ダウンロード数やコンバージョン率(資料請求 / 説明会予約)
  • ・App Store, Google Playなどマーケットプレイスでのユーザ評価を重視

これをもとに、僕らからの提案を考えていく。フォーデジットグループ全体ではすでにお付き合いも長いクライアントだが、今回は各社が横断的に絡む新しい挑戦。僕らはそこにどんな価値を提供できるだろうか?

疑うステップ

「何を作るか」の前に「なぜ作るのか?」を疑ってみる

与件を受けて最初に取り組んだこと。それは社内で「なぜいまYahoo!不動産のスマホアプリが必要か」議論することだった。そもそも先方の依頼だから「必要」なのは当たり前? そう言われればその通りだ。「Yahoo!不動産」はすでに業界大手の地位を確立する一方で、当時スマホアプリはAndroidのみ対応。本格展開はこれからだった。もちろん後発でも、ビジネス的にはメリットがある。「ウチの店で決めてもらう」ための窓口は多いほうが良いし、その選択肢としてスマホは今後外せないはずだから。

ただ、ユーザーにとってはどうなんだろう?すでに世にあるものと似たアプリが市場に並ぶことで、彼らの住まい探しに新たな付加価値が加わるのか。つまり、このプロジェクトはユーザーにとってどんな意味があるのだろう?

あえてこうした「疑うステップ」を入れることで、案件のより深い理解や、後の発展につながる可能性は高まる、と僕らは考えている。

これは示されたゴールを、自分たちで咀嚼する試みといってもいい。そこまで遡ることではじめて共有できるクライアントの想いもあるはず。「従来のマンション探しアプリとは違うもの」という彼らのシンプルな言葉も、きっと上述のような想いを経由している。こうした思考をたどり共感することで、垣根を超えたチームを作っていきたい。

そう、今回の僕らの仕事は、看板違いの類似アプリ作りではない。「マンション探しに新しい価値を与えたい」というこのチームの意思を、デザインで表現することなのだ。

社内ブレスト

ブレスト、そしてプロダクトイメージヘ

続いて社内ブレストを行った。まずは既存の同業態アプリ群を実体験。その課題を列挙してみた結果、鍵となる検索について多くの「めんどい」「しんどい」が挙がる。

  • ・検索方法(○○から探す)が多すぎてめんどい
  • ・路線やエリアのドリルダウン(例:東京都→JR→山手線→渋谷駅)がめんどい
  • ・選択リストが細かくてしんどい
  • ・(といった手間の割には)詳細情報が少ない
  • ・(その結果?)条件入力→該当リスト表示→条件修正…をただ繰り返してしまう
他にも、
  • ・資料請求のゴリ押し感が気になる
  • ・なんだか事務的
  • ・そもそも家を買う人ってアプリで探すの?
  • ・間口を広げるなら「診断系」とかもアリ?
  • ・希望物件の新着時のみプッシュ通知する(だけ)でもよい?

などなど、あらゆる角度から意見を出し合う。

概念モデルは、不動産屋のおじさんに直接相談するイメージ。

ここで再確認したのは、ユーザーのマンション探しの行動も多様だろうということ。「この路線周辺で」という人、予算で探す人、物件タイプの希望がある人……。マンション購入層がスマホで物件探しをするのか? の素朴な疑問も、むしろそうした人々をも迎え入れる親しみ易さがあれば広がりが期待できる、との考え方にシフトしていった。

結果的に参考にした概念モデルは、誰もが賃貸などで経験する、不動産屋のおじさんに直接相談するイメージだ。すなわち…

  1. 1「この辺りで、こういう感じで探してるんだけど」
  2. 2担当さんが分厚いファイルを取り出して人力検索
  3. 3「こんなのあります」リストを見つつ、気になる情報はストック
  4. 4「ちょっと条件違うけど、こういうのもいかがですか?」
  5. 5気に入ったら、さらに候補に追加
  6. 6「ちなみに別エリアも検討してて、そちらだとどう?」
  7. 7担当さんが別ファイルで人力検索…以下同様

多くの人が慣れ親しんでいる「不動産屋訪問式」。

もちろん、新築マンション探しには異なる要素もある。しかしここでは、めんどい・しんどいを解消する心地よいアシストのため、すでに多くの人が慣れ親しんでいる現実のフロー、その良い面に着目してみることを試みた。

《「不動産屋訪問式」のフローで抽出された点》
  • ・最初はキーワード(最小限でもよい)から入る
  • ・できうる限りアシストする
  • ・候補はこちらから提示する
  • ・写真もたくさん見せてあげる
  • ・検索結果に縛られない(「こういうのもいかが?」)
  • ・お気に入りのレベルを付けられる
  • ・気になる部分、気に入った部分はメモも残せる

こうして、新アプリの方向性およびラフな機能イメージが作られていく。

プロトタイプ作成

使えるものはデジタルでも、アナログでも

目指すアプリの輪郭が見えてきたある日、田口・西垣のふたりで深夜の集中クイックシンク!主要画面のラフスケッチをざっと描き上げた。こういうときは何だかんだ言っても手描きがとにかくスピーディで、コミュニケーションも取りやすい。最近はUI Stencil などが、スマホ画面の考案用に使い勝手のいいシートも提供している。

僕らは勢いに乗り、さらにこれをそのままプロトタイプツールに突っ込んでみた。今回はfluidを使って3時間程で作業完了、これでプロトタイプが出来上がり。早い段階でイメージ共有とフィードバック取得ができる利点は大きい。関連ツールの進化と共に、プロトタイプ活用は今後より重要性を増していくと思う。

提案書とプレゼン

ゆるめでも「決め台詞」を

続いては提案書。通常、僕らはこれを「与件整理+方針」「コンテキスト分析」「プロダクト」「コスト+スケジュール」「体制」の流れでまとめている。プロダクトの説明では、ネット経由のマンション探しにおける基本行動となる、以下の流れを解説した。

「検索→リスト表示→詳細表示→お気に入りをストック→シェア・コンバージョン(資料請求・見学会申込)」

その上で、各ステップで最適な機能化を図ることを提案した。今回はいわば、『「鉄板」の流れを押さえつつ、細部をバージョンアップする。』というやりかただ。プレゼンで工夫したのはそれぞれの機能の「決め台詞」。たとえば今回は目指すアプリの検索性について、対人的な柔軟さを表す言葉として「ふわピタ ファジー検索」などを打ち出した。プレゼン時のウケ具合はまた違う意味でファジーだった(!?)かもしれないが、開発前にこうした言葉でイメージを共有してもらうのはとても大切なはず。。

プレゼンの結果、僕らのプロジェクト参加が正式に決定された。

たとえば、目指すアプリの検索性について、対人的な柔軟さを表す言葉として「ふわピタファジー検索」と打ち出し、開発前にこうした言葉でイメージを共有してもらう。

ユーザー検証

いざ製作!の前に

契約手続きにかかる時間も無駄にならないように、進められる部分は出来る限り実作業に突入する。ただしいきなり制作開始ではなく、僕らはここでユーザー分析の仮説検証を試みた。これは考案したアプリの機能が、想定ユーザーの要望をきちんと満たすのかどうかを探るヒントとなる。

テストの概要はこうだ。対象は、今回KPIとしても挙がった「マーケットプレイスでの評価」が高い競合アプリ。これを被験者に使ってもらい、その反応を動画とインタビューで観察する。対象は社内のデザイナー・ディレクターを中心に、グループの社長も駆り出して行なった。
今回は被験者群を「マンション購入意欲」「スマホ操作の慣れ具合」の2軸でとらえ、4象限のタイプに分類。

・具体的に購入予定 + スマホ操作に慣れている
・具体的に購入予定 + スマホ操作に不慣れ
・購入に関心はあり + スマホ操作に慣れている
・購入に関心はあり + スマホ操作に不慣れ

結果、全ユーザーの共通点(とにかく候補物件を多く見たい)、またスマホに不慣れなユーザーの予想外のハードル(使い易いか以前に「自分にも使えるか」で早々に挫折)などが浮かび上がった。これに基づき仮説部分を一部訂正、改めて資料化していく。

ゴールを見据えた上で、動きながら、動かしながら考え続けることで見えていなかったこと、違うものを見ていたことに気づくことができる。

ユーザーインターフェース構築

「心地よさ」を鍵に方向性と質感を探る

ユーザインターフェイス(UI)構築では、まずサービスの垣根を超えて人気アプリ群を調査、今回ヒントになりそうなものをピックアップした。その上で、西垣やアートディレクターの石田康太らクリエイティブチームが「こんな感じ?」と共通認識を持てる部分を抽出。「とっつきやすい」「わかってくれる」「ライトなわくわく」などキーワード化も行い、方向性と質感をかたちづくっていく。

リサーチでピックアップされた参考アプリ群。業態にはこだわらず、ヒントとなるものを探った。

一方この過程では、検索結果のリスト表示で定番の縦並びの画面だけなく、あえて横方向スライド式の画面なども実験。最終的にはやはり縦リスト画面を選択したけれど、個別物件の写真群閲覧で横スライドを取り入れるなどしている。また、この世界特有っぽい細かい対応も随所に。たとえばサムネール画像において、マンションの画像は中央揃えで切り取るより、青空と最上階が表示される上揃えが見栄えもいい。また検索ワードの入力時、ユーザーをただ待たせずに、ヒット件数を先に表示する機能なども盛り込んだ。

デザインコンセプト

ブランドとユーザーのあいだで

先行フェーズを受けてデザインコンセプトを策定。サービス(アプリ)名は「HouseeS」ということで決定し、並行してアプリロゴにも取りかかった。石田が考案した最初のロゴはここまで打ち出してきた「親しみやすさ」を反映し、「HouseeS」の語感からのイメージもふまえてキャラクター性を持つポップなもの。しかし、このアイデアは充分に検討いただいた結果、要再考となった。クライアントの求めるスタイリッシュさ・シンプルさと必ずしもマッチしなかったのだ。
ユーザーゴールを元にしたイメージ構築は間違いではないが、ブランドはその上位概念であり、この土台への意識は十分に配慮されなければいけない。

そこで根本的に再検討し、シンプルな色使いとデザインの現ロゴが完成。これは競合アプリ各種との効果的な差別化にもつながった。なお「Yahoo!不動産」は賃貸マンション探しのスマホアプリ「Rent RooomS」も進めていて、このロゴも同じコンセプトで提供させて頂くことになったのだ。

ユーザーゴールを元にしたイメージ構築は間違いではない。しかし、ブランドはその上位概念であり、この土台への意識は十分に配慮されなければいけない。

データベースとの対話

IAと技術制限

HouseeSはPC版「Yahoo!不動産」と共通のデータベースから、既存の専用APIで情報を引き出す。そこで、APIの仕様やデータ構造の詳細を理解した上で情報設計を行う必要があった。各管理項目とその入出力ルールを確認し、得られるデータがそのまま広取委の不動産表示ルールを満たすのか?なども細かくチェック。機能の実現性をスタディしつつの情報設計になった。なお、前述のグループ会社・イーサグラムが「Yahoo!不動産」の業務に参加していたので、彼らとの情報交換も助けに。横断的なミーティングも短期間で実施し、グループ会社の強みが活かせた一場面とも言える。

ユーザーの指定条件に厳格になりすぎず、かといって的を外さず、というアプリ実現のため検索UIは大きな柱だ。そこでAPI動作の確認用に、まずPCブラウザ上で動く検索UI呼出プログラムをHTML+Javascriptベースで作成。

実動作を詳細に確認すると、やっぱり実際ふれてみてはじめてわかることが出てきた。さらにユーザービリティの視点からも、快適な検索フローの実現見込みなどを検証する。

一方このころ、デザイナーサイドも設計たけなわ。プロトタイプをワイヤーフレームに起こし、情報のひも付きを可視化、コンテンツマップを作成する。さらに検索リスト、詳細表示それぞれの表示、コンバージョンにあたるボタンの位置やサイズまで、ユーザインタラクションも含めて続くデザイン作業に備える。

もちろん、両者は互いの状況を把握し合いながら作業する。実装へ落とし込んでいくプロセスでは、こまめなミーティングの積み重ねも忘れなかった。

デザインとユーザーテスト

ふたたび「使う側」へ

こうして主要ページが揃い、検索機能を除くHTMLベースの遷移モックアップを実現!レビューを繰り返し、主要インターフェイスはほぼ完成版レベルまでブラッシュアップされた。やっとここまで、という気もするが、実際はプロジェクトが本格スタートしてから約1ヶ月半というところ。モックアップの利点は、メンバーが実際にふれながら各所を確認し合えること。さらにいいのは、ユーザーテストが実施できること。やはり、生の反応がナンボの世界。

ユーザーテストはヤフー社のテストルームを会場に、丸3日かがりで行った。デザイナーやデベロッパー、さらにヤフー側チームも一緒に、関係者総出のディスカッションに突入。ホワイトボードがみるみる文字と図で埋まっていく……。

並行してアイコンレベルから各種インタラクションまで、グリグリと修正が入り詳細が仕上げられていく。ともすれば初見ユーザーの感覚から離れてしまう時期だけど、直前のユーザーテストの副次効果もあり、皆の目線はしっかりユーザーを向いたまま、議論が進められた。一方、微修正が常に行える環境は、議論が詳細に及んでしまう場面もあり、プロジェクト管理の面では課題も残した(これは記事の最後にふれたい)。
ともあれ、これで実機への搭載前に検証できる環境は整った!

モックアップの利点は、メンバーが実際にふれながら各所を確認し合えること。さらにいいのは、ユーザーテストが実施できること。やはり、生の反応がナンボの世界。

最終調整

「試せる環境」と「動くべき環境」の併走

今回、iPhone/Android版の同時対応もあり、実装では開発経験の豊富なフューチュレック社に加わってもらった。実機での開発を彼らに進めてもらいつつ、僕らは何をしていたか? HTMLベースのモックを作成し、これまで挙った要確認トピックを実験していた。

「動くもので試せる」環境を整えることは、開発の重要なポイントになった。もしこれを省いて実機開発に進んでいたら、意図せず重要な検証をすっ飛ばしたかもしれず、テストで気づかなかった問題に対応できなかったかもしれない。コスト面での大事な検証を、後回しにせざるを得ない可能性もある。それらの懸案をクライアントと試行錯誤しつつ、実機での動きをフューチュレックと確認し合う、という手順を並行させた。

そして、初春のスタートから季節も入れ替わった夏のある日――。ついに物件データ部を切り離した状態で動作する実機試作版アプリが完成。メンバー一同がヤフー本社に集結し、「Housees」アプリの産声を体感した。

とはいえ作業はさらに、API部の実組込へと続く。この段階でも、さわればさわるほど「ここはもっとこういう感じだと…」との声は尽きず、納得いく使い心地になるまでブラッシュアップは続いた。ちなみにここでもHTML製モックは活躍、インターフェイスの負荷やレスポンスなど、使い勝手を確認しながらの作業をスムースにしてくれた。

Ver1.0

各環境の動作確認を経て、Ver1.0の完成!

そんなこんなで、ようやくver 1.0の完成!!細部の調整を残したリリースレベルにたどり着いた。後はiOS / Androidの各バージョンで最終確認だ。

しかし、ちょうどその頃、プロジェクトを進めながらタイミング的にあやしいあやしいとうすうす気づいていたこと、、、つまりiOS7がリリースされたのだった。ちょうど、プロダクトが出来上がるというタイミングだったが、最終的に正式リリースはこれにしっかり対応し、クライアントから先行して頂いた機能追加も盛り込んでから行うことに決まった。

2013年もまさに暮れようとする12月18日。HouseeSはApp Store、Google Play の両舞台でデビューを果たした。先行する競合アプリがユーザーに揉まれ進化する中、Houseesの本当の勝負はこれから。しかし、その一歩を自信をもって踏み出すことはできたと思う。奇しくもローンチ当日の開催となった全プロジェクトチーム参加の忘年会では、「このアプリをこれからも継続して育てていこう」と一同が確認し合った。

  • 使えば使うほど便利になる設計

  • ビジュアルを、大きく、美しく

  • 不動産屋にいるかのような体験

  • メモを残せる現実に近いフロー

まとめ

このプロジェクトで学んだこと

  • 決めるべきことを決める。

    要素や画面設計・インタラクションなど、UIデザインを進めていく中では同時に様々な判断が必要となるので、どれかにフォーカスしすぎないこと。実際に触って動くもので判断すべきこともあり、そのときに判断しなければならないことを意識して進めるのが大事。

    Kota Ishida , AD

  • 全部入りにはしない。

    検索機能・ビュー切り替え・ソート項目などなど、機能を追加することで問題を解決しようということもあるが、あった方がいいという理由での機能追加はコンセプトを揺るがすことがある。「本当にその機能がこのサービスに必要?」か充分に検討する必要がある。

    Nobuyuki Nishigaki , CD

  • ものづくりに大切なのはまずチームづくり。

    クライアントも制作側も、常に同じ目線でプロジェクトを進められるかどうか。こと自分たちが手がける「ものづくり」の面においては、このことを忘れずにいたい。

    Shohei Fujihara , PMO

  • ユーザーの声は問題発見の種。しかし問題解決の答ではない。

    ユーザーとは、どんなものを提供しても「ここがわからない」と言う。そして、こちらの期待通りには行動してくれない。彼らの意見・意図を一度分解し、プロとしての解決法を検討すべき。

    Ryo Taguchi , CEO

クライアント様からのメッセージ

ヤフー株式会社 梅本様

確固たる意思を持つ頼もしいパートナー

今回のプロジェクトをフォーデジットデザインさまと進められて良かったと思っています。
それは、いい意味でこちらの希望通りに組んでくれないから。
1つ1つの提案に根拠と意思があり、おかしいものはおかしい、良いものはもっとこうしたらどうか、
と常に同じ目線で考え、一緒に試行錯誤し、プロジェクトを完成まで導くその過程は、
とても信頼のおけるパートナーであり、刺激を受けるものづくりでした。

Contact Us

お仕事の依頼やご相談、弊社ご説明は
こちらからお問い合わせください。
TEL : 03-5774-6809 / 
FAX : 03-5774-6705