◆ 還沒搞懂需求，就急著打開 Figma
很多專案一開始，都長得差不多。
老闆說：「我們來做一個○○功能。」
PM 開完一次需求會，筆記還沒整理完，
就先打開 Figma/Axure，開始拉畫面。
先畫首頁、再畫登入、再畫註冊，
畫到一半突然想到：「啊，這裡應該要多一個紀錄帳號。」
過兩天老闆又說：「這裡要加一個開關。」
規格改一次、設計改一次、前端再改一次。
等到大家都累了，你才發現：
其實一開始連「誰在用」、「怎麼用」、「要解決什麼問題」
都還沒講清楚。
畫面改到第三版，
需求才慢慢搞清楚。
◆ 不斷改畫面，其實是需求根本沒落地
很多 PM 以為自己在「修畫面」，
但實際上是在幫一開始沒想清楚的需求補洞。
今天業務說：「客戶想要 A。」
你就畫了一版 A 的畫面。
後來發現實際流程不是這樣，
再改成 A’。
再開一次會，客服說：「我們這邊需要有一個XXX的功能。」
再改成 B。
到了要開發前，工程師看完只問了一句：
「所以到底誰會按這個按鈕？它什麼時候會出現？
按下去會發生甚麼事？」
你這才意識到，
前面那些「修改畫面」的過程，
根本不是在做 UI 設計，
而是在補一開始「需求理解」的洞。
畫面只是被你拿來當投石問路的工具。
◆ 畫 Wireframe 前，先把「系統會怎麼動」想清楚
就算你真的把需求聽懂了，
下一個陷阱也很常見：
你知道「大家想要什麼」，
卻不知道「系統要怎麼做到」。
於是 Wireframe 上出現一堆看起來很溫柔的設計：
「這裡加一個開關，讓管理員可以手動覆寫。」
「這裡加一個勾選，就可以決定要不要同步。」
「這裡多一個按鈕，讓使用者可以重新觸發。」
聽起來都只是「一個小地方調整一下」，
實際上背後牽扯的是：
誰有權限改？
改了會不會打斷流程？
改的當下資料在路上還是已經落地？
要不要寫 Log？要不要通知其他服務？
你在 Wireframe 上畫一顆看起來很無害的小按鈕，
RD 心裡想的卻是：
「這顆按鈕按下去，我有可能要重寫一整段流程。」
想得很美滿，
現實真的很骨感。
◆ Wireframe 不是 UI 稿，是「邏輯的草圖」
很多 PM 一畫 Wireframe，就忍不住往「設計」那邊靠。
調間距、選顏色、找 icon、配圖，
畫完之後，看起來像半成品設計稿，
自己看了都很有成就感。
問題來了：
設計師看到，只能先心理建設一輪：
「這些我大概要全部重畫。」
工程師看到，會問：
「按鈕三態怎麼切換？什麼時候可以按？
錯誤要怎麼顯示？ loading 要放哪？」
老闆看到，則會說：
「怎麼跟一般看到的不一樣？」
結果一輪討論下來，
沒有人真的在意你的 配置、配色跟 icon。
Wireframe 對 PM 來說，
真正的任務其實只有一件事：
把你對「需求、流程、資料、狀態」的理解，
整理成一個大家都看得懂的畫面結構。
好不好看，是設計師的專業。
邏輯清不清楚，才是 PM 的本事。
◆ 畫畫面之前，先想好「資訊的重量」
Wireframe 最容易暴露一件事：
你到底知不知道「什麼是重要的」。
以「訂單詳情」為例。
如果沒有資訊架構的概念，
你很容易做出一個畫面：
上面塞狀態、下面塞商品、右邊塞地址、
左邊塞備註，中間再塞操作按鈕。
全部都在畫面上，
卻沒有任何明確的「資料重心」。
但如果你腦中有一點資料與正規化的概念，
你就會先分清楚：
這個畫面，使用者第一眼最需要的是什麼？
（例如：訂單清單、狀態、總金額、接下來能做什麼）
哪些是操作當下會用到的？
（例如：訂單明細、付款紀錄）
哪些只是偶爾需要查？
（例如：發票資訊、訂單備註）
然後依據資料的重要性、使用頻率、資料量體…等
決定哪些要開始要出現，那些要透過「詳情」才出現
還記得我們在 #028 談過的「資料表結構」嗎？
這裡就是它的體現。
如果你知道這筆資料是「一對多」的（例如訂單明細），
你就不會傻傻地把它塞在一個小格子裡，
而是會留出一個「列表」或「展開」的空間。
Wireframe 在畫的，
不是「東西有沒有放上去」，
而是「重要的東西有沒有被擺在對的位置」。
這跟配色無關，
跟你有沒有搞懂資料和流程的優先順序有關。
◆ 畫的不是一張畫面，而是資料的「佈局」
另一個常見的坑，是只畫「一個版本」。
你畫了一張看起來很完整的列表頁，
裡面每一列都有資料、有圖、有文字。
工程師看完問：
「那如果一筆訂單都沒有，要顯示什麼？」
「如果讀取失敗，要提示嗎？」
「如果資料還在路上，要轉圈圈還是骨架畫面？」
「如果有一筆資料特別長，版面會不會破版？」
這些東西，
不是 UI 設計師會幫你自然補上的。
一個有系統觀念的 PM，
在畫 Wireframe 時，通常會至少想四種狀態：
-初始／沒有資料
-載入中
-有資料
-錯誤或逾時你不需要每一種都畫到很細，
但至少要在圖上或註解裡寫清楚：
「這邊有 empty state。」
「這邊 loading 要有明確的回饋。」
「這邊錯誤時不能整個畫面白掉。」因為這些，就是「真實世界」會遇到的狀況。
如果只畫順利路徑（Happy Path），
你就會常常接到客服通知。
◆ Wireframe 是你「懂不懂系統」的期末考
嗨，我是廣三。
在軟體開發裡打滾二十年，
看過太多 PM 被 Wireframe 害慘。
不是畫得不夠漂亮，
而是畫得太快、想得太少。
很多時候，不斷改畫面，
根本不是 UI 的問題，
而是：
需求一開始就沒講清楚；
系統實際運作你也不熟；
資料流、狀態、例外、權限，都還在霧裡看花。
Wireframe 對 PM 來說，
不是「創作時間」，
而是檢查自己有沒有想清楚的一面鏡子。
當你可以在 Wireframe 上：
說得出每個欄位為什麼出現在這裡；
說得出按鈕什麼時候能按、按下去會走哪條流程；
說得出這個畫面有哪些狀態、各自長什麼樣；那表示你不是只在畫畫，
而是真的在用畫面，把系統運作翻譯成大家看得懂的語言。
設計師可以把它變美，
工程師可以把它變成真的產品。
而你，終於不是那個
「一直在改畫面、卻說不出來到底哪裡不對」的 PM，
而是那個能把需求、系統、介面串在一起的人。
這，才是 Wireframe 真正的價值。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
探索更多來自 AI時代|PM破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言