DeNAのデザイナーのセカンドルです。DeNAデザイン本部に所属しつつ、カーシェアアプリ「Anyca」でプロダクトデザインを担当しています。
Anycaではユーザーさんの声やデータをもとに日々サービス改善を進めていて、今年の8月に「クイック予約」という機能をリリースしました。
この機能はとても複雑な仕様で影響範囲が多くあったのですが、2週間で体験設計とUIデザインを行う必要があったので、以下の2点を特に大切にしながら案件を進めていました。
- 要件を鵜呑みにしすぎず、ユーザビリティを意識しながら体験を磨き込むこと
- チームメンバーの頭の中を可視化しながら合意を取っていくこと
複雑な機能を作っていくとき、どこから手をつけるべきかどのように合意を取っていくべきか分からなくなることって大いにあると思います。そういったお悩みを持っているデザイナーの仲間のみなさんにとって、今回の記事が少しでも参考になれば嬉しいです。
まず初めに、カーシェアアプリAnyca (エニカ)と今回作った「クイック予約」という機能について簡単に説明させてください。
Anyca は、個人間でクルマをシェアする新しいカーシェアリングサービスです。個人オーナーのクルマをシェアできるため、SUV、オープンカー、ミニバン、キャンピングカー、トラックなど、多種多様で幅広いバリエーションのクルマを好みやシチュエーションに合わせて選ぶことができます。
Anycaではクルマを持つオーナーとクルマに乗りたいドライバー双方がアプリ内のチャット機能を使って話し合い、条件がマッチングしたときに予約が成立するのですが、チャットに返信するのが遅れてしまったり、話し合いの結果条件が合わずに不成立となってしまうことも少なくありませんでした。
そこで、オーナーが先んじて条件を提示でき、その条件内の予約であれば、チャットでのやり取りをはさまずに即マッチングできるような機能を検討しました。それが「クイック予約」です。
オーナーがクイック予約を利用すると
- シェアできる時間
- クルマの受け渡し場所
等の条件をあらかじめ設定でき、設定された条件に合う形でドライバーから予約のリクエストがあった場合、即時に予約が成立します。
この「クイック予約」は、
- 夏休みの旅行シーズンに需要が高まることを想定してなるべく早くリリースしたい
- まずは短期間でリリースし、ユーザーからの反応を見てよりフィットした機能にブラッシュアップしたい
という理由から短期間でのリリースを目指していて、企画〜UIのFIXまでを2週間で行いました。
この案件ではPdMの方がPRD（プロダクト要求仕様書）を作ってくれました。
この資料には、クイック予約を実装することで救いたいユースケースや、現状考えられるユーザーのペインがまとめられています。
このPRDをたたき台に、要件をブラッシュアップするために下記のステップで案件を進めました。
① 想定スコープの可視化
② UIに起こして、体験を俯瞰
それぞれについてまとめていきます。
PRDをもらっていきなりデザインに入るのではなく、実際の体験に落とし込んだ時に違和感が無いか確認していきました。
PdMの方を信頼しつつ、自分の目線で疑問に思った箇所について、現在の仕様にした理由を聞いたり、適宜提案をしていくようなイメージです。そうすることでユーザーに届けたい価値や機能に磨きがかかっていきます。
Anycaの体験フローに沿って図に起こすと、
- マストで必要な改修
- あると嬉しいけどマストではない改修
が見えてきます。
この施策を作る目的やスコープ、その理由を整理してまとめておき、いつでも立ち戻って目線合わせができるようにしていました。
どうしたらユーザーがこの機能を快適に利用できるかを考えながら複数パターンのUIを検証しています。
前述のようにクイック予約を利用するとオーナーがシェアの条件を設定できるのですが、どこまで細かく条件設定ができるようにするかで、下記のようにチームの意見が割れました。
- オーナーは日付単位で細かく時間設定をできるようにしたい
- そもそも深夜早朝などといった非常識な時間を避けることができれば細かい設定は不要
- 時間設定自体が不要で、優良ドライバーのみクイック予約を利用できるようにしていればOK
クイック予約は即予約成立機能なので、極端な話オーナーが拒否していなければ深夜早朝の時間帯にクルマの受け渡しを行うシェアも成立してしまいます。
条件を細かく設定できるにこしたことはないと思いがちですが、オーナーが条件を細かく設定できるようにすると、ドライバーに複雑な条件の理解が求められ利用ハードルが上がります。オーナー/ドライバー双方が利用しやすく長期的に使いたくなるような落とし所を探っていく必要がありました。
ここまで進めてみて、思ったよりチームメンバー内のイメージがずれていることがわかったため、この機能を作る際の軸（ペルソナやユースケース）をわかりやすく可視化しながら、再度すり合わせる工程を挟むことにしました。
急遽ユーザーインタビューを行いつつ、今まで獲得してきたデータと照らし合わせてオーナーのペルソナを設定し、クイック予約を利用するに至るストーリーを整理しました。
すると、クイック予約を利用しそうな想定オーナーは、シェアに対してかなり前向きで多少自身の都合が悪くてもドライバーからの要望に応えようと調整する方が多いということが分かりました。
また、積極的にシェアを募集しているオーナーであったとしても、何かしらの予定が入っている日にまでクイック予約を適用することは考えづらく、基本的には何も予定がない日のシェアをクイック予約を利用する想定ケースとしました。
なので、細かく時間を設定する必要はなく、深夜早朝などといった非常識な時間帯にクルマの受け渡しを希望するシェアのみを弾くことができればよいと判断しました。
次に、設定したペルソナがどういう状況だったらクイック予約を使ってくれるかを考えます。
クイック予約は即時に予約が確定する機能なので、そもそも”予定がある日”や”少しでも予定が入る可能性がある日”は利用されないだろうと考え、使われるケースのイメージを固めていきました。
また、上記ユースケースを元にUIのたたきを作り、それぞれの画面でユーザーがどのような情報を求めているかを検討しました。
そうすることで画面単位のコミュニケーションではなく、全体の体験を通してユーザーに必要な情報を少しずつ伝えていく情報設計を目指していました。
今まで考えてきたペルソナ、ユースケース、必要最低限の機能を元に、ユーザーがよりシンプルに簡単にゴールまでたどり着けるような体験フローを考えていきました。
いくつかのパターンが想定でき、それぞれメリットデメリットがあるので、プロトタイプを作りチームメンバーを巻き込んで意思決定をしていきました。
機能のカラーも合わせて検討しています。Anycaで普段使用している既存のカラーにはそれぞれ意味や役割があるので、同じものを使わずにユーザーにしっかり認知されることを目的として選定しました。
こうして、2週間という短い期間でしたが、クイック予約の体験設計とUIを完成させることができました。
無事にスケジュール通りに実装に入ることができ、8月からクイック予約は使えるようになりました。リリースして新しい課題も見えてきたので、引き続き機能のブラッシュアップを進めています。
チームメンバーとの打ち合わせ中に、相手の伝えたいことが分かりづらく感じることはありませんか？今回作った機能はとても複雑な仕様だったので、理解が追いつかずにメンバーのイメージが少しずつズレていると感じることが多々ありました。
口頭のみで会話していると、全員が同じ認識を持つのに時間がかかってしまいます。そのためデザイナーが目に見える形で要件をまとめ、ステークホルダーを巻き込んで積極的に議論を導き、案件を進めていく動きが求められると感じています。
今回は時間がかなり限られていたため丁寧に進めることでスケジュールを守れなくなる不安もありましたが、そんな中でも常にチームの認識を合わせながら、メンバー全員が同じ方向を向いて案件を進められたからこそ期日内にリリースができたと思っています。
Anycaはこの機能に限らず、引き続きチーム一丸となってサービス改善を進めていますので、これからにご期待ください。