REEF
打造個人管理工具，
安放大小事、鼓勵行動、看見成長軌跡
為了提升時間與任務管理的能力，我嘗試過不同的工具記錄日常事務。依紀錄的類型，過去的使用方式如下。
主要記錄固定時間的行程，但無法滿足任務、記事與反思的紀錄需求。
先後嘗試多種工具。紙本的修改與攜帶不便；數位工具缺乏整合行事曆的功能，重複輸入與跨平台查看降低效率。
與行程、任務分屬不同平台。回顧時需自行對照多個來源，或透過重複輸入自行同步，難以追蹤行動與想法之間的關聯。
礙於各項工具功能上的限制，不同情境的紀錄分散於不同平台，歸納為以下三個問題。
同一件事需在不同工具各記一次。
事項未集中管理，沒有固定入口。
回顧或復盤時，資訊無法彙整。
為了確認市場上是否已有符合需求的工具，我分析了任務管理、習慣養成與情感紀錄三類共五款 App，並從兩個面向進行比較：可使用的平台，以及整合了哪些類型的紀錄。
是否同時提供電腦版與手機版（Reef 的手機版採 PWA）。規劃與回顧適合在電腦上進行，隨手記錄與查看則發生在手機上，兩者缺一會造成紀錄中斷。
涵蓋行事曆、待辦清單、排程任務、習慣追蹤、情感與日記紀錄、回顧等六種類型中的哪幾種。
| App | 使用平台 | 整合的紀錄類型 | ||||||
|---|---|---|---|---|---|---|---|---|
| 電腦 | 手機 | 行事曆 | 待辦清單 | 排程任務 | 習慣追蹤 | 情感／日記 | 回顧 | |
| Tiimo視覺化日程規劃 | ● | ● | ● | ● | ● | – | △ | △ |
| Routinery例行流程的引導執行 | – | ● | – | – | △ | ● | – | △ |
| stoic.日記與心情反思 | ● | ● | – | – | – | △ | ● | ● |
| Sagely低壓力的待辦清單 | ● | ● | – | ● | △ | – | – | – |
| Bearable心情與健康狀況追蹤 | – | ● | – | – | – | ● | ● | ● |
| Reef本專案的目標 | ● | ● | ● | ● | ● | ● | ○ | ○ |
● 完整支援 △ 部分支援 – 不支援 ○ 規劃中 比較表內容待核對
任務管理、習慣養成與情感紀錄各有專精的工具，但沒有單一工具涵蓋全部類型，使用者需同時維護多個 App。
提供回顧的工具多以情感紀錄為主，不含任務；以任務為主的工具則缺乏反思與長期回顧。
Tiimo 同時涵蓋行事曆、待辦清單與排程任務，且提供電腦與手機版，是最接近需求的工具，因此進一步檢視其使用經驗。
實際改用 Tiimo 後，部分問題獲得改善，但持續使用後仍有三項個人化的需求未被滿足。
Tiimo 可匯入 Google 行事曆，行程與任務不需再分開查看或重複謄寫。
以時段分組呈現一天的安排，新增與調整任務的操作成本低，也解決了紙本的修改痕跡與攜帶問題。
圖片來源：Tiimo 官方產品圖
當日未完成的任務只能單筆手動改期，操作瑣碎；若未改期，任務會停留在過去的日期而被遺漏。
日記需記錄在其他平台。進行系統性的回顧或復盤時，跨平台的資訊難以整合。
回顧僅顯示當日完成的任務，且只在特定時間出現，無法隨時查看。長期任務與目標的行動過程難以追溯。
除了功能涵蓋範圍，另針對介面與機制進行兩項分析，作為後續設計的依據。
第一階段分析首頁畫面：視覺層級、主要 CTA 與資訊密度。第二階段分析機制：各工具如何處理未完成的事項。
分析競品的紅色用途，發現同一種紅色經常同時代表刪除、付費推銷與「尚未完成」，容易將未完成的事項與錯誤狀態混淆。
針對上述未被滿足的需求，我設計並開發了 Reef：一款個人管理工具，整合任務、行程、提醒與習慣追蹤，資料儲存於使用者自己的 Notion。電腦版為網頁應用程式；手機版製作成 PWA（Progressive Web App，漸進式網頁應用程式），可加入手機主畫面，以接近原生 App 的方式開啟，並支援離線使用。
Reef 的定位，是透過規律而簡單的紀錄支援後續的回顧與復盤，包含習慣的維持狀況、時間的實際分配，以及各類任務所需的時間。最終目標是協助使用者了解自己的行動與成長軌跡，降低完美主義造成的行動阻力，提升實踐能力。
任務、行程、日記反思與目標集中於單一工具，避免重複輸入。
目標、有截止日的長期任務、想養成的習慣，以及提醒與日常瑣事，皆有對應的位置。
縮短從記錄到執行的操作距離；計畫變動時，由工具承接未完成的項目。
保留完整的行動紀錄，支援後續的回顧。
Reef 目前為單一使用者的個人工具，因此不以轉換率或營收衡量成效，而以「是否持續被使用」作為主要指標。同時，為避免工具加重完美主義帶來的壓力，全站不呈現逾期、達成率或連續天數等評價性資訊。
設計目標之間存在張力：工具需要呈現進度，卻不能評價使用者；需要容納多種事項，卻不能增加記錄負擔。以下為四項主要的設計挑戰。
提醒、待辦與排程任務以版面配置加以區分；但為了鼓勵行動，待辦與提醒需能透過拖曳或簡單的編輯轉為任務，不必重新輸入。
時間與完成狀況是回顧的必要資訊，但逾期、達成率等常見呈現方式會將工具變成考核機制。
紙本的修改會留下雜亂的痕跡，數位工具則容易讓未完成的事項停留在過去而被遺漏。
分類、目標、時長等欄位有助於後續回顧，但填寫要求會提高記錄成本，使紀錄難以持續。
開發採分階段進行。第一階段先建立設計系統與資料模型，並盡早上線；後續功能的順序依實際使用中遇到的問題決定。色彩與間距的細部調整刻意延後至功能與版面確定之後，由於色彩自第一階段即以設計 token 管理，延後調整不需修改元件。
競品研究與定位、設計系統（色彩語意與設計 token）、資料模型、登入機制、手機版的 PWA 外殼（可加入主畫面、支援離線）。
桌機與手機的日檢視、離線可用的資料同步、任務建立與編輯、子任務、提醒與習慣分頁、多日檢視、桌機側邊欄與分頁架構。
Google 行事曆同步、起訖時間與跨日任務、重複規則、任務卡的進度描述。
提醒的編輯與重複、女性生理週期提醒、自訂圖示與圖示選擇器。
視覺整體調整、「完成為止」、任務提醒、拖曳排序、展示模式。
回顧頁、每日反思、提醒與待辦的拖曳排程。
本專案的程式由 Claude Code（AI 程式開發工具）撰寫。設計決策、方案取捨與驗收由我負責；AI 提出方案與風險評估，由我選擇並記錄理由。
設計原則與限制寫入專案規則檔，AI 於每次工作開始時讀取，例如「提醒不得出現勾選圈」。
色彩僅能取自設計 token，並移除框架預設的色盤；使用未定義的顏色時不會產生任何樣式。
決策紀錄包含理由與被否決的選項，本 case study 即整理自該份紀錄。
參考 Tiimo 時，量測實際網頁的數值而非依截圖推估；涉及原生控制項與觸控的問題，一律以實機驗證。
右側為 Reef 的展示版，可直接點擊操作。展示版使用虛構的資料，所有操作僅存在於此瀏覽器，重新整理後即還原，不會連接任何後台。
建議嘗試的操作
Google 行事曆的行程會自動同步至 Reef 並轉為任務，可勾選完成、新增子任務與撰寫說明。
同步方向採單向（Google 至 Reef）。評估雙向同步後決定不採用，原因是發生錯誤時，單向同步的影響僅限於 Reef 內的資料，雙向同步則可能影響原始的行事曆。此外，使用者在 Reef 修改過的欄位，後續同步時不會被 Google 的資料覆蓋。
每日反思將整合於同一工具，回顧時不需跨平台彙整資料。 設計中
| 類型 | 定義 | 介面 |
|---|---|---|
| 排程任務 | 已安排於特定日期與時段的事項 | 具勾選圈 |
| 待辦 | 尚未安排日期的事項 | 具勾選圈，收納於待辦清單 |
| 習慣 | 想要長期記錄與追蹤的事項 | 可勾選，不累計連續天數 |
| 提醒 | 僅需知悉，或知悉後再視情況決定是否轉為任務的事項 | 不具勾選圈，不計入任何數量 |
提醒規則以「週期第幾天」表示，不提供倒數，也不預測下一次經期。
經期期間與經期後一週可由實際開始日向後計算，結果準確。「經期前一週」則需預測下次開始日，而依長期的實際紀錄，週期長度的變動幅度大，無法支撐可靠的倒數。因此此階段的提醒設定為「自第幾天起」，介面僅顯示目前為第幾天，不宣告所處階段。
任務可連結至目標，目標頁會呈現該目標下累積的行動。
回顧頁可隨時開啟，呈現特定期間內實際完成的事項與所花費的時間。 設計中
回顧的文案僅描述事實，例如「這次花了 52 分」「此類任務通常需要 50 分左右」，不使用超時或達成率。
為支援回顧，以下規則自第一版起即納入資料模型：
完成狀態依日期逐筆記錄，完成的任務保留於原位。
刪除任務僅影響尚未發生的日期，過去已完成的紀錄仍可查看。
日期變更歷史由 Reef 寫入並保存，因為此類資料若未在第一版保留，事後無法回補。
