ネイルブックの「近くで予約できる」タイムラインができるまで
ネイルブックの開発プロセスの一端をご紹介します。
現在、ネイルブックでは「ディレクター」という明確なポジションがなく、デザイナーやエンジニア、サポート、マーケが企画を立て、それぞれディレクションするという、ちょっと変わったやり方をしています。
この企画はエンジニア起案。エンジニアが中心となって開発を進めています。
課題・仮説
解決したい課題
ユーザとサロンのマッチング精度をもっと向上させたい
ネイルブックではネイルデザインでユーザとサロンをマッチングさせていますが、タイムライン上で「これ、やりたい！」と思っても、そのサロンが遠くて行けないことが多い。
仮説
タイムラインに「位置」の概念を導入し、近隣サロンのデザインだけを表示すればマッチング機会が増えるはず！
プロトタイピング
ユーザの場所を反映した「近くで予約できる」というタイムラインを新設することにしました。タイムラインはネイルブックのメイン機能でユーザに与える影響も大きいため、プロトタイピングで検証を繰り返しました。
IPアドレス方式
IPアドレスで大まかな位置情報を把握する方式で実装しました。メインユーザが女性なので、位置情報を送信することについて抵抗があるだろうという判断です。
実際に実装してみたところ、IPアドレスでの位置特定精度が悪く、隣の県のネイルデザインなどが表示されてしまう、などがっかり感が多い結果となりました。
IPアドレスから位置情報を特定する他のAPIも試してみましたが、どこもいまいち。。。
IPアドレスと位置情報のハイブリッド
IPアドレスで推定する方式はそのまま残し、精度を上げたい人は明示的に位置情報を送信する方式にしました。
位置情報を利用することでタイムラインの精度は抜群に良くなりました！しかし、ここでエンジニア内で議論に。
そもそも精度の悪いIPアドレス方式をユーザに提供する必要があるの？
位置情報方式
タイムラインを価値のあるものにするためには位置情報が必須と判断し、位置情報がないと利用できない機能にする決断をしました。
そのかわりユーザには位置情報の必要性を丁寧に説明し、できるだけ位置情報を送信してもらえるように画面遷移を工夫しました。
ここまでの過程はエンジニアだけですすめ、方式や画面フローが固まった段階で、やっとデザイナー登場です。
せっかく作ったIPアドレスから位置情報取得する機能を捨てるのは、なかなか勇気がいりました😅
こうしてプロトタイプした最終バージョンは年明けにリリース予定！
お楽しみに！