はじめに
「あれ？今日はやたら街が混んでるな」と、12時のランチや平日の仕事帰りに感じることはないでしょうか。
先日、東京の混雑や宿泊・交通需要の波を先読みするアプリ『Peekgo（ピークゴー）』をリリースしました。
Webサービスを作るとき、機能の実装と同じくらい頭を悩ませるのが 「モバイルにおけるUI / UX設計」 です。
説明書や長文を読ませず、数回タップしただけでユーザーが「あ、そういうことね」と直感的に理解できる道具にするため、試行錯誤した 画面設計の意図と割り切り についてまとめました。
1. 検索 & トップ画面：主役である「地図」の表示面積を最大化する情報設計
予約・旅行アプリにおける「場所」と「日付」の入力フォームは、従来型の国内サービスだと画面上部で大きな面積をとり、肝心の地図やチャートが下へ押し出されがちであったり、ページ切り替えが複数回必要です。
Peekgoでは「開いた瞬間に画面下の混雑レーダー（地図）を最も広く見せる」ことを最優先し、海外のチケッティングサービス（Ticketmaster等）を参考に、入力をコンパクトな2列スロット型にしました。
-
段階的な情報開示：
タップした後に展開されるボトムシートは、Airbnbなどのモダンで身近な探索UIを参考にデザインを決めました。「現在地から探す」「マップでピン」「主要エリア一覧」を縦並びで配置し、指の届きやすい画面下部（サムゾーン）で選択が完結するようにしています -
クイック日程バー：
検索バー直下には、日本や海外の重要な年中行事、インバウンドの影響が大きいタイミングを時系列で横並び（スクロール可能）に配置しました。日付を単なる「カレンダーの数字」として選ばせるのではなく、「街の潮目」として直感的に選ばせる工夫です。タップすると該当日のデータが即座に同期し、ボトムシートで何の日かの背景が数秒だけ提示されます -
チャートとマップの連動：
選択した日付と前後の日程の人混みを時系列チャートで可視化しつつ、マップ上ではイベント開催地周辺が青く灯るヒートマップで直感的に過熱感を伝えます
2. その日のおでかけのアドバイス機能（Tips）
混雑数値やグラフを提示するだけでは、「で、結局自分はどう行動すればいいの？」という疑問が残ります。
そこで、混雑ピーク予報のヘッダー右端に『Tips』ボタンを置きました。タップするとボトムシートが開き、その日特有のおでかけ需要の強さに加えて、大まかな傾向を展開します（1時間単位の細かい数字よりも、行動判断に必要な「街の傾向」に絞るための割り切りです）。
-
ランチの混雑傾向（並ばずに入れる時間帯、オフィス街の状況）
-
ディナーの混雑傾向（居酒屋にふらっと入れるか、予約しておくべきか）
-
温浴・スパの混雑傾向（サウナが混み合う時間帯、おすすめの穴場時間など）
長文の観光ガイドを読ませるのではなく、雨雲レーダーを見て「折りたたみ傘を持っていこう」と判断するのと同じ感覚で、0秒で立ち回りを決められるUXを目指しました。
3. リコメンド機能のデザイン（PLAN B）
ホテル予約サイトで最もストレスなのが、「本命エリアが値上がりしすぎていて泊まれないとき、どこに泊まれば良いのかわからない」という問題です。既存のアプリでは「日程をずらせ」としか言えませんが、旅行やライブ遠征の日程はずらせません。
そこで、「日程はそのままで、空間を回避する」ための『PLAN B』機能を設計しました。
-
RATE TIDE：本命の宿泊エリア（渋谷など）が平常時と比べて何倍に値上がりしそうかを波形グラフで可視化し、イベント等の影響をうけるを表示
-
PLAN B：本命エリアが過熱している際、ワンタップで「直通電車で12〜15分」「乗り換え0回」で移動でき、かつ安く泊まれそうな周辺駅（武蔵小杉なら今61%安いなど）をリコメンド
国内外問わず、土地勘のない旅行者でも、トグルを1回切り替えるだけで「安くて近い逃げ道」を見つけられる体験を作りました。
おわりに
UI/UXを考えるとき、「機能をたくさん足すこと」よりも「迷いを減らし、数タップで答えに辿り着かせる引き算」のほうが遥かに難しく、何度もコードとレイアウトを書き直しました。
次は、これらのデータをサーバー代ほぼ0円かつ高速な初期表示で届けるために採用した、Astro（SSR / アイランドアーキテクチャ）と Cloudflare（Workers / R2 / D1）によるエッジ構成についてまとめたいと思います。