0→1 建置整合行銷公司的內部系統
把說不清楚的行銷工作規則，轉化成系統化執行的管理流程。
專案背景
業主是一間業務橫跨廣告執行、電商運營與整合行銷的大型行銷服務公司，計畫將所有內部作業流程系統化，以因應業務擴張。在此之前以共用試算表管理，業務規則分散在各部門的習慣做法與各種版本的文件紀錄中。
這不是一個優化既有系統的專案，而是把沒有人說清楚過的工作方式，第一次轉化成可以被系統執行的邏輯。我以 UX/UI 設計師的身份主導系統規劃與設計交付，負責需求訪談、PRD 撰寫、Prototype 設計與 UAT 測試。
| 痛點 | 設計挑戰 | 我的任務 |
|---|---|---|
| 業務規則分散在各部門習慣做法中，沒有統一的資料來源與操作規則。 | 五種角色的權限與資料可見範圍，必須在元件層控制，不能靠頁面區隔。 | 把隱形的業務規則轉化為系統可執行、使用者可操作的具體設計依據。 |
脈絡訪查（Contextual Inquiry）
挖掘使用者沒說出口的潛在需求
領域知識高度客製化，需要先弄清楚規則，因此採用脈絡訪查的方法。我們請內部人員帶著走過實際操作流程，針對每一段業務流程進行結構化追問：流程的起點與終點在哪、最關鍵的節點是什麼、是否需要主管審核、狀態要系統自動關聯還是人工註記就夠、例外情況如何處理……等。
再把理解到的規則，轉述成系統的運作方式和流程邏輯回饋給對方確認，反覆釐清與對焦需求，直到規則的邏輯和邊界明確為止。
三類隱形規則
透過訪談看到文件和現實之間的落差
透過實際操作流程的觀察，浮現出三種類型的隱形規則：
Key Insight
主要使用者能描述習慣，說不清楚規則；文件記錄理想流程，不是實際執行。訪談的工作是在這兩個落差中，把隱藏其中的判斷邏輯逐條建構出來。
設計決策
以 AI 分工建立規格驗證流程
本專案領域知識高度客製化，業主很難從文字規格想像系統實際運作，標準的「規格 → 設計 → 開發」流程，預期會製造大量來回確認的成本。
我設計了一套 AI 協作工作流，分三個層次運作：
定義五大業務流程的依賴關係與設計的優先序
系統涵蓋系統設定、客戶管理、專案管理、委外管理、財務管理五大業務流程，彼此有明確的依賴關係：客戶管理是所有流程的起點——沒有客戶資料，所有資料都無從掛載；委外管理從專案管理延伸，記錄採購與交付狀態；財務管理同時關聯專案與委外，確保每一筆收支都能追溯到對應的業務來源。
這個依賴結構決定了 IA 的設計優先順序：先定義客戶主檔的資料模型，再往下延伸專案與委外的關聯邏輯，財務計算規則最後定義。
角色權限對應把組織層級與職能邊界區分開來
權限設計最複雜的是組織現實和系統權限之間的落差。研究階段識別出的虛設角色與邊界不清問題，在這裡轉化成具體的設計判斷：
- 移除業務角色：業務分工只做為獎金分配依據，無專職業務人員，業務工作在開案簽約後即告結束，把這個角色設計進系統只會製造不必要的邊界與維護成本
- 主管向下兼容：主管級同時可能身兼專案經理執行專案，權限需要向下兼容的設計
- 財務獨立角色：財務在組織上隸屬總經理室，但組織位階不等於系統權限，財務負責處理發票與收付款，審核單據與簽核是主管的工作，兩者邊界不同，需要各自獨立的角色
組織架構負責確保內部溝通順暢，權限設計要判斷的是這個人在系統裡需要做什麼，以及不應該做什麼。
設計成果
系統規格分批對應功能模組完整交付，每個模組在進入開發前均已通過可互動原型的易用性測試驗證。AI 分工流程將原本的設計週期縮短 2–3 週，第一版原型在需求釐清 1 週內交付，後續設計調整都能在 2 天內完成並交付。
業主回饋
設計過程中被問到的問題，讓他們第一次把許多習以為常、從未被定義的工作環節說清楚——隱形規則第一次有了語言。
心得與反思
本專案是一次導入 AI 開發流程嘗試，原本是同時產出完整的規格文件和測試文件等多份文件，明確定義所有功能的規格和邊界，並以規格驅動開發的模式完成產品。
然而，迫於專案時程壓力，需求釐清和設計是幾乎同時在進行，而每個階段討論的工作流又環環相扣。在規格尚未收斂的階段，過早產出下游文件只會製造更多需要維護的負擔。
最後決定收斂為只維護 PRD 作為單一事實來源，等全部規格確定後再依需求補上其他文件。
在規格還沒收斂的階段強行往下走，製造的是更大的負擔；知道什麼時候該停，才是設計師的判斷，不是妥協。
