Wireframe 線框圖設計入門：UI/UX 必學的網站原型規劃技巧與工具推薦
Wireframe 線框圖是網站或 App 在進入視覺設計之前、用灰階線條與方框組成的低擬真版面草圖，目的在於把每個區塊的位置、大小與功能優先順序先定下來，讓團隊在花錢做設計與寫程…
Wireframe 線框圖是網站或 App 在進入視覺設計之前、用灰階線條與方框組成的低擬真版面草圖，目的在於把每個區塊的位置、大小與功能優先順序先定下來，讓團隊在花錢做設計與寫程式之前先對齊共識。在線框稿階段改一條線的成本，往往只有視覺完成後再改的零頭，因為後期修正通常牽動設計重做與程式重構，這才是它真正省下來的錢，不是工具費。
重點先看：判斷要不要做線框稿只有一個標準：它能不能降低這個專案的溝通成本；會就做，不會就是儀式，砍掉。多數新手把線框稿畫得太漂亮、太愛用顏色，反而失去它存在的意義。
Wireframe 線框圖是什麼？先把它想成網站的裝潢平面圖
Wireframe（線框圖／線框稿）的中文意思是「線框草稿」，是網站或 App 進入視覺設計之前的低擬真版面藍圖，只用灰階線條、色塊與方框組成，刻意拿掉配色、字體、照片這些會干擾判斷的元素。它回答的不是「這頁要長怎樣」，而是「這頁要放什麼、放哪裡、使用者怎麼走」。如果你熟悉 UI 與 UX 設計的差異與完整工作流程，就會知道線框稿落在「定義問題」與「視覺設計」之間，是銜接兩端的那一塊。
用裝潢平面圖來比喻最貼切。你買了新房，不會一進門就挑沙發顏色，而是先拿一張平面圖，決定電視牆在哪、餐桌放哪邊、走道留多寬。等到動線定了，才請設計師談配色與家具。網站線框稿也是同樣的道理：先把內文放哪、按鈕放哪、選單長在什麼位置敲定，再交給視覺設計與前端工程。這個順序一旦顛倒，後面幾乎一定返工。
本質上它是「資訊架構的藍圖」，不是「視覺設計的初稿」。只關心內容放哪、功能長在什麼位置、使用者怎麼走流程。所以灰階、單一字體、方框代替圖片這些限制，全都是刻意的：目的是逼大家把注意力集中在結構與功能本身，避開漂亮的漸層或圓角度數這類干擾。說到底，線框稿存在的意義，是讓 顧客旅程地圖與使用者流程 在畫面上具體化，把設計師的主觀偏好放一邊。
不過要提醒一件容易被忽略的事：線框稿的價值來自「開發初期對齊共識」，而「畫得很完整」反而常常是干擾。一張乾淨的手繪草圖，只要能讓 PM、工程師、客戶三方面對同一張紙點頭，它的任務就完成了。反過來，一份用 Figma 雕了三天、細到每個像素的高擬真稿，如果沒有人一起看、沒有人討論，它就只是一張昂貴的圖，省不下任何返工成本。判斷它好壞的真正標準，是「有沒有把最貴的決策前置到最便宜的階段」。
為什麼動手做網站前，這張灰階草圖不能省
因為在線框稿階段改一條線，成本是在視覺完成後改的零頭。它把「功能優先順序」「使用者流程」「團隊共識」這三件最貴的事情，全部前置到最便宜的階段處理。一張灰階圖溝通的效率，遠高於一份十頁的文字規格書，這也是為什麼幾乎所有網站開發團隊都會把它排進 網頁設計從零到一的完整指南 的前期。
把好處拆開來看，價值其實集中在溝通與時機兩個層面。一張灰階圖比十頁文字規格書更容易讓 PM、工程、客戶看懂各自負責哪一塊，省下反覆開會確認的時間；而後期修改往往牽動設計重做與程式重構，線框稿階段的修正幾乎免費，這才是它真正省下來的錢。功能優先於視覺也是同樣的道理，灰階強迫團隊先回答「這頁要解決什麼問題」，把配色漸層這類決策往後挪；等到中高擬真稿能拿去做可點擊流程測試，在寫程式前先驗證假設，結合 Persona 人物誌與目標受眾輪廓 會更聚焦。
以一個常見的中型活動網站為例，客戶在中擬真線框稿階段臨時要把首頁的報名表單往下移一個區塊。這類站常見幅度大約是：改動只花十分鐘，重新排列幾個 frame 就收工。如果同樣的改動發生在視覺完成後，則往往要重做首圖、重排間距、重新切版，工程那邊還要調整元件順序，工作量約落在兩到三天之間。這就是「在對的階段做對的事」的實際差距，精確數字因團隊而異，但「零頭」這個形容在實務上並不誇張。
換個角度想，這也解釋了為什麼很多新手覺得線框稿「沒什麼用」。他們把線框稿畫完就收進抽屜，從來沒拿去和團隊一起看、一起吵。沒有共識這一步，線框稿就只是一張草圖，自然感受不到它省下來的錢。所以問題從來不是「要不要畫」，而是「畫完之後，有沒有真的用它來對齊」。把它放進 設計思考五步驟與使用者需求 的原型階段一起討論，效果會最明顯。
低擬真、中擬真、高擬真線框稿：該做到哪一層
差別在「細節密度」與「使用時機」。低擬真是紙筆概念草圖，用來快速試想法；中擬真是 Figma 等軟體做出的灰階結構，用來團隊評估；高擬真已接近最終設計，用來客戶確認與流程測試。原則是專案越小越早停在中低擬真即可，不要一頭栽進高擬真。業界普遍把這三層當成 UI/UX 方法的共識分類。
| 擬真度 | 製作方式 | 細節密度 | 主要用途 | 適用階段 |
|---|---|---|---|---|
| 低擬真 Low-fidelity | 紙筆、白板 | 只有區塊與文字標示 | 三十分鐘內產出多個方案快速比稿 | 概念發想期 |
| 中擬真 Mid-fidelity | Figma、Sketch | 灰階層級加示意元件 | 團隊評估與內部討論 | 設計前期到中期 |
| 高擬真 High-fidelity | 專業設計軟體 | 接近最終成品含圖片配色 | 客戶確認與使用者測試 | 設計後期 |
低擬真線框稿是最初階、成本最低的型態，通常是隨手在紙上描繪或在白板上畫，只包含基本版面結構與元素配置，目的是三十分鐘內產出多個方案快速比稿。它的價值在「快」與「便宜」，畫錯了擦掉重來沒有任何心理負擔。發想方向卡住時，把問題丟給 Perplexity AI 查資料找靈感，往往能快速蹦出幾個還沒想過的版面組合。如果你想了解整個流程的全貌，可以參考 免費 UIUX 自學資源與學習地圖，裡面會把線框稿放在更完整的脈絡裡。
中擬真線框稿比低擬真更詳細，會加入灰階層級與示意元件，通常用 Figma 或 Sketch 製作，是實務上最常用的交付層級。它有助於更具體地理解設計細節，同時保留修改的彈性。多數團隊的日常工作都落在這一層，因為它在「清楚」與「可改」之間取得了最好的平衡。搭配 Figma 中文完整教學從入門到精通 一起練，能很快把中擬真稿的產出速度拉起來。
高擬真線框稿是最接近最終成品的草圖，包含真實圖片、字體、顏色甚至互動效果，通常只在提案給客戶或做使用者測試時才需要。它的成本最高，也最難改，所以一旦做到這一層，就代表前面兩層的決策已經底定。小專案如果直接跳到高擬真，往往會把自己綁死在細節裡，反而失去線框稿「快速試錯」的本意。
關鍵判斷在這裡：低擬真與中擬真若無特殊需求，擇一即可。多數專案根本不需要三層全做，硬要把紙筆、灰階稿、高擬真稿都跑過一遍，純粹是浪費時間。判斷標準只有一個：這個專案現在需要多詳細的資訊才能做決定？需要到什麼程度，就做到什麼程度。這也是 Figma 完整指南與 UIUX 設計實戰 裡反覆強調的原則：擬真度要配合決策密度，不是越高越好。
Wireframe、Mockup、Prototype 的分工界線
Wireframe 管「結構」（東西放哪）、Mockup 管「外觀」（東西長怎樣）、Prototype 管「互動」（點下去會去哪）。三者是設計流程的三個遞進階段，不是同一個東西的三種說法，混用會讓團隊雞同鴨講。這個區分是多數競品沒講清楚的資訊缺口，也是新手最容易混淆的地方。
| 階段 | 回答的問題 | 視覺擬真度 | 可否互動 | 常見用途 |
|---|---|---|---|---|
| Wireframe 線框稿 | 頁面有什麼、放哪裡 | 低，灰階 | 通常不能 | 定義資訊架構與功能位置 |
| Mockup 視覺稿 | 最終看起來如何 | 高，含配色字體圖片 | 通常不能點 | 視覺定案與品牌呈現 |
| Prototype 原型 | 使用者怎麼從 A 走到 B | 視需求而定 | 可以，含流程串接 | 使用者測試與流程驗證 |
Wireframe 是灰階、低擬真的草圖，回答「頁面有什麼、放哪裡」。它只關心結構與功能位置，配色、字體、照片這些視覺細節全部被刻意省略。你可以把它想成「還沒穿衣服的骨架」，骨架歪了，衣服再漂亮也沒用。所以它一定是設計流程裡最早出現的那一個，也是爭議最少、最好改的那一個。把它和 SEO 友善的網站架構設計心法 一起想，連搜尋引擎要爬的層級都能在這個階段先顧到，上線後再搭配 Google Search Console 檢視收錄狀況，就能回頭驗證當初的結構決策對不對。
Mockup 是高擬真的靜態畫面，回答「最終看起來如何」，可以包含配色、字體、圖片，但通常不能點。它是視覺定案的工具，用途是讓客戶與團隊確認「這個網站做出來會長這樣」。從 Wireframe 走到 Mockup，中間要決定的是品牌色彩、字體選擇、圖片風格這些屬於視覺語言的事。這時候就會大量用到 網頁配色工具與色盤推薦 與 排版設計技巧與字體行距設定 的判斷。
Prototype 是可互動的流程串接，回答「使用者怎麼從 A 走到 B」，背後常接著使用者測試。它可以是從 Mockup 加上連結轉場而來，也可以是直接把中擬真線框稿串起來做早期測試。重點在於它「會動」，能讓受測者實際點擊、走完流程，從中觀察哪裡卡住、哪裡找不到按鈕。想知道兩者更細的差別，可以看 UI Prototype 原型設計與 wireframe 的差別，裡面有完整的對照。
三者其實是一條遞進的鏈：先有結構（Wireframe），再長出外觀（Mockup），最後賦予互動（Prototype）。每一層回答的問題不同、成本不同、可改動的幅度也不同。把它們混在一起講，最大的風險是客戶以為你已經在做視覺，結果你只是在畫結構；或是團隊以為 Prototype 就是可上線的成品，結果連資料庫都還沒接。名詞先分清楚，後面的討論才不會失焦。
畫線框稿的設計原則：越乾淨越有力量的 6 個判斷
核心原則只有一句：線框稿是給「別人看懂」的，不是給你自己爽的。實務上要守住灰階分層、單一字體、方框代圖、留白優先、資訊排序、換位思考這六個判斷。這六個判斷的共同目的，是把視覺干擾壓到最低，逼所有人聚焦在結構與功能本身。
- 灰階不是只有黑白。用三到四個明度層級區分主要內容、次要內容、背景，建立視覺優先順序，這是線框稿能不能讓人一秒看懂的分水嶺。
- 固定用一種字體。同時出現兩三種字體，團隊會誤以為不同字型代表不同設計意圖，徒增溝通成本。
- 用方框代替圖片。除非高擬真階段，否則不放照片，用方框與圓形代替以避免視覺干擾；需要圖示時用 免費 Icon 圖示網站資源 找簡單線條版本即可。
- 留白優先。寧可區塊之間留多一點距離，也不要把畫面塞滿，留白本身就是在暗示「這裡是不同區塊」。
- 排好資訊優先順序。最重要內容放左上視覺熱區，CTA 與核心功能要先被看見，這部分可以對照 CTA 行動呼籲按鈕設計指南 的邏輯。
- 換位思考。畫的時候假設看的人是 PM、客戶、工程師，不是設計師同行；符號要看得懂，不能用自創縮寫。
灰階分層這一點特別值得展開。很多新手以為「灰階就是黑白」，於是整張稿只有黑框與白底，所有區塊看起來一樣重，等於沒有重點。正確做法是用三到四個明度層級：最深的一層給標題與主要內容、中間灰給次要內容、最淺的灰給背景與次要元件。這樣一張稿擺開來，視線會自然落在你希望大家先看的地方，不需要任何文字說明。這個分層邏輯和 色彩學與對比色互補色配色技巧 裡講的明度對比是同一件事，只是搬到灰階版本。
單一字體也是常被忽略的一條。線框稿裡如果同時出現兩三種字體，團隊會下意識去猜「為什麼這裡用 A 字、那裡用 B 字？是不是有不同的設計意圖？」這種猜測會吃掉注意力。所以線框稿階段固定用一種中性字體就好，例如系統預設的無襯線字，字型選擇這件事留到 Mockup 階段再用 網頁字體選擇與中文字型載入 的方法處理。
方框代圖的道理也一樣。除非你已經做到高擬真，否則放真實照片只會引來「這張圖不好看」「可以換一張嗎」這類完全偏題的討論，白白浪費大家聚焦結構的機會。需要示意圖片位置時，用打叉的方框或灰階色塊標示「這裡會有一張圖」就夠了。要找示意用素材，商用免費圖庫網站總整理 裡的資源留到 Mockup 階段再用更合適。
Wireframe 工具的選擇：從紙筆到專業軟體
低擬真階段紙筆就夠用且最快；要交付與協作就用 Figma，免費方案足夠、即時多人協作、可做 prototype 與 mockup 一條龍，是當前主流；Sketch 與 Adobe XD 則是 macOS 與 Adobe 生態的進階選項。對新手與多數專案，Figma 是性價比最高的預設選擇，實際金額以各工具官網為準。
| 工具 | 平台 | 免費方案 | 協作 | 適合階段 |
|---|---|---|---|---|
| 紙筆 | 不限 | 零成本 | 難保存與協作 | 低擬真發想 |
| Figma | 跨平台（瀏覽器） | 有，足夠新手使用 | 即時多人協作 | 中擬真到 mockup、prototype |
| Sketch | 僅 macOS | 無免費方案，有 30 天試用 | 支援團隊協作 | 中高擬真進階設計 |
| Adobe XD | 跨平台 | 無免費方案，有 7 天試用 | 支援團隊協作 | Adobe 生態團隊 |
紙筆是零成本、零學習曲線的選擇，適合發想與概念草圖階段。它的缺點是難以保存與協作，畫完要拍照傳給團隊，修改也只能重畫一張。但正因為門檻這麼低，它反而是最快能逼出想法的工具：不用開軟體、不用想檔名、不用排版，拿筆就畫。新手不知道從哪開始的時候，先從紙筆開始把腦袋裡的東西倒出來再說，通常是最順的起手式。
Figma 是當前最主流的選擇。它跨平台、用瀏覽器就能跑、免費方案對新手夠用，而且即時多人協作是它的核心強項，團隊成員的游標會清楚顯示在畫面上，任何人都能在任意位置加註解。你可以從中擬真線框稿一路做到 mockup 與 prototype，一條龍不用換工具。如果你想系統化學會它，Figma 網格系統與響應式排版設定 與 Figma 響應式設計與行動版排版 是很好的起點。
Sketch 是為 UI/UX 設計師打造的 macOS 應用程式，向量工具強，由 Bohemian Coding 開發。它也提供團隊協作與留言註解功能，但只限 macOS，而且沒有免費方案，只有 30 天免費試用。對已經在蘋果生態、又需要向量精度的設計師來說是合理選擇，但對跨平台團隊就比較吃力。
Adobe XD 是 Adobe 開發的 UI/UX 設計工具，能在 macOS、Windows、iOS、Android 上使用，最大優勢是與 Adobe 全家桶整合，設計檔可以存進 Creative Cloud 跨裝置存取。它同樣沒有免費方案，只提供 7 天試用。適合已經在用 Photoshop、Illustrator 等 Adobe 工具的團隊，把設計工作流集中在一個生態裡。
對多數新手與中小型專案，Sketch 與 Adobe XD 不是必要選項。Figma 的免費方案加上完整生態已經能 cover 從線框稿到 prototype 的全部需求，硬要為了工具付費訂閱，反而本末倒置。把省下來的錢與時間花在 新手必裝的 Figma 外掛推薦 與 Figma 圖示外掛快速匯入 Icon 這類生產力提升上，回報會更高。
比較新的變化是 AI 輔助。Figma 有 AI wireframe 外掛，輸入網站類型描述就能生成中擬真稿。這對完全沒有設計基礎、卻需要快速產出一版結構的人很有幫助。想了解 AI 在設計流程裡的其他應用，可以看 Figma AI 功能與 Design Agent 實戰，裡面有更多把 AI 放進工作流的具體做法。
線框稿的完整工作流程：從一張白紙到團隊簽字
很多新手卡關，是因為把線框稿當成「打開軟體就開始畫」的單一動作。實際上它是一條有順序的流程，跳過前面任何一步，後面都要加倍補回來。把流程拆成七個階段，每一個階段都有明確的產出與判斷點，團隊才知道現在在做什麼、做到哪裡才算完成。
- 釐清頁面目標。先回答「這一頁存在的目的是什麼」：是促成註冊、是回答使用者問題、還是引導到下一頁。目標沒有寫下來，後面所有版面決策都會失去評估標準。
- 列出必備內容清單。把標題、正文、圖片、表單欄位、CTA、頁首頁尾全部條列出來，先有材料再決定怎麼擺，避免畫到一半才發現漏了重要區塊。
- 決定資訊優先順序。把清單上的項目依重要性排序，最重要的內容排在視覺熱區，次要內容往後放。這一步直接決定灰階分層的深淺。
- 低擬真草圖發想。用紙筆或白板快速產出兩到三個版面方向，重點在於量與速度，不追求精緻，目的是比較不同排列組合的優劣。
- 挑選方案並升級到中擬真。把團隊選定的方向搬到 Figma，補上灰階層級與示意元件，讓 PM 與工程師能具體討論。
- 內部走查與修改。邀請 PM、工程、內容負責人一起看稿，逐區塊確認功能位置與流程，把爭議在這個階段全部吵完。
- 簽字與交付。線框稿一旦定案，請所有決策者在文件上留言或標記確認，作為後續視覺設計與切版的依據，避免事後翻案。
這七個階段裡，最容易被打折扣的是第一步與第七步。釐清目標聽起來像廢話，但只要回頭看幾份自己畫過的稿，就會發現很多版面爭議的源頭，其實是「這頁到底要解決什麼問題」從來沒被寫下來過。至於簽字交付，很多團隊覺得「大家看過就好」，結果進到視覺階段客戶突然要動結構，又沒有白紙黑字的確認記錄可依循，只好整頁重來。把這兩端補實，線框稿才能真正發揮把成本前置的效果。
走查會議有一個常被忽略的技巧：不要讓設計師逐頁簡報，而是把稿攤開，請參與者輪流用手指著畫面說出「我以為這裡要放什麼」。這種換位複述的方式，能瞬間暴露設計師與其他角色之間的認知落差，比設計師單向解釋有效率得多。發現落差當場標註，會後再統一修改，避免會議失焦。
響應式線框稿：手機優先的版面決策
行動裝置已經是全球網站流量的主要來源。根據 Statista 的統計，2026 年第一季行動裝置（不含平板）占全球網站流量的 52.27%[來源：〈Share of mobile web traffic worldwide quarterly 2015-2026〉〈https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/〉〈2026-04-28〉]。這個比例意味著，線框稿如果只畫桌面版、把手機版當成縮小附屬品，等於把過半使用者的體驗交給運氣。把行動版納入線框階段的正式決策，已經是基本要求而不是加分項。
實務上採用「手機優先」（mobile first）的順序來畫：先把最精簡的手機版結構定下來，再往桌面版擴充。這個順序的好處在於，手機版面有限，會逼你先決定哪些內容最重要、哪些可以捨棄，等這個判斷做完了，桌面版只是把已經排好優先順序的內容重新展開。反過來從桌面版開始畫，很容易把手機版塞成桌面版的縮小版，結果每個區塊都擠、重點全部消失。
| 斷點寬度 | 常見裝置 | 線框稿重點 |
|---|---|---|
| 375px 以下 | 小尺寸手機 | 單欄、CTA 全寬、圖片置頂 |
| 768px 前後 | 平板直式 | 可出現兩欄，仍以觸控為主 |
| 1024px 以上 | 桌面、橫向平板 | 多欄排版、側邊欄、滑鼠互動 |
幾個響應式線框稿的判斷原則值得記下。手機版的導覽列要用漢堡選單或底部導航，而不是把桌面版的橫向選單硬塞進窄螢幕。表單欄位在手機上要放大到足以用手指點擊，間距也要比桌面版寬，避免誤觸。圖片區塊要標註是否需要在窄螢幕下隱藏或改成全寬，這些都屬於線框階段就該決定的結構問題。把這些判斷結合 響應式網頁設計 RWD 觀念 一起想，可以避免上線後才發現手機版動線卡死的窘境。
線框稿與效能：把 Core Web Vitals 想進結構裡
線框稿雖然是結構層，但它會間接決定頁面的效能表現。畫面上每多一個首屏大圖、每多一段自動播放影片、每多一個載入才出現的元件，都會在後期變成影響載入速度與互動流暢度的負擔。Google 自 2021 年將 Core Web Vitals 納入搜尋排名訊號，頁面體驗已成為排名的正式因素之一[來源：〈Google Search Central Blog — Core Web Vitals / page experience ranking rollout timing〉〈https://developers.google.com/search/blog/2020/11/timing-for-page-experience〉〈2020-11-10〉]。在線框階段就為首屏內容、圖片數量、互動元件預留合理空間，等於把效能問題前置到成本最低的階段處理。
具體做法是在畫稿時標註哪些內容屬於首屏（above the fold）、哪些可以延後載入。首屏只放真正必要的標題、關鍵訊息與主 CTA，大型圖片或影片區塊往後挪，讓工程師知道哪些資源要優先送出。會員登入彈窗、聊天機器人、廣告版位這些會拖慢互動的元件，也建議在線框稿上標清楚位置與觸發時機，避免日後為了塞這些功能而犧牲使用體驗。投資頁面體驗的回報相當具體，已有公開案例顯示企業在改善 Core Web Vitals 後帶動了營收與轉換率，例如 Rakuten 24 在投入 Core Web Vitals 優化後，每位訪客營收提升 53.37%、轉換率提升 33.13%[來源：〈web.dev (Google) - Why does speed matter?〉〈https://web.dev/articles/why-speed-matters〉〈2026〉]。這些數字說明，效能從來不只是技術議題，而是直接反映在商業成果上。
線框稿評分卡：用五個維度自我檢查
畫完一份線框稿之後，憑感覺判斷好壞往往失準，用一張評分卡逐項打分會客觀得多。五維度評分卡是給設計師與 PM 共用的檢查工具，每個維度給一到五分，總分二十五分。把它印出來或在會議上投影，逐項討論，能讓「這份稿到底夠不夠好」從主觀爭論變成可量化的對話。
| 維度 | 評分重點 | 一分代表 | 五分代表 |
|---|---|---|---|
| 結構清晰度 | 看的人能否一秒說出頁面做什麼 | 區塊混亂、層級不明 | 層級分明、重點突出 |
| 資訊優先序 | 最重要內容是否落在視覺熱區 | 每個區塊一樣大 | 主次清楚、CTA 明顯 |
| 跨裝置考量 | 是否同時規劃手機與桌面版 | 只有桌面版 | 多斷點皆已想過 |
| 可溝通性 | 符號是否團隊都看得懂 | 一堆自創縮寫 | 業界通用符號 |
| 決策完整度 | 是否足以讓團隊做下一步決定 | 還有大量未定事項 | 可直接進入視覺階段 |
總分低於十五分，代表這份稿還不到可以討論的程度，先回頭補結構與優先序。十五到二十分，適合拿來做內部初版走查，收斂方向。二十分以上，就可以正式交付並進入視覺設計。評分卡的最大價值在於讓團隊對「什麼叫完成」有共同標準，避免設計師覺得已經好了、PM 卻覺得還要改的認知落差。
以一個常見的中型電商改版專案為例，這類站通常落在五到八個主要頁面類型（首頁、分類頁、商品頁、結帳流程、會員中心等），用評分卡實測時最常出現的狀況是：結構清晰度與資訊優先序普遍能拿到三到四分，但跨裝置考量與決策完整度往往只有一到二分。原因不難理解，多數團隊習慣先畫桌面版，手機版的斷點行為常常是「之後再補」，而結帳流程這類跨頁面串接又最容易被當成單頁處理，於是決策完整度自然偏低。依這類站的典型表現，整體總分約落在十二到十六分之間，剛好卡在「還不能正式交付」的尷尬帶。這時務實的做法是先回頭補兩件事：把每個頁面類型的手機版斷點標註補齊，以及把結帳流程的跨頁箭頭與分支條件畫清楚，通常這兩項補完，總分就能推到十八到二十分的可交付區間，不必硬把每個維度都拉到五分。要誠實提醒的是，評分卡本身有上限：它檢查的是「結構層有沒有想清楚」，並不能保證視覺階段不會因為品牌色彩或圖片風格引發新的爭議，把評分卡當成萬靈丹、以為高分就一定不返工，是常見的誤解。決策角度上，評分卡最該被當成「還缺哪些決策」的清單來用，看成檢查待辦會比看成成績單更接近它的價值。
線框稿交付檢查清單：簽字前最後核對
在把線框稿交出去進入視覺設計之前，過一遍這份檢查清單，可以把絕大多數後期爭議擋在門外。清單不必每項都寫成長篇說明，重點是有沒有被想過、被標註清楚。
- 每一頁都寫了頁面目標（這頁要解決什麼問題）。
- 所有 CTA 的位置、文字、優先序都已標明。
- 灰階分層至少有三個明度層級，主次內容可一眼分辨。
- 圖片區塊用方框或色塊標示位置，未放真實照片。
- 手機版與桌面版的斷點行為都已在稿上說明。
- 表單欄位、必填項、送送後流程都已標示。
- 頁首頁尾、導覽結構、麵包屑等共用元件一致。
- 跨頁面流程（從 A 頁到 B 頁）已用箭頭或備註串起來。
- 所有符號都是業界通用，沒有自創縮寫。
- PM、工程、內容負責人都已在稿上留下確認記錄。
這份清單看似瑣碎，但它把線框稿最容易漏掉的決策全部攤開。每勾掉一項，就等於少一個未來可能引爆爭議的未定事項。把檢查清單變成團隊的固定儀式，線框稿的品質會穩定地拉起來，整個專案的返工率也會跟著下降。
新手最容易踩的 5 個線框稿地雷
新手在線框稿階段犯的錯，多半集中在「把結構層的事往視覺層挪」這個方向：太早上色、擬真度開得太高、符號自創、優先序混亂、在像素細節上鑽牛角尖。這些都會讓線框稿失去它「快速對齊」的核心價值，把一個本來該省時間的工具，變成浪費時間的儀式。
- 還沒定結構就上色放圖，把線框稿做成半成品 mockup，灰階聚焦結構的意義就沒了。配色留到 網站配色計畫四步驟實戰 那個階段再做。
- 擬真度跟專案規模對不上。一人接案還做高擬真，純粹浪費時間，小專案停在中低擬真就夠了。
- 符號只有自己看得懂。一堆自創縮寫與箭頭，團隊看不懂等於沒做，請用業界通用的。
- 沒排資訊優先順序。每個區塊一樣大、一樣深，等於沒有重點，看的人不知道該先看哪。
- 在對齊一像素、圓角幾度這種事上糾結，早就偏離線框稿「快速試錯」的本質。
過早上色這條是新手最常犯的。一打開 Figma 就忍不住套顏色、放照片，結果一張線框稿畫了兩天，看起來像半成品的 mockup。問題在於：一旦上了色，討論就會被「這個藍太亮」「這張圖不好看」這類視覺意見帶走，結構問題反而沒人談。線框稿之所以是灰階，就是要刻意關掉這個開關。所以請忍住，這階段連 色相環配色完全手冊 都不要打開。
擬真度選錯是第二常見的坑。一人接案、頁面只有三四頁的小網站，做到中擬真灰階稿就已經足夠和客戶確認，硬要再做一份高擬真稿只是讓自己累、讓客戶以為「怎麼還沒好」。判斷標準很簡單：這個專案的決策需要多詳細的資訊才能定案？需要到什麼程度就做到什麼程度。如果連 作品集網站設計指南 這種結構相對單純的案型，中擬真稿通常就夠用了。
後面三條毛病其實同源：符號只有自己看得懂、沒排資訊優先順序、在像素細節上糾結，本質都是把線框稿當成給自己看的草稿，忘了它真正的讀者是團隊。符號要假設看的人是 PM、客戶、工程師，實線箭頭代表點擊跳轉、虛線框代表暫時性區塊這類業界通用記法，在 網頁設計必備的關鍵元素 都有共識基礎；灰階分層用最深的灰給主要內容、中灰給次要、最淺給背景，整張稿若只有同一明度，等於告訴團隊「這頁沒有重點」；至於一像素的對齊、圓角幾度，那是 Mockup 階段的事，在線框稿裡糾結等於在最便宜的階段做最貴的事。排版邏輯可對照 網頁版面設計與響應式排版攻略 來檢視。
哪些專案可以跳過線框稿
不是每個專案都「必須」做正式線框稿。頁面結構單純、套用現成模板、或一人快速試做時，可以跳過；但只要是多人協作、有客戶要確認、或頁面結構複雜，至少做一份中低擬真線框稿仍是省下後期爭吵的最低保險。線框稿是工具不是儀式，判斷它「能不能降低這個專案的溝通成本」才是要不要做的唯一標準。
- 可以省略的情境：套版網站、頁面單純的部落格、個人快速原型、複用既有版型，例如直接用 WordPress 視覺化頁面編輯器比較 裡的版型。
- 不該省略的情境：多人協作、客戶提案、電商或多頁面複雜結構、需要使用者測試。
- 折衷做法：即使不做正式稿，至少在紙上或白板快速畫一輪資訊架構也值得。
可以省略的情境有幾種。第一種是套版網站，例如用 Elementor、Divi 或 Bricks Builder 這類工具直接套現成版型，結構已經被模板定義好，線框稿的邊際效益很低。第二種是頁面單純的部落格，文章頁的結構大同小異，套主題即可。第三種是一人快速試做原型，目的只是驗證想法，紙筆畫一輪就夠。
不該省略的情境也很清楚。多人協作時，沒有一張共同的灰階圖，每個人對「這頁要放什麼」的想像都會不一樣，等到各自做完才發現兜不起來，這是最貴的錯誤。客戶提案時，線框稿是讓客戶在視覺之前先確認結構的唯一工具，跳過它等於讓客戶在視覺稿階段同時評結構與配色，兩件事混在一起很難談。電商或多頁面複雜結構更需要，因為頁面之間的流程一旦亂掉，影響的是轉換率，這部分可以對照 Landing Page 轉換率優化原則 來看結構對轉換的影響。
折衷做法其實是最務實的。即使專案小到不值得開 Figma 做正式稿，至少在紙上或白板快速畫一輪資訊架構也值得。這一輪的重點在於逼自己把「這頁要解決什麼問題」「使用者進來後要去哪」先想清楚，至於有沒有留下漂亮的文件反而是次要的。把它和 響應式網頁設計 RWD 觀念 一起用，連手機版的區塊順序都能在這階段先想過一遍。
收束回那句標準：判斷要不要做線框稿，只看它能不能降低這個專案的溝通成本。會就做，不會就是儀式，砍掉。能降低成本，哪怕只是紙上一張草圖也值得；不能降低成本，哪怕用 Figma 做得再精緻也是浪費。這個判斷不需要任何工具，需要的是對專案規模與團隊組成的誠實評估。把它放進 網頁設計自學路線圖與接案策略 的整體規劃裡，你會更清楚什麼時候該投資在線框稿、什麼時候該直接往下走。
線框稿不是設計流程裡的裝飾品，它真正的作用是把後期返工的成本往前期搬。這一步站穩了，後面的視覺設計與前端切版才有發揮的空間。對新手來說，工具選擇遠不如把上面六個設計原則與五個地雷記熟來得重要，那才是真正決定線框稿好壞的關鍵。想往更進階的版面配置走，Bento Grid 網頁版面配置設計 會是下一步的好材料。
線框稿常見問題 FAQ
線框稿要畫到多細才夠？
細到「能讓看的人做決定」就夠了。每個專案需要的決策密度不同，需要多詳細就畫多詳細。判斷標準是它能不能降低溝通成本，能就繼續畫，不能就停下來。
什麼情況下可以不做線框稿？
結構已經被模板定死的套版站、頁面大同小異的部落格、純粹試想法的個人原型，這幾種可以直接跳過。但只要牽涉多人協作、要對客戶提案，或頁面流程一複雜起來，至少補一份中低擬真稿，才不會後期吵不完。
線框稿可以放真實圖片和顏色嗎？
原則上不要。除非已經做到高擬真階段，否則放照片與配色會把討論帶偏到視覺意見，失去灰階聚焦結構的意義。圖片位置用打叉方框或灰階色塊標示即可。