昨天把 PRD 收好之後，功能跟資料大致有了範圍。
但寫在文件裡的「搜尋 → 篩選 → 看店家 → 導航」看起來很順，真的放到手機上，不一定還這麼順。
所以今天先不碰漂亮 UI。
我想先確認一件更基本的事：

一個人在外面臨時想找地方工作，從打開網站到真的選好店，中間到底要做多少事？

如果這條路本身就很繞，後面畫面再漂亮也只是把迷宮裝潢得比較好看。

先從真的會發生的情境開始

我先給自己一個很具體的場景。
人在台北車站附近，等等要處理工作，想找一間有插座、可以坐一段時間，而且不要太吵的咖啡廳。
這時候我真正會做的事情其實沒有很多：

1. 打開網站
2. 用目前位置，或輸入「台北車站」
3. 選「有插座」「適合久坐」這類工作條件
4. 看附近有哪些店
5. 挑一間，確認工作資訊跟營業狀態
6. 開 Google Maps 導航

先這樣就夠了。
中間如果還要註冊會員、選興趣、回答「今天想喝什麼咖啡」，甚至先跟 AI 聊五輪，我大概已經直接開 Google Maps 了。

📸 圖片 1｜第一版文字流程

這張我故意保留得很粗。
因為現在不是在做作品集，我只是想知道：使用者到底會經過哪些步驟。

第一版先不要急著砍

接著把上面的文字真的畫成 User Flow。
第一版我沒有追求最短，而是把可能會出現的節點先全部攤開：

• 開啟網站
• 允許定位／輸入地點
• 顯示附近咖啡廳
• 開啟 Filter
• 選工作條件
• 回到列表／地圖
• 點選店家
• 看店家詳情
• 開 Google Maps 導航

一畫成方框，原本藏在一句話裡的小動作就跑出來了。
例如「選工作條件」聽起來只有一步，但如果實際操作變成：

開 Filter
→ 選條件
→ 按套用
→ 關掉 Filter
→ 回列表

那手機上其實已經繞了一圈。

📸 圖片 2｜第一版 User Flow 圖

這張的重點不是漂亮，而是保留第一版。後面改了什麼，才有東西可以比。

畫完第一版，再丟給 Gemini 挑毛病

流程畫完後，我才拿去給 Gemini Review。
這次我不想讓它重新幫我發明產品，所以 Prompt 寫得很明確：

請幫我檢查這條使用流程：

打開網站 → 定位／搜尋地點 → 選工作條件 →
看地圖與列表 → 看店家詳情 → 導航

使用者情境：
人在陌生地區，想快速找到一間可以工作的咖啡廳。

請只檢查目前流程，找出：
- 不必要的步驟
- 可能卡住的地方
- 哪些資訊應該提早顯示
- 手機上最容易操作失敗的地方

不要新增功能。
不要新增頁面。
先想辦法把流程變短。

最後三句最近越寫越順手。
因為 AI 很容易看到一條流程，就順便幫你加 onboarding、推薦頁、會員偏好設定。
今天完全不需要。

📸 圖片 3｜丟給 Gemini 的 UX Review Prompt

這次 Gemini 沒有亂長功能，反而抓到幾個我自己看久了會忽略的地方。

第一個問題：工作資訊藏太深

它先指出，插座、限時跟 Wi-Fi 這些東西，不應該等到店家詳情頁才出現。
這點我同意。
如果列表上只有店名、距離跟評分，每一間都要點進去才知道能不能工作，那我只是把 Google Maps 的「翻評論」，換成另一種「一直點詳情」。
所以至少這幾個資訊：

• ⚡ 插座
• ⏳ 限時／久坐
• 📶 Wi-Fi

應該直接放在 Cafe Card 上。
使用者先在列表裡比較，真的想看更多，再進詳情。

📸 圖片 4-1｜Gemini 建議把核心工作資訊提前

第二個問題：條件一多，很容易直接零結果

Gemini 也提醒了一個我原本沒特別想到的地方：Filter 很容易把結果篩到歸零。
假設一次勾了：

有插座 + 不限時 + Wi-Fi 穩定 + 安靜

結果附近一間都沒有。
如果畫面只回一句「找不到符合條件的咖啡廳」，其實很像在跟使用者說：你自己想辦法。
至少要讓人知道現在套了哪些條件，而且可以很快拿掉其中一個再找。
所以這條分支我直接留進流程裡：沒結果時，可以回頭調整條件，而不是卡死。

📸 圖片 4-2｜Gemini 提到 Filter 歸零的卡點

但「店家詳情」我沒有照它的建議砍掉

Gemini 最後很積極地把原本 6 個步驟壓成 4 個：

打開網站
→ 自動定位＋套用條件
→ 看列表／地圖＋工作資訊
→ 直接導航

看起來很俐落。
它甚至認為，既然核心資訊都提前到列表了，那「店家詳情」可以直接消失。
這裡我沒有照做。

詳情頁可以不是必經步驟，但不能沒有。

前面整理資料欄位時就碰過很多這種情況：

平日不限時
假日客滿時限 2 小時

或者：

有插座
但只有靠牆座位有

這些規則全部塞進 Cafe Card，手機畫面很快就會爆掉。
所以我最後留下的是兩條路：

列表／地圖
├─ 資訊夠了 → 直接導航
└─ 想確認更多 → 店家詳情 → 導航

店家詳情還在，只是不再強迫每個人都進去。

📸 圖片 4-3｜Gemini 的 4 步流程與我的修正版

「自動定位」也沒有想像中這麼單純

Gemini 還建議網站一打開就直接抓 GPS，馬上顯示附近店家。
方向沒問題，但瀏覽器不是我想拿位置就一定拿得到。
使用者可能拒絕定位，也可能還沒授權。
所以我把這裡改成：

打開網站
↓
請求目前位置
├─ 成功 → 顯示附近店家
└─ 失敗／拒絕 → 輸入地點搜尋

定位是快的那條路，搜尋地點則是備援。
這樣比較符合真的會遇到的狀況。

第二版，不是單純把步驟砍少

Review 完之後，我再畫第二版。
這次真正改掉的東西其實很具體：

• 找店前不要求登入
• 定位成功就直接找附近；失敗還能搜尋地點
• Filter 不做成一個很長的獨立流程
• 插座、Wi-Fi、久坐資訊提早放到 Cafe Card
• 詳情頁改成 Optional，不強迫每間都點
• 導航直接交給 Google Maps

主流程最後比較像：

打開網站
↓
定位／搜尋地點
↓
看到附近店家＋核心工作資訊
↓
快速套用 Filter
↓
├─ 資訊夠了 → Google Maps 導航
└─ 想確認更多 → 店家詳情 → Google Maps 導航

這一版我自己看起來舒服很多。
不是因為節點變少而已，而是每一步都比較像真的有必要。

User Flow 不是越短越好，而是每一步都要有理由。

Gemini 可以幫我抓摩擦點，但最後要不要砍，還是得看前面已經確認過的需求。

📸 圖片 5｜精簡後的 User Flow

如果把圖片 2 跟圖片 5 放在一起看，差異就很明顯。
第一版是在把所有可能的步驟攤開；第二版則是把必要資訊往前搬，把不一定要走的路改成分支。

Day 08 最後留下來的是一條路

今天沒有做新功能，也沒有畫正式 UI。
但至少產品最重要的那條路已經比較清楚了：

找到地點 → 套工作條件 → 比較店家 → 確認 → 導航。

其他東西都可以晚點再加，但不能卡在這條路中間。
而且 User Flow 寫成文字時，很多問題真的看不出來。
一畫成方框跟箭頭，多按一次、多跳一頁，馬上就很刺眼。
接下來要處理的問題也很自然：

既然這條路差不多定了，網站到底需要哪些頁面，才能把它撐起來？