昨天把 User Flow 畫完之後，使用者到底會怎麼找店，總算比較清楚了。
今天換一個很容易越做越大的東西：Sitemap。
一開始最直覺的做法，通常就是一個功能配一個頁面。
有搜尋，就做搜尋頁；有地圖，就做地圖頁；有收藏，就做收藏頁；有會員，再補一個會員中心。
結果程式都還沒開始寫，網站已經先長得像政府入口網站。
所以今天我想反過來：

不是先問「網站應該有哪些頁」，而是先看「使用者完成找店這件事，到底需要哪些畫面」。

先從昨天的 User Flow 開始

昨天最後留下來的主流程，大概是：

定位／搜尋地點
↓
看到附近店家＋核心工作資訊
↓
套用工作條件
↓
比較店家
↓
需要時看詳情
↓
Google Maps 導航

先不管頁面名稱，我把每個節點可能會出現的畫面全部攤開。
第一輪很自然就會長出這些東西：

• 首頁
• 探索頁
• 地圖頁
• 列表頁
• Filter
• 店家詳情
• 登入
• 收藏

看到這裡就開始有點不妙。
地圖跟列表真的需要拆成兩頁嗎？
首頁如果只是放 Logo、品牌介紹，再丟一顆「開始探索」按鈕，那它到底幫了什麼？

Filter 又真的有資格自己長成一個完整頁面嗎？

📸 圖片 1｜第一版 Sitemap 草稿

我先自己砍一輪

這次我沒有先問 Gemini。
先拿昨天的 User Flow 自己對一次。
首頁如果只是品牌介紹＋「開始找咖啡廳」，那使用者其實只是多按一次才開始找店，所以先拿掉。
地圖跟列表本來就是同一批店，只是兩種看法，也沒必要硬拆。
Filter 更像探索過程裡的一個操作，不是另一段旅程。
所以第一輪先收成：

探索頁
├─ 地點搜尋
├─ 地圖／列表切換
├─ Filter
└─ Cafe Card

店家詳情

登入／收藏

光這樣，頁面就少很多。

📸 圖片 2｜第一次手動合併後的 Sitemap

再丟給 Gemini，看我是不是還留太多

自己砍完之後，我才把 User Flow 跟目前 Sitemap 丟給 Gemini。
這次 Prompt 也刻意限制它，不要又順手幫我發明新功能：

以下是我的主要 User Flow：

定位／搜尋地點 →
查看附近店家與工作資訊 →
套用篩選條件 →
比較店家 →
需要時查看店家詳情 →
Google Maps 導航

目前暫定頁面：
- 探索頁
- 店家詳情
- 登入
- 收藏

請幫我檢查資訊架構。

要求：
- 頁面越少越好
- 不要因為有一個功能就新增一頁
- 優先考慮手機操作
- 指出哪些頁面可以合併
- 每個留下的頁面都要說明「為什麼一定需要存在」
- 不要新增目前需求以外的功能

📸 圖片 3｜Gemini IA Review Prompt

Gemini 這次砍得比我還狠。
它看完之後，直接認為第一版可以只剩下：

1 個主畫面＋1 個次要視圖。

📸 圖片 4｜Gemini IA Review 的精簡結論

收藏跟登入，先退出核心流程

Gemini 第一刀先砍收藏。
這個其實跟前幾天的方向滿一致。
一個人在外面急著找工作地點時，第一件事不是整理收藏，而是先找到一間現在能坐的店。
登入也是一樣。
找店、套 Filter、看工作資訊、看詳情，這些事情都不需要先知道使用者是誰。
如果為了這些功能硬塞一個登入頁，只是多一道門檻。
所以這兩個我同意先從核心 Sitemap 拿掉。
重點不是「登入跟收藏永遠不做」，而是：

它們現在沒有理由擋在找店流程中間。

「比較店家」也不用自己長一頁

Gemini 另一個建議，是把比較直接留在探索頁裡完成。
這點也很合理。
如果 Cafe Card 已經直接顯示：

• 插座
• Wi-Fi
• 限時／久坐

那使用者在滑列表、看地圖時，本來就在比較。
根本不用再做一套「加入比較 → 打開比較頁 → 看比較表」。
那種東西做著做著，很容易從找咖啡廳變成在買筆電。

📸 圖片 5｜探索、比較合併的 Gemini 建議

店家詳情不用消失，但也不一定要換頁

這次比較有意思的是店家詳情。
Day 08 才剛確認過，詳情不能直接砍，因為很多店家規則不是一個 Tag 就講得完。
Gemini 這次沒有叫我把內容拿掉，而是換一個呈現方式：

內容保留，但不要另外切頁。

它建議在探索頁點店家後，直接從下面拉出 Bottom Sheet，把完整工作資訊、低消規則跟 Google Maps 導航放在裡面。
這個做法我滿喜歡。
因為使用者看完覺得不適合，只要把 Bottom Sheet 關掉，就回到剛才的地圖跟列表位置。
不用進詳情、按上一頁，再重新找剛才看到哪間店。
這比直接把詳情砍掉合理很多。
真正重要的是資訊還在。至於它是不是一個獨立 URL，現在反而不是最重要的事。

📸 圖片 6｜Gemini 建議用 Bottom Sheet 取代獨立詳情頁

不過 Gemini 的回答裡，又把「現場輕量回報按鈕」塞回來了。
這個前面已經砍過，所以我不會因為它又出現在 Sitemap 裡就撿回來。
這也剛好提醒我一件事：

叫 Gemini 幫忙 Review，不代表它記得前面所有產品決定。

最後的 Sitemap，真的只剩一個主畫面

整理完之後，目前留下來的資訊架構變成：

探索頁
├─ 定位／地點搜尋
├─ 工作條件 Filter
├─ 地圖／列表切換
├─ Cafe Card
│  ├─ 插座
│  ├─ Wi-Fi
│  └─ 限時／久坐
│
└─ 點擊 Cafe Card
   └─ Bottom Sheet：店家詳情
      ├─ 完整工作資訊
      ├─ 低消／特殊規則
      └─ Google Maps 導航

沒有獨立首頁。
沒有獨立地圖頁。
沒有獨立列表頁。
Filter 不是一頁。
比較也不是一頁。
登入跟收藏先不放進核心 Sitemap。
最後真正要設計的，反而只剩一個探索主畫面，以及它上面的不同狀態。

📸 圖片 7｜最終 Sitemap

頁面少，不代表把所有東西硬塞在一起

做到這裡，我覺得有一個地方滿容易搞混。
把頁面從一開始的八個砍到一個，不是因為 Single Page 聽起來比較帥。
如果最後所有東西都擠在同一個畫面，操作反而更亂，那也沒有比較好。
這次會收成這樣，是因為搜尋、Filter、地圖、列表、比較，本來就在做同一件事：

幫使用者從附近的店裡，挑出現在適合工作的那一間。

既然任務沒換，就沒必要一直換頁。
店家完整規則則是下一層資訊，但也不需要把使用者整個帶離探索情境，所以放進 Bottom Sheet 剛好。
今天最後沒有得到一張很壯觀的 Sitemap。
反而得到一張小到有點寒酸的 Sitemap。
但這次我覺得，小是好事。
因為網站的骨架，已經從「我覺得網站應該有哪些頁」，慢慢變成「使用者真的需要哪些畫面」。
接下來就可以拿這個骨架去做畫面，看看只剩一個主畫面之後，怎麼把搜尋、Filter、地圖、列表跟店家資訊排得清楚。