PM 打開文件解釋：「這裡先驗證，再送出…」

工程師立刻質疑：「這個檢查到底是前端還是後端做？」

設計師皺著眉：「我以為這一步會直接跳到下一個畫面？」

主管更直接：「我只想知道，下週能不能上線。」

同一份文件，卻冒出三種不同的質疑聲音。PM 並不是沒準備，資訊也不是不完整，而是沒有被轉譯成最適合的格式。結果就是：每個人腦中都有不同的版本，最後只能雞同鴨講。

這正是為什麼，PM 需要把「圖解」當成第二語言。

圖解是 PM 的「第二語言」

文字像小說，能交代細節，但會讓人各自腦補；圖解像地圖，雖然簡化了內容，卻能快速讓大家找到方向。

在專案裡，不同角色看同一份文件，卻常常腦中浮現完全不同的畫面：

• 工程師在想 API 與邏輯
• 設計師在想畫面與互動
• 主管在想時程與風險

如果缺少圖解，就像一群人拿著同一本小說，卻腦補出三種畫面分支。圖解的價值，就是把這些資訊翻譯成「共通的語言」，讓抽象的需求先變得結構化，再進一步落實到設計與開發。

六種最常用的圖解

不用學會所有工具，掌握這六種圖解，就能解決七、八成的溝通誤會。

流程圖（Flowchart）

最常見也最直覺。它能把「先做什麼，再做什麼」清楚畫出來。

文字寫「先登入，再驗證，再導向」聽起來很合理，但工程師馬上會問：「驗證失敗怎麼辦？」、「如果用第三方登入呢？」文字很容易漏掉分支。

一張流程圖就能讓所有「如果…那就…」一目了然：

• 成功路徑：註冊 → 驗證成功 → 導向登入頁
• 失敗路徑：驗證失敗 → 顯示錯誤 → 回到註冊頁

有了流程圖，就不怕大家各自腦補。

泳道圖（Swimlane）

流程圖能說明「要做什麼」，但責任不清時就需要泳道圖。它能把不同角色或部門放在不同「泳道」，清楚顯示誰該做什麼。

例如：

• 行銷要推播
• 前端觸發事件
• 後端排程處理
• 客服收到回報

過去如果只有文字，常常變成「我以為是你要做」。泳道圖一出來，責任邊界立即明確。

序列圖（Sequence Diagram）

序列圖特別適合描述系統互動，像是一場「對話紀錄」。誰先發話、誰回應、誰再傳給第三方，一清二楚。

最典型的例子就是訂單支付：

使用者送出訂單 → 前端呼叫 API → 後端驗證 → 呼叫第三方金流 → 回傳成功訊息 → 前端顯示「付款完成」。

如果沒有序列圖，前後端很容易各說各話：

• 前端認為先 call 金流，成功再驗證
• 後端卻覺得應該先驗證，再丟給金流
• 測試人員照著文件測，結果流程根本跑不通

這種爭議在會議裡可能來回半小時，有序列圖的好處就是，把「誰先誰後」畫出來，避免反覆溝通，也避免到最後才發現落差。

時程圖（Timeline / Gantt）

主管最關心的不是「怎麼做」，而是「什麼時候能交付」。時程圖能把進度和任務依賴關係 (dependency) 直覺地展現出來。

舉例：假設要做「新會員註冊功能」：

• UX 設計（第 1–2 週）
• 前端開發（第 3–4 週）
• 後端 API（第 3–5 週）
• 整合測試（第 6 週）

這裡的路徑依賴很明顯：測試必須等前端和後端都完成才能開始。如果負責後端的 Alexsandra 因故延遲到第 7 週，那麼測試就必然被往後推，最後上線也會延遲。傳統的文字形文件只會寫「第 6 週測試」，除了無法以視覺化看出時間長短外，更糟的是，看不出依賴關係。而在甘特圖裡，箭頭清楚的表示出「測試依賴前端與後端」，一眼就能看出關鍵路徑在哪。

決策樹（Decision Tree）

決策樹最適合處理「條件一多就像程式邏輯題」的情境。它把規則拆成分支，讓複雜的邏輯變得清晰。

例如權限判斷的情境：

• 如果使用者是管理員 → 顯示全部功能
• 如果是一般銅會員→ 顯示標準功能
• 如果是訪客 → 只能瀏覽公開頁面
• 如果符合特殊條件（例如新註冊三天內） → 額外跳出導覽教學
• …

如果只用文字寫，常常變成「若 A 且 B，或 C 且非 D…」讀起來像繞口令 (邏輯去走去去走)。

決策樹則能讓每個分支逐層展開，任何人看一眼就懂。對工程師來說，這等於是「程式邏輯的可視化版本」，對測試人員來說，也能馬上推導出測試案例。

心智圖（Mind Map）

心智圖最適合在需求還很零碎的時候使用。Kickoff 或腦暴會議後，大家丟了一堆點子，最後誰都搞不清楚全貌。這時候快速畫一張心智圖，就能把碎片整理成結構。

例如「新會員體驗」可以展開為：註冊流程、導覽教學、優惠券發放、客服協助。

它不需要精美，但能讓團隊馬上看到完整輪廓，且能幫助好記憶。

圖解就像是我們的溝通瑞士刀。在不同情境之下，採用不同圖解方式，就能避免大部分的溝通誤會。

傳統做法的痛點

既然圖解這麼好用，為什麼很多 PM 卻不愛畫？

因為傳統做法真的太折磨人了，隨便列舉一些如下：

• 一堆工具轉來轉去：要畫流程圖得用 Visio，排時程圖還要 MS Project。工具分散、學習曲線高，PM 常常乾脆用 PPT 硬拉方框。
• 製圖效率低：只想加一個條件，卻要調半天線條。很多人甚至吐槽「改圖比改需求還麻煩」。
• 原始檔容易消失：文件放在 Notion 或 Word，但圖卻在 Visio。等到要更新時，發現只有文件裡那張過期圖片。原始檔早就找不到，只能重畫，或者用小畫家縫縫補補。
• 缺乏快速草稿能力：傳統上，大家只能每次都一次畫到完美，導致速度慢，會議中更難邊說邊畫。最後要嘛畫很久，要嘛乾脆不畫。

總結一句：過去，PM 很少願意做圖解，因為不是太花時間，就是太難改、太麻煩。

曙光：AI 時代自動化的輔助

現在，環境已經不同了。AI 不只能幫你畫圖，而且可以是重新定義圖解的角色。

它讓圖解回到可即時溝通的位置，就像傳統我們開會時，會在白板上直接畫示意圖彼此溝通那樣。

現在，在會議中，PM 可以下 prompt：「把這段邏輯畫成決策樹吧。」AI 立刻生出草稿。然後大家看著圖繼續討論：工程師補上細節、設計師加上註記，如此一來，團隊就能邊在共用空間上看邊改，當場形成共識。

其次，它讓圖解「跟得上變更」。以前需求一改，圖就跟不上，最後乾脆棄用。現在，只要更新需求描述，AI 就能快速刷新圖解，文件和圖能保持一致。(當然，我們還是得檢查一下有沒有畫錯)

最後，以更高維度來看，AI 開啟了「多模態協作」的新時代。今天是文字轉圖，不久後我相信可能可以是以圖轉原型、以簡報轉原型等，讓團隊可以更方便的溝通想法。

掌握圖解力，讓溝通更加順暢

文字是 PM 的母語，但圖解是第二語言。缺少這個語言，溝通就容易有誤解。

當你把六種常用圖解融入日常工作中，不管是 RD、主管還是 QA，都能秒懂你要表達的重點，誤會大幅減少。從此不再雞同鴨講，專案溝通順順過。