業主如何審設計稿：wireframe、視覺稿與可點擊原型各階段該看什麼

設計稿送來了，業主打開檔案，第一句話往往是「這個藍色可以再亮一點嗎」。幾輪下來顏色改了五次，到了開發階段才發現會員註冊少了一個步驟、訂單查詢頁根本沒有地方放篩選條件。審設計稿真正困難的地方，不是審美，而是在對的階段看對的東西。

軟體與網站的設計通常會經過三個階段：線框圖（wireframe）、視覺設計稿、可點擊原型。每個階段回答的問題不同，能改的成本也不同。越早發現流程問題，改起來越便宜；越晚才提出結構性修改，越容易牽動已經完成的工作。

以下依序說明三個階段各自該看什麼、不該在那個階段糾結什麼、回饋怎麼寫設計方才接得住，以及定稿與改稿次數該怎麼事先約定。

為什麼設計審查需要分階段

把設計拆成階段，不是為了多收幾次款，而是為了把不同性質的決定分開做。

線框圖處理的是「資訊放哪裡、流程怎麼走」；視覺稿處理的是「看起來像不像這個品牌、讀起來舒不舒服」；原型處理的是「實際操作起來順不順」。如果三件事混在一起審，討論就會失焦：有人在講按鈕顏色，有人在講欄位該不該必填，會議開完沒有一個結論能落地。

分階段還有一個好處：每個階段結束時，前一階段的決定就被「鎖住」。視覺稿是建立在已確認的線框圖之上，如果到了視覺稿階段才要求把整頁結構重排，等於回頭推翻上一階段，設計方要重做的不只是一張圖。

所以審查的第一個原則是：先問自己現在處於哪個階段，這個階段要回答什麼問題，再開始看稿。

第一階段：線框圖該看什麼

線框圖通常是灰階的方塊與文字，刻意不放顏色與圖片，就是要讓你只專注在結構上。

這個階段要看的重點：

• 頁面清單是否完整：該有的頁面都有嗎？例如忘記密碼、搜尋無結果、訂單取消後的畫面，這些常被遺漏。
• 每頁的資訊優先順序：使用者打開這頁最想知道的是什麼？那個資訊是不是放在最顯眼的位置？
• 流程是否走得通：從入口到完成任務，每一步都有下一步可按嗎？有沒有走到一半卡住、找不到返回路徑的地方？
• 欄位與資料是否正確：表單要填哪些欄位、列表要顯示哪些欄位，是否與實際業務一致？
• 角色差異：管理員、一般會員、訪客看到的畫面是否有區分？

這個階段不該糾結的事：顏色、字型、圖片、圖示風格、按鈕的圓角。線框圖的方塊大小也只是示意，不代表最終比例。在這裡花時間討論美感，等於討論一張草圖的筆觸。

線框圖審查最好對照需求文件一起看。如果需求文件本身寫得不清楚，線框圖就會反映出那份模糊，此時該回頭補需求，而不是在畫面上猜。需求文件的結構可以參考軟體需求怎麼寫。

第二階段：視覺設計稿該看什麼

線框圖確認後，設計方會加上品牌色、字型、圖片與元件樣式，變成接近成品的畫面。

這個階段要看的重點：

• 品牌一致性：色彩、語氣、圖片風格是否符合品牌調性？放在官網、社群、名片旁邊會不會格格不入？
• 可讀性：內文字級在手機上是否看得清楚？文字與背景的對比夠不夠？長段落有沒有足夠行距？
• 層級是否清楚：主要按鈕和次要按鈕看得出差別嗎？標題、內文、說明文字是否一眼就分得開？
• 狀態是否齊全：按鈕的按下與停用狀態、表單錯誤提示、空白狀態、載入中，是否都有設計？
• 響應式版本：桌機與手機版是否都有？手機版不是把桌機縮小，而是要重新安排優先順序。

這個階段不該糾結的事：重新討論流程與頁面結構。如果真的發現結構有問題，要明確標示為「回到線框圖層級的修改」，讓設計方評估影響，而不是混在一般意見裡。另外，示意用的文案與圖片若尚未定稿，不必逐字修改，先確認版面能容納真實內容的長度即可。

可讀性與對比也和無障礙有關，如果網站服務的對象包含年長者或需要輔助工具的使用者，可以順便對照網站無障礙指南檢查。

第三階段：可點擊原型該看什麼

可點擊原型是把設計稿串成可以點擊、切換的模擬操作，還不是真正的程式，但能讓你「用」一遍。

這個階段要看的重點：

• 關鍵任務走一遍：挑三到五個最重要的使用情境，例如註冊、下單、查詢、送出申請，從頭操作到尾。
• 找真實使用者試：請一位沒參與專案的同事或客戶操作，不提示、只觀察。他在哪裡停頓、在哪裡點錯，就是要改的地方。
• 轉場與回饋：按下按鈕之後有沒有明確的回應？送出成功後使用者知道接下來會發生什麼嗎？
• 例外路徑：輸入錯誤、網路中斷、權限不足時，畫面是否引導使用者下一步？

這個階段不該糾結的事：原型的動畫流暢度、假資料內容、以及原型工具本身的限制。原型裡的轉場效果不一定等於最後的實作，假資料也只是佔位。要討論的是「操作邏輯對不對」，不是「原型做得精不精緻」。

原型階段發現的問題，通常是整個專案中最划算的修改時機：它已經接近真實操作，但還沒有寫任何正式程式。這也是為什麼許多團隊在做最小可行產品（MVP）時，會先用原型驗證流程再開發。

回饋怎麼寫，設計方才接得住

同樣一個問題，寫成「這頁怪怪的」和寫成「會員第一次進來看不出要先填資料，建議把步驟提示移到頂部」，設計方的處理速度完全不同。

有用的回饋包含四個元素：

1. 位置：哪一頁、哪一個區塊，最好附截圖並標註。
2. 觀察：你看到了什麼，或使用者遇到了什麼困難。
3. 原因：為什麼這是問題，跟哪個業務目標或使用情境有關。
4. 期待：你希望達到的效果，而不一定是具體解法。

第四點特別重要。業主描述「想達到什麼」，比直接指定「把按鈕改成紅色」更有效，因為設計方可能有更好的做法。當然，如果是品牌規範或法規要求的硬性條件，就直接寫清楚。

回饋範本骨架（可直接複製使用）：

• 頁面／區塊：
• 我看到：
• 這會造成的問題：
• 我希望的效果：
• 優先程度：必改／建議／可留到下一期
• 提出者：

標示優先程度可以避免設計方把每一條都當成同樣緊急。所有意見最好集中在一份文件或一個工具裡，依頁面排序，不要散落在多個聊天群組與電子郵件中。散落的回饋最容易漏改，也最容易出現前後矛盾。

要避免的回饋寫法：

• 只有感受沒有原因：「不喜歡」「不夠大氣」「沒有感覺」。
• 用競品截圖代替說明：「做成像那家一樣」，卻沒說是哪個部分像。
• 同一輪內自相矛盾：第一條要求精簡，第五條要求多放資訊。
• 回饋之後又私下追加：定稿後才補「其實老闆也有意見」。

定稿標準與改稿次數怎麼約定

設計審查最容易拖延的原因，是沒有人說清楚「什麼時候算定稿」。

定稿應該是一個明確的動作：由指定的決策者以書面（郵件或專案工具留言）確認某個階段的稿件版本，之後的修改就屬於變更。這個動作看似形式，但能避免開發進行到一半，又有人拿出舊版說「我記得之前是這樣」。

改稿次數建議在合約或專案啟動時就約定，常見的做法是每個階段包含固定輪數的修改，每一輪回饋要一次彙整提出。這裡的「一輪」指的是一份完整的回饋文件，而不是零星提出的每一條意見。超過約定輪數或推翻已定稿的階段，就依變更流程評估時程與範圍。專案啟動時要約定的事項，可以參考軟體專案啟動前的業主準備清單。

為什麼要限制輪數？不是為了不讓業主改，而是為了逼出決策。實務上常見的情況是，沒有限制時大家習慣「先給個意見、之後再想」，每一輪只解決一部分問題，總輪數反而比一次想清楚還多。

定稿前的自查清單：

• 所有頁面、所有角色的畫面都在稿件中了嗎？
• 空白、錯誤、載入中等狀態有沒有設計？
• 手機與桌機版本都確認過了嗎？
• 該拍板的人都看過了嗎？還有沒有人的意見沒收進來？
• 上一輪的每一條回饋，是否都已處理或明確決定不處理？
• 正式文案與圖片的長度，版面放得下嗎？

業主審稿常見的五個錯誤

一、跳階段審查：線框圖階段要看顏色、視覺稿階段才發現流程不對。結果是前一階段的確認失去意義。

二、只看單頁不看流程：每一頁單獨看都很漂亮，串起來卻斷掉。審稿一定要至少走一遍完整任務。

三、用自己的偏好代替使用者：決策者喜歡的配色或排版，不一定是目標客群最容易使用的。有疑慮時找幾位真實使用者試，比會議室裡辯論有效。

四、決策者缺席：中間窗口確認了三輪，最後老闆看了一眼全部推翻。真正有決策權的人至少要參與線框圖與最後定稿兩個關鍵節點。

五、把設計稿當成功能規格：設計稿呈現的是畫面，但很多行為畫不出來，例如資料排序規則、權限邏輯、通知時機。這些要用文字寫進規格，否則開發階段雙方會各自解讀，到了驗收才出現爭議。

設計審查做得好，後面的開發、測試、驗收都會順很多；做得草率，代價會一路傳到上線前。如果你手上有一份設計稿不知道從何審起，或想在專案一開始就把審查節點與定稿方式規劃清楚，歡迎跟 NETVANA 聊聊。我們的軟體服務一律採詢問報價制，會先依專案規模安排線框圖、視覺稿與原型的審查節點，服務範圍與交付內容可以在軟體服務介紹查看。

延伸閱讀：設計之前需求要先寫清楚，參考軟體需求怎麼寫；開工前要和廠商約定哪些事，看軟體專案啟動前的業主準備清單；改版網站時設計該怎麼銜接舊站，讀網站改版專案指南；想先用原型驗證點子，看MVP 開發指南；設計完成後怎麼驗收，看軟體驗收測試怎麼做；審設計稿時搞不清楚該對誰提意見，可以看軟體專案團隊角色白話解說。