Product Development
產品開發
共 14 篇相關文章。
Day 16｜以終為始：思考產品功能
以工作終點反推畫面、資料、操作與完成條件，說明如何用「以終為始」設計真正幫人完成工作的產品功能。
Day 15｜我開始能從工作流程看見產品應該如何被使用
從案件進度走向今日工作入口，整理產品如何幫使用者判斷現在該做什麼，同時保留需要由人完成的判斷。
Day 14｜我開始能從工作流程看見系統需要做什麼
從工作流程圖往下推導案件階段、狀態與系統需求，說明如何在實作前提早看見系統需要管理的事情。
Day 13｜聽他怎麼說，也看他怎麼做
說明面對陌生行政流程時，如何先訪談、再觀察實際操作，最後把零散步驟整理成可討論的工作流程圖。
Day 12｜原來我在做翻譯
從陌生行政委託案出發，整理如何把現場工作翻譯成工程可處理的問題，以及第一個產品留下的可轉移能力。
Day 11｜看到 n8n 時，我以為找到做預約系統的方法了
以 n8n 預約流程為例，說明當需求從自動化轉為狀態管理時，真正需要改變的是問題框架，而不只是工具設定。
Day 10｜我以為功能做完，產品就完成了
回顧功能都能運作卻仍撤回上線的預約產品，說明完成標準、日常可用性與功能清單之間的差異。
Day 9｜系統知道怎麼做，不代表使用者就該這樣做
從把系統步驟直接變成使用者流程的失敗經驗，說明系統怎麼處理與人要怎麼完成工作是兩個不同問題。
Day 8｜沒有告訴 AI 的事
整理 AI 規劃與反問如何提早暴露需求缺口，並區分使用者忘了說與使用者自己尚未理解的兩種資訊缺失。
Day 7｜一句「平常都這樣做」，後面藏了多少事情？
以提醒、跨情境與颱風假等例外為例，說明人的經驗如何藏著未明說的條件，以及需求如何被持續追問撐開。
Day 6｜把反覆確認的工作交給系統之後
從預約背後的固定確認與例外判斷，說明系統適合接手哪些工作，以及自動化與順手完成工作之間的差距。
Day 5｜做自己的系統，不代表什麼都要自己做
整理 Google Calendar、Sheets、Drive 與 Gmail 等成熟工具如何補上產品能力，也看見工具串接不等於工作流程順暢。
Day 4｜如果所有事情都能交給 LINE 機器人就好了
回顧把預約流程全部放進 LINE 機器人的最初構想，以及熟悉入口、對話流程與前端能力如何影響產品形式。
Day 3｜功能是從觀察和許願長出來的
從觀察諮商所實際工作與提出改善願望開始，回看預約管理產品的需求與功能如何一個一個長出來。