フードデリバリーサービスにおけるオブジェクト同士の関係性と体験の考察

私はUberEatsというフードデリバリーサービスが大好きで、週3回以上使っています。

初めてUberEatsを使った時、食べたい料理を複数の店でまとめて頼めることができたら非常に便利だな、と想像しながら実際にアプリを触っていました。
ですが、1軒目の商品をカートに追加した後に、2軒目の商品をカートに追加しようとしたら、急にモーダルが表示されて「新しいカートをご利用になりますか」と聞かれました。
内容を見てみると「現在のカートにある商品を削除して、2軒目の商品を追加しますか」と書いてありました。このモーダルで、カートは1軒の店に限られていることに初めて気付きました。

普段よくAmazonや楽天市場を利用していますが、カートは1軒の店に限られてはいません。それに慣れていたのですが、UberEatsはカートが1軒の店に限られていました。
ここで、他のフードデリバリーサービスも同じ体験であるかどうかを考察したいと思います。

オブジェクト同士の関係性と体験設計

UberEatsをリバースモデリングして、ユーザー、注文、カート、店、商品の関係性が下記のようになっているのではないかという仮説を立てていきました。

ユーザーは、1つのカートを持っています。1つのカートには、0または1つの注文があります。1つの注文には、1軒の店があります。そして、1軒の店は複数の商品を持っています。

1カートにつき1つの注文、1つの注文につき1つの店という関係性であるため、複数の店の商品をカートに追加しようとしたら、確認モーダルが表示され、1軒目の商品だけカートに残るような体験になっているのではないかと考えられます。

他のフードデリバリーサービスもリバースモデリングして、考察してみました。そのすると、3種類のパターンがあることがわかりました。

対象のフードデリバリーサービス：出前館、menu、Wolt、楽天デリバリー、Chompy、EASI、FOODNEKO、foodpanda、deliveroo

パターン1：カートに1軒の店の注文のみ

ほとんどのサービスはUberEatsと同様に、2軒目の商品をカートに追加しようとしたら、どちらかの注文しか残せないという体験でした。
（出前館・menu・Chompy・FOODNEKO・foodpanda・Deliveroo）

その中で、menuはちょっと違う体験となっています。

menuの場合は、2軒目の商品を追加したら、1軒目の商品が検討中の注文として残すことが可能、また、検討中の注文をカートに戻すことも可能となっています。

その理由として、menuのオブジェクト同士の関係性が下記のようになっているからではないかと考えられます。

カートには、0または複数の検討中の注文があります。

「検討中の注文」という概念があると、複数の店を検討したいユーザーにとっては、とても便利な機能になるのではないかと考えられます。

パターン2：カートに複数の店の注文を追加することが可能

楽天デリバリーの場合は、カートに複数の注文を追加することが可能のため、2軒目の商品を追加しようとした時に、スムーズに追加することができました。

下記の左画像のタブのところにある「2」といういう数字は、注文が2つ入っているという意味です。

ただし、同時に複数な店を注文することができないため、別々の注文手続きが必要となります。

楽天デリバリーのオブジェクト同士の関係性が下記のようになっているのではないと考えられます。

カートには、0または複数な注文があります。

EASIの場合も、カートに複数の注文を追加することが可能で、しかも店ごとにカート（買い物かご）を持ってるように見せて、その店の注文だけ表示して注文に繋げるようにしています。

下記のように、左画像のカートのアイコンに2が表示され、真ん中の画像ではカートの詳細に2つの注文が入っていて、一番右の画像では店の詳細ページでその店の注文だけを表示しています。

パターン3：カートという概念が存在しない

Woltの場合は、そもそもカートという概念がありません。そのため、店の詳細からしか注文できません。また、1軒目の商品を注文に追加した後に、店の詳細から出ようとすると、「メニューを離れますか？」という確認モーダルが表示され、店から離れても、選択した内容は保存されるという体験でした。（もう一回店に戻ったら、「前回の注文を選択する」というモーダルが表示されます。）

Woltのオブジェクト同士の関係性が下記のようになっているのではないと考えられます。

普通の注文は商品が入ってないと存在しないという性質がありますが、Woltの場合は、注文が店に依存しているなので、店から離れると注文が一時的に保存されるという制約で、店から離れると店に戻るたびに、ユーザーに確認しないといけないという体験になっています。

考察

今回考察したサービスの中では、楽天デリバリー、EASIが理想的な体験を実現しています。
ここでわかるのは、オブジェクト同士の関係性によって、理想的な体験が決まるわけでは無いということです。

楽天デリバリー、EASI以外のサービスにおいて、オブジェクト同士の関係性が理想的な体験を妨げているとは考えにくく、別の制約によって理想的な体験を妨げられているのでは無いかと推測します。

何らかの制約によって途中でモーダルを表示させざるを得ない。これは、ユーザーの行動を邪魔していると考えられます。

おわり

今回は、フードデリバリー サービスのオブジェクト同士の関係性と体験を考察しました。

理想的な体験は、ユーザーが達成したいゴールに向かっている最中に、ユーザーの行動を邪魔せずに、スムーズにゴールを達成できるように設計すべきです。極力モーダルなどを使わず、モードレスを目指すべきだと考えられます。