PRODUCT DESIGN · IN PROGRESS
路記 Luji
讓旅行規劃從一個人的工作，變成旅伴之間的共同決定。收藏想去的地方、表達彼此偏好，再把共同決定轉成可持續調整的行程。
01 · OVERVIEW
專案概述
路記是一款為 2–4 位旅伴設計的私密旅行規劃工具。我從 2026 年 8 月開始獨立推進這個自發專案，負責問題定義、產品架構、互動設計、介面系統，以及可操作的行動版功能切片。
- 角色
- 獨立 UI/UX 與產品設計師
- 時間
- 2026.08–現在
- 平台
- 行動裝置 · iOS／Android／網頁展示版
- 範圍
- 產品定義 · 使用者體驗架構 · 互動設計 · 介面系統 · 可操作原型
- 協作方式
- 我主導問題定義與最終取捨；AI 協助方案發散、反方提問與文件整理
專案仍在開發與驗證中；本案例聚焦已完成的產品判斷、設計收斂與實作，不把尚未發生的市場成效寫成成果——目前累計 48 項決策；5 條核心流程已完成規劃，其中 4 條功能切片已實作並通過技術驗證，真人可用性測試尚待進行。
02 · PROBLEM & EVIDENCE
問題不是沒有人想旅行，而是只有一個人在排行程
多人自由行常由一位主揪蒐集地點、追問意見，再把散落在社群平台、群組對話、地圖收藏與行程表裡的資訊拼回來；其他旅伴不一定沒有想法，卻往往只在回應成本足夠低時參與。如何讓每位旅伴低負擔表達真實偏好，並一起走向可執行的安排，而不讓協作本身變成更多工作？
問題 01
規劃責任集中在主揪身上
大家一起旅行，但投入成本與決策責任並不對等。
主揪持續整理
資訊與決策都需要有人接住
- 蒐集散落的地點
- 反覆追問意見
- 解讀「都可以」
- 整理最後安排
旅伴被動回應
有想法，但回應成本必須夠低
- 願意一起旅行
- 不想多學一套工具
- 避免公開反對
- 通常只回應眼前問題
問題 02
資訊又散落在不同工具裡
主揪不只要做決定，還要在工具之間搬運資訊、補回脈絡。
社群平台
找靈感
群組對話
討論
地圖收藏
存地點
行程表
排行程
重複輸入 · 討論容易沉底 · 收藏原因遺失 · 最後仍由主揪整合
問題框架來自初步人物誌（proto-persona）、旅行情境推演與競品分析，還沒有訪談過真實旅伴，現階段仍是待驗證假設。
03 · USERS
使用者輪廓
從產品功能重心（收藏地點、偏好表態、團體訊號與行程安排）可以反推：目標使用者是 2–4 人一起旅行的旅伴，其中一人常態性地花更多心力蒐集資訊與整理行程，其他人有真實想法，卻不一定會主動整理或表達。他們需要一個比社群平台、群組對話與地圖收藏更低負擔的參與方式，也需要一個能保留脈絡、之後還能回頭調整的空間。
這些輪廓來自初步人物誌與情境推演，還沒有訪談過真實旅伴，是待驗證的假設，不是實際研究結果。
04 · INFORMATION ARCHITECTURE
同一個地點，如何穿過產品架構
一趟旅行（Trip）定義共同規劃的邊界；「想去的地方」（Places）保存候選地點與決策脈絡；當地點被排入某一天，「行程」（Plan）只新增一筆安排，而不改寫原始地點。
支援物件依附在同一個地點上，隨時可查詢：偏好（我怎麼想）、團體訊號（共識與差異）、規劃狀態（待安排／已排入）。地點保留來源與脈絡；移除行程安排，原本收藏的地點仍會保留。
05 · PRIMARY FLOW
一個地點如何穿過循環式規劃
- 01在「想去的地方」（Places）收藏一個「可能想去」的地點，保留來源與討論脈絡。
- 02尚未表態的地點維持中性，不會被催促，也不會被推定為不想去。
- 03用四值＋空白表達想法——「尚未表態」代表沒有輸入，不是第五種答案。
- 04地點卡片顯示精簡的團體訊號：高度共識或明顯差異，分歧是資訊不是警告。
- 05選擇日期後，系統在「行程」（Plan）建立一筆安排，只記錄日期、順序與選填時間。
- 06從行程移除這筆安排，不會刪除原本收藏的地點——旅伴仍能保留想法，之後再重新安排。
FUNCTIONAL SLICES
功能切片實作進度
5 條核心流程已完成規劃，4 條功能切片已實作，另完成切片五的既有主線驗收與操作展示。以下 5 支影片說明目前可操作的流程；真人可用性測試尚待進行。
- Flow A收藏、表態與加入行程已實作・切片一
- Flow B從行程探索可安排的地點既有主線已驗收・切片五
- Flow C外部收藏完整匯入待實作
- Flow D行程編輯與時間衝突已實作・切片二
- Flow E協作更新與重新進入已實作・切片四（單機模擬）
切片數不等於完整核心流程數：切片三補上示範搜尋與收藏，不代表 Flow C 外部分享匯入完成；切片四展示 Flow E 的單機模擬，不代表真實多人同步；切片五驗收既有主線，未新增「已略過」狀態，完整 Flow B 仍待完成。
切片一涵蓋 Flow A，並包含部分基礎行程調整
從偏好到行程
新增地點、表達想法、看見旅伴摘要，再選擇日期與選填時間加入行程；後續可以調整安排，同時保留原始收藏脈絡。
核心價值收藏不等於排程，偏好不等於承諾。「想去的地方」保存靈感與共同脈絡，「行程」承載真正的日期與時間安排。
查看 8 個核心操作
- 從旅行首頁進入「想去的地方」，並可返回首頁。
- 新增地點，包含名稱、來源連結、補充文字與選填照片。
- 編輯或刪除地點。
- 表達「想去／都可以／不想去」，查看自己與旅伴的想法摘要。
- 選擇旅行日期，並以選填方式設定時間後加入行程。
- 從「想去的地方」或「行程」查看安排結果。
- 調整日期與時間、移除時間、移至其他天，或只從行程移除。
- 重新整理或重新進入後，變更仍會保留。
切片二主要完成 Flow D
彈性排序與時間承諾
拖曳調整同日順序；無時間項目保持彈性，明確時間維持先後約束，衝突操作不寫入並提供就地修改入口。
核心價值順序表達相對安排，時間表達明確承諾。系統守住時間矛盾，但不替使用者自動重新排程或改寫決定。
查看 8 個核心操作
- 在「行程」選擇日期，查看當日所有行程。
- 拖曳整張行程卡調整同日順序。
- 無時間項目可移到任意位置，並維持未設定時間。
- 有時間項目可跨越無時間項目，但不能違反彼此的時間先後。
- 合法排序立即保存，重新整理後仍保留。
- 發生時間衝突時，卡片回到原位置且不寫入錯誤順序。
- 畫面顯示非阻擋式提示，並提供「修改時間」入口。
- 修改或移除時間、移至其他天、移除行程後，各日期的排序會重新整理。
切片三示範地點搜尋與收藏
搜尋地點，保留收藏脈絡
輸入京都、選取清水寺，帶入示範地點資料並補上筆記；收藏後重新載入，內容仍保留。
核心價值搜尋協助建立收藏，但不代替偏好表態或行程安排。本段使用示範資料，不代表真實地點 API。
查看 4 個核心操作
- 輸入「京都」，從示範候選選取「清水寺」。
- 查看自動帶入的名稱與示範區域，補上收藏筆記。
- 儲存收藏，重新載入後確認資料保留。
- 從收藏進入表態入口，後續再決定是否安排。
切片四單機模擬協作變更提示
看見變更，不被打斷
旅伴變更以非阻擋式提示呈現；編輯中的草稿保持不變，由使用者決定何時查看更新。
核心價值讓變更可察覺，同時保留當下操作的主導權。這是隔離的單機模擬，不代表真實多人或跨裝置同步。
查看 4 個核心操作
- 模擬旅伴調整時間，從首頁進入對應日期查看。
- 編輯未儲存的 11:00 草稿，另一筆變更不關閉面板。
- 查看更新前提醒未儲存編輯將結束，由自己決定是否查看。
- 同次瀏覽離開再返回，保留最新安排且不重播已看提示。
切片五示範 Flow B 既有探索與單筆安排主線
從共識到安排
從行程探索可安排的地點，查看旅伴想法，選擇第 3 天並保留時間空白；移除安排後，地點仍可再次探索。
核心價值團體訊號提供參考，安排由自己決定。日期必填、時間選填；移除安排仍保留收藏與偏好。本段不含「已略過」狀態，也不代表完整 Flow B 或真人測試。
查看 5 個核心操作
- 從行程進入「可以安排的地方」，查看 3 人想去、1 人都可以的摘要。
- 未選日期時無法新增；選擇第 3 天，時間保持空白。
- 加入後回到指定日期，確認安排結果。
- 回到收藏，原有來源與偏好仍保留。
- 只移除行程安排，地點重新出現在可安排列表。
想親自操作完整流程，可前往 Luji 網頁展示版 ↗
06 · KEY DECISIONS
三個最有代表性的決策
聚焦共同決策，而不是功能廣度——「想去的地方」回答「我們可能想去哪？」；「行程」回答「我們要怎麼安排？」，兩者形成可反覆進入的循環式規劃。
先收藏，再決定
把「保留想法」與「承諾安排」拆開：收藏只代表可能想去，選擇日期後才建立一筆行程安排。
偏好用四值＋空白，不是投票
非常想去／想去／都可以／不太想去，加上可以不表態；分歧是資訊，不是警告，也不會阻止加入行程。
日期必填、時間選填
一筆行程只要有日期與當日順序就能成立；調整順序時，系統不會擅自修改已設定的時間。
決策一：一個地點，兩種不同責任
收藏是一個低承諾行為；若同時要求偏好、日期與時間，就會把保留靈感變成高負擔決策，也混淆「可能想去」與「已經安排」。「想去的地方」中的地點代表「我們可能想去這裡」，保存來源、偏好與討論脈絡；旅伴選擇日期後，系統才在「行程」中建立一筆安排，只負責日期、順序與選填時間。
決策 01
收藏當下，需要做多少決定？
先比較三種做法，再看採用後如何分開保存收藏與行程。
收藏時全部決定
收藏 → 想法 → 日期 → 時間
步驟過重，容易在收藏前退出。
收藏即排行程
收藏 → 直接加入行程
混淆「可能想去」與「已經安排」。
先收藏，再決定
收藏 → 需要時再安排
先保留靈感，再逐步提高承諾。
採用後如何運作
收藏與行程，保留不同責任
兩者彼此相關，但不共享同一個生命週期。
收藏的地點
我們可能想去這裡
- 地點資訊與來源
- 旅伴的個人偏好
- 團體意向
- 待安排／已排入
行程安排
已排入某一天
- 日期
- 當日順序
- 時間（選填）
- 移除安排後，地點仍會保留
決策二：由個人表達，形成團體理解
想去／不想去、分數與排名看似有效率，卻容易把禮貌性同意、沉默與真實偏好壓成勝負。地點卡片先顯示自己的想法，再以精簡的團體訊號呈現高度共識或明顯差異；標籤語意是否被一致理解，仍需真實旅伴驗證。
決策 02
如何表達想法，又不把旅行變成投票？
先比較不同輸入方式，再看個人想法如何形成團體訊號。
二元選擇
想去／不想去
快速，但過度壓縮態度。
分數或排名
1–5 分／選出前三名
容易暗示勝負與裁決。
三段式
想去／普通／不想去
缺少「非常想去」的層級。
四種想法＋未表態
非常想去／想去／都可以／不太想去
尚未表態保持為沒有輸入。
採用後如何運作
個人表態，形成團體理解
團體訊號協助理解差異，但不替旅伴做決定。
高度共識
3 人想去 · 1 人都可以
下一步：可以優先加入行程
明顯差異
2 人想去 · 2 人不太想去
下一步：先查看彼此想法，仍可加入行程
未表態代表沒有輸入 · 未完成不催促 · 想去不等於已同意排入行程
決策三：日期必填，時間選填，順序獨立
加入行程時，日期回答「哪一天去」所以必填；時間只在有預約或明確時刻時設定，沒有時間仍是一筆完整安排。加入後可以明確設定、修改或移除時間；同一天的排列順序則獨立管理，不會因移動項目而自動改寫時間。
決策 03
日期、時間與順序，各自負責一件事
三者可以一起呈現，但不會互相推定或偷偷改寫。
日期
這一天要去哪裡
- 加入行程時必填
- 決定項目屬於旅行第幾天
時間
是否有明確時刻
- 選填；沒有時間仍是有效安排
- 設定、修改與移除都由旅伴確認
順序
同一天的先後位置
- 可獨立調整
- 不會因移動而自動改寫時間
日期／時間與同日排序已實作 · 時間矛盾的排序會被拒絕並提示修改
07 · ALTERNATIVES CONSIDERED
其他設計取捨
第 06 章已完整說明三個核心決策；這裡只保留其他曾影響產品架構的選擇，呈現我如何控制流程壓力、狀態數量與協作成本。
步驟式流程＋完成百分比→︎循環式規劃
旅行規劃沒有單一完成終點。
加入「考慮中」狀態→︎待安排／已排入／已略過
個人偏好與可安排程度會互相重疊。
審核流程＋永久活動紀錄→︎共同編輯＋短暫狀態提示
避免把共同編輯變成流程管控。
08 · DESIGN SYSTEM
讓視覺語言承接產品價值
溫暖極簡：以紙張感背景、低彩度陶土紅、鼠尾草綠與充足留白，讓共同規劃更接近安靜的旅行筆記，而不是高壓的工作管理工具。視覺系統不把分歧畫成錯誤，也不讓顏色單獨承擔狀態。
Noto Serif TC（思源宋體繁中）用於標題，Inter 用於資訊、按鈕與操作文字；間距尺度為 4 · 8 · 12 · 16 · 24 · 32 px。
09 · TESTING & VALIDATION
實作驗證與待驗證
目前完成的是設計規則與程式行為的技術驗證，不等同於可用性測試。下列標示區分已通過內部技術與產品規則驗證的項目，以及仍需真實旅伴回答的「待可用性測試」。
「先收藏，再決定」規則：收藏地點與行程安排彼此獨立，已寫入程式並通過單元測試。 — 實作驗證完成
日期必填、時間選填，以及修改日期、設定或移除時間的操作，已寫入可操作原型並通過單元測試。 — 實作驗證完成
切片二：違反時間先後的矛盾排序會被拒絕、卡片回到原位；合法排序、修改時間與跨日移動能正確保存。 — 實作驗證完成
切片三：京都示範資料的搜尋、選取、收藏與重載已完成；不呼叫付費地點 API，也不代表完整外部分享匯入。 — 示範搜尋完成
切片四：隔離的單機協作示範已完成，涵蓋變更提示、編輯／拖曳保護、相關日期已看狀態與失效操作拒絕；一般收藏與行程不受示範影響。 — 單機示範完成
四條切片已通過自動測試（含日期、偏好、收藏、排序、時間衝突及單機協作規則）、TypeScript 型別檢查與 Web 建置部署，並以瀏覽器實際操作主要流程，確認資料能正確儲存與重新載入。 — 技術驗證完成
尚未進行正式的真人可用性測試，也還沒證明使用者能在沒有提示的情況下完成流程，或真人能正確理解「個人偏好／團體訊號」的語意。 — 待可用性測試
切片五：Flow B 既有探索與單筆安排主線已於本機驗收，包含日期必填、時間選填、重新載入保留與移除安排後重新推薦；不含尚未實作的「已略過」狀態，完整 Flow B 仍待完成。 — 既有主線驗收完成
帳號、後端、真實多人與跨裝置同步尚未實作，不能以單機協作示範替代可靠性驗證。 — 待實作與測試
10 · RESULTS & LIMITATIONS
完成設計，不等於完成驗證
目前 Luji 已完成核心產品定義、五組核心操作流程、代表性高擬真介面、設計系統，以及 4 條可操作功能切片。這證明設計能轉化為產品，但尚不能證明它已降低真實旅伴的協調成本。
已定義
- 循環式規劃流程
- 主要操作流程與產品規則
- 第一版產品範圍
已完成設計
- 五組核心操作流程
- 高擬真介面
- 共用介面元件
已完成實作
- 4 條功能切片＋切片五既有主線驗收展示
- 裝置內資料儲存
- iOS／Android／網頁展示版
尚未驗證
- 使用者證據
- 真實協作成效
- 市場成效
定義邊界，比增加功能更直接影響體驗 — 四組語意界線，從產品原則一路影響資料關係、互動規則與視覺狀態。
- 已證明：設計規則可以轉成可操作流程，而不只停在靜態畫面；收藏與行程分離、日期必填而時間選填等規則，也實際寫入程式並通過單元測試；同日排序遇到時間矛盾時，系統會拒絕寫入並提供修改入口。
- 尚未證明／驗證：真人可用性測試、使用者證據、後端、登入、真實多人同步與市場成效都還沒有。Flow B 既有主線已驗收，「已略過」狀態與完整流程仍待完成；Flow C 完整外部匯入與 Flow E 真實多人版本仍待實作。
- 下一步：以旅伴測試驗證「個人偏好／團體訊號」、「想去的地方／行程」與「日期／時間」的語意理解，再依共同誤解修正核心流程；後端、登入與真實多人同步仍不列為目前成果。
真正困難的不是增加功能，而是決定哪些狀態值得存在，以及哪些決定應該留給旅伴自己完成。