Wireframe 是什麼？線框圖與高保真設計稿的差異，委外開發前你該懂的一步

作者｜瞻新資訊　張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）

如果你正在找廠商做網站或 APP，對方在流程表裡列出「wireframe」這個階段，你可能會愣一下：這是什麼？是不是設計稿的一種？可以跳過直接看漂亮的視覺稿嗎？

這其實是很多第一次委外開發的中小企業主都會卡住的地方。Wireframe（中文常譯作「線框圖」或「線框稿」）不是廠商用來拖時間或多收一筆費用的環節，而是整個 UI/UX 設計流程中，用來把「你腦中的想法」變成「大家都看得懂的架構圖」的關鍵一步。這篇文章會把 wireframe 到底是什麼、它跟你可能更熟悉的「高保真設計稿」差在哪裡、以及委外開發時為什麼不建議跳過這一步，一次講清楚。

Wireframe（線框圖）到底是什麼

一句話定義：先確定架構，還沒開始講究好不好看

Wireframe 是設計流程中用來確認頁面架構與資訊層級的低保真圖，不處理顏色、字體或圖片等視覺細節。它通常用簡單的灰階色塊、線條與文字佔位符，畫出一個網頁或 APP 畫面上有哪些區塊、東西擺在哪個位置、使用者會怎麼操作。

換句話說，wireframe 回答的問題是「這個畫面上要放什麼、放在哪」，而不是「這個畫面看起來會是什麼樣子」。這個角色很像蓋房子之前的平面圖——平面圖不會告訴你牆壁要漆什麼顏色、家具要選什麼材質，但會告訴你每個房間在哪裡、動線怎麼走、門窗開在哪個方向。

這種刻意不做視覺細節的做法，其實是設計上的一種策略：讓所有人在還沒被顏色、字體、圖片這些視覺元素分散注意力之前，先把架構對不對這件事想清楚。

Wireframe 在整個 UI/UX 設計流程中的位置

Wireframe 很少是獨立存在的產出物，它通常銜接在使用者研究、需求釐清之後，視覺設計之前。一個常見的完整鏈路大致是：先釐清使用者會怎麼使用這個網站或 APP（有時會用使用者流程圖呈現），再用 wireframe 把這些流程轉成具體的頁面架構，架構確認後才進入視覺設計階段，把顏色、字體、圖片、UI 元件樣式加上去。

Wireframe 銜接在需求與使用流程確認之後、視覺設計之前，作用是把抽象的操作流程轉換成具體可討論的頁面架構。這個定位在國際互動設計教育機構 Interaction Design Foundation（IxDF）的說明中也有對應描述：互動設計師的工作通常包含畫出 wireframe 來確立產品的結構與流程，之後才視需要再製作互動原型或高保真原型。這與台灣常見的委外開發流程順序一致，可作為讀者理解為什麼廠商流程裡會有這一步、而且排在視覺設計之前的參考依據。

這個順序背後的邏輯很直覺：如果連這個頁面上要放什麼東西、使用者會怎麼點都還沒想清楚，就急著決定顏色跟字體好不好看，很容易在後續發現架構有問題時，連視覺設計都得跟著大改，等於做了兩次工。

Wireframe 跟高保真設計稿（Mockup）差在哪裡

這是繁體中文與英文搜尋結果裡都高頻出現的疑問，尤其對第一次接觸委外開發流程的人來說，線框圖跟設計稿這兩個詞聽起來都像是設計圖，很容易搞混。

兩者確認的東西不一樣：結構 vs 視覺

Wireframe 確認的是畫面上有什麼、東西擺在哪，高保真設計稿確認的是這些東西實際看起來會是什麼樣子，兩者處理的問題不同，不能互相取代。

高保真設計稿（也就是一般說的 mockup 或視覺稿）包含了真實的顏色配置、選定的字體、實際的圖片素材、按鈕與圖示的樣式，簡單說，就是你會實際在瀏覽器或手機上看到的樣子。它是在 wireframe 確認的架構基礎上，把視覺層加上去的結果。

這也是為什麼在委外開發的討論裡，「先確認 wireframe 再進視覺設計」會被反覆強調：如果架構本身有問題，例如某個重要功能被埋在很深的位置、表單欄位順序不合理，等到視覺稿都做好了才發現，通常代表視覺設計也得跟著調整，等於多花一輪工。

低保真、中保真、高保真：保真度是怎麼分的

保真度越低，修改成本越低；保真度越高，越接近最終成品，但修改起來也越花時間。

這句話大致可以對應到業界常見的三個層次：

• 低保真：可能只是簡單的方框、線條與文字佔位符，甚至手繪草圖也算，目的是快速把想法攤開來討論，一個畫面可能十幾分鐘到半小時就能畫出一版，方便反覆調整。
• 中保真：開始加入比較精確的版面配置與基礎的互動邏輯，例如按下這個按鈕會跳到哪一頁，但視覺細節仍未確定。
• 高保真：最接近最終樣貌的階段，通常會搭配可互動的原型，讓團隊或使用者實際操作測試流程順不順。

這個低、中、高的分級並非各家廠商自創、各說各話的說法。知名 UX 研究機構 Nielsen Norman Group（NN/g，由 Jakob Nielsen 與 Don Norman 創立）在其原型設計相關文章中指出，保真度實際上可以拆成互動性、視覺呈現、內容真實度三個獨立軸線來衡量，一個原型或 wireframe 可能在某一軸線是高保真、在另一軸線卻是低保真，例如視覺上很陽春（低保真），但已經可以點擊切換頁面（互動性偏高）。這個三軸框架比單純的低中高三分法更精確，也說明了為什麼保真度不是一個單一刻度，而是要看你在意的是哪個面向。國際上並沒有規定 wireframe 一定要照哪一種固定格式做，但理解這個三軸概念，有助於在委外討論時更精準地跟廠商溝通：現在需要看到的是架構、還是也要看到互動邏輯。

這個分級的意義在於：專案初期需要的是快速討論、方便改，這時候低保真最合適；到了要跟使用者測試、或要交接給工程團隊開發時，才需要更精確的中高保真版本。用錯階段，例如一開始就急著做高保真，反而會拖慢討論速度，因為每改一次架構，連帶要改的視覺細節也變多。

表格：Wireframe vs 高保真設計稿 vs 互動原型，一次看懂三者差異

項目	Wireframe（線框圖）	高保真設計稿（Mockup）	互動原型（Prototype）
主要確認什麼	頁面架構、資訊層級、內容擺放位置	視覺細節：色彩、字體、圖片、UI 元件樣式	操作邏輯與畫面之間的互動流程
保真度	低（灰階色塊、線條、文字佔位符）	高（接近最終成品樣貌）	依工具而定，通常搭配高保真視覺一起呈現
常見出現階段	設計流程最早期，需求釐清之後	架構確認之後、開發之前	視覺設計確定後，準備開發前的測試階段
主要目的	快速對齊架構共識，降低後續返工風險	讓客戶與團隊具體看到長什麼樣子	讓使用者或團隊實際操作，驗證流程是否順暢

中小企業委外開發，為什麼不能跳過 Wireframe 這一步

瞻新資訊長期接觸台北與台灣的中小企業主委外開發網站或 APP，橫跨新創媒合平台、企業內部系統、電商購物商城、行銷活動網頁四大類型的專案情境，這些經驗裡有一個重複出現的模式：老闆對自己的產品或服務很熟，但要怎麼把這份熟悉轉成一個好用的網站或 APP 介面，中間往往需要一個雙方都看得懂的橋樑，而 wireframe 正是扮演這個橋樑的角色。

老闆腦中的想法，跟工程師理解的功能，中間需要一張圖對齊

很多委外開發專案一開始，客戶心中對產品其實只有一個大方向的構想，細節，例如某個功能該放在首頁還是子頁面、表單要分幾步驟填寫，往往是在討論過程中才逐漸清楚。如果沒有 wireframe 這種視覺化的中介工具，光靠口頭描述或文字需求書，客戶、設計師、工程師三方很容易對這個功能長什麼樣子、怎麼運作有不同的想像。

委外開發流程中，wireframe 是客戶與開發團隊在還沒投入視覺設計與工程資源前，先對齊架構共識的工具。它不需要好看，但需要讓不懂設計或技術的人也看得懂，這正是低保真、不做視覺修飾的用意所在：讓大家的注意力集中在這樣安排對不對，而不是被顏色或圖片分心。

這個先確認架構共識、再投入資源的邏輯，其實也呼應國際標準對於互動系統設計流程的一般性建議。國際標準化組織發布的 ISO 9241-210 標準，訂定了以人為本設計（human-centred design）的流程原則，其中明確指出設計方案應先產出代表性的原型，範圍可以從簡單的草圖或靜態畫面示意，到功能完整的系統，再依評估結果反覆修正，而非一次到位。這份標準是國際通用的人因工程與人機互動規範，並非針對台灣市場或特定產業訂定，因此可以作為讀者理解為什麼設計流程普遍建議先做低成本的草案再逐步完善這個原則的參考框架，但實際操作上仍須以個別專案的實際規劃與台灣本地開發團隊的做法為準，ISO 標準本身不規定具體要用什麼工具或畫成什麼樣子。

Wireframe 修改成本，遠比開發到一半才發現問題便宜

架構問題如果留到開發後期才發現，修改成本通常會比在 wireframe 階段修改高出許多。這是一個相對直覺的判斷：在 wireframe 階段，改動一個方塊的位置可能只需要幾分鐘；但如果同樣的問題是在程式都寫到一半才發現，往往牽動資料庫欄位設計、前後端串接邏輯，甚至可能需要重新規劃部分功能，時間與人力成本自然高出許多。

這也呼應瞻新資訊在 UI/UX 設計服務中的定位：使用者流程圖與 wireframe 這類前期規劃產出物，價值不在於畫得多漂亮，而在於有沒有在正式投入開發資源之前，先把可能出錯的地方攔下來。

什麼情況可以簡化、什麼情況不建議跳過

不是每個專案都需要一輪完整、正式的 wireframe 流程。如果專案架構單純、頁面數量少，例如單純的活動報名頁、資訊單頁，而且客戶與團隊對頁面內容已經有高度共識，適度簡化這個階段是合理的。

但如果專案牽涉到多個頁面、有表單流程、有會員或後台系統、或是功能之間有比較複雜的互動邏輯，例如媒合平台、進銷存系統、預約系統這類瞻新常接觸的專案類型，跳過 wireframe 直接進入視覺設計或開發，風險會明顯提高，即使不追求正式繪製，至少用非正式的草圖或條列式流程溝通過架構，也比完全略過來得穩妥。

瞻新資訊的 UI/UX 設計流程，Wireframe 怎麼被處理

從使用者流程圖到 Wireframe，再到 Figma 視覺稿

瞻新資訊的 UI/UX 設計服務中，交付物包含使用者流程圖與 Figma UI 視覺稿，含桌機與手機版本、互動狀態，wireframe 階段銜接在這兩者之間：先透過使用者流程圖釐清使用者會怎麼操作、會經過哪些步驟，再用 wireframe 把這些流程落地成具體的頁面架構，確認架構沒有問題之後，才進入 Figma 的視覺設計階段，處理色彩、字型、元件庫與排版這些設計系統相關的細節。

這個順序的核心理念，瞻新資訊內部的說法是把使用者的行為路徑想清楚，然後把介面設計成他最自然會走的那條路——這句話某種程度上也說明了為什麼 wireframe 不能被跳過：如果連使用者最自然的路徑都還沒想清楚就開始做視覺設計，很容易做出好看但不好用的介面。

瞻新資訊成立超過十年，自 2010 年起，累積經手橫跨工程、宗教、美容、教育、餐飲、金融、機電等四十至五十個以上產業的專案，業主資料顯示，這種產業廣度也代表在 wireframe 規劃階段，需要處理的使用情境相當多元，不同產業的使用者操作習慣與資訊優先順序本來就不一樣，這也是為什麼架構規劃階段需要投入足夠時間，而不是套用單一模板應付了事。

業主提供的實際案例：架構調整帶來的改變

以下兩則案例數據為業主提供，用以說明架構與流程調整可能帶來的改變方向，非第三方驗證數字。

一個網站改版案例中，業主資料顯示調整後使用者的頁面停留時間從約 40 秒提升到 2 分 20 秒，表單填寫率則從 2% 提升到 8%。這類案例通常代表的是：原本的頁面架構可能存在資訊層級不清楚、關鍵行動點不明顯等問題，透過重新梳理使用者流程與頁面架構，也就是 wireframe 階段在處理的問題，讓使用者更容易找到自己要的資訊、更順暢地完成表單填寫這個動作。

另一個 APP 流程優化案例中，業主資料顯示原本需要 7 個步驟才能完成的主流程，簡化為 3 個步驟。這類優化同樣是從架構規劃階段著手，先重新盤點使用者實際需要哪些步驟、哪些步驟可以合併或省略，而不是先做視覺美化再回頭改流程，這也是 wireframe 階段先確定架構、再講究視覺的核心價值所在。

需要留意的是，改善成效會因專案背景、原始問題與調整幅度而異，上述數字為特定案例的業主自述結果，並非對所有專案都能保證的固定成果。瞻新資訊官網本身也明確表態不應相信「保證排名」「保證引用」這類絕對化承諾，這種誠實表態延伸到 UI/UX 設計成效上同樣適用，架構調整能提高改善的機會與條件，但不構成對特定數字結果的保證。

FAQ

如果你正準備委外開發網站或 APP，還不確定自己的專案需要多完整的 UI/UX 設計流程，這類問題其實適合在初期討論階段就先問清楚，讓雙方對接下來會經過哪些步驟、每個步驟在解決什麼問題有一致的理解，比事後才發現漏了什麼要來得省事。