UI Prototype 原型設計：與 Wireframe 差異解析

靜態設計稿可以標示表單、錯誤訊息與返回路徑，但不容易呈現操作時的連續感受。例如返回後資料是否保留、鍵盤是否遮住結帳鈕、等待時是否有回饋，都適合放進互動原型或實作測試。原型只能驗證已模擬的行為；真實鍵盤、網路與金流問題仍須在對應裝置和系統上測試。

UI 原型（UI Prototype）是用來探索或驗證介面行為的模型，可以是紙本模擬、可點擊畫面，也可以用程式製作。線框圖常著重內容與結構，Mockup 常著重視覺，原型則著重操作與回饋；這些用途可以重疊，不一定要在寫任何程式前依序完成三種文件。

這篇會把原型設計整件事拆開來講：從它跟線框圖、Mockup 的差異、低中高三種擬真度到底什麼時候用、互動原型為什麼比靜態稿更能挖出問題、做原型時該守住的設計要點、工具怎麼挑、到怎麼拿原型去做使用者測試與開發交接。如果你還在想 UI 跟 UX 到底差在哪，可以先看這篇 UI/UX 設計差異全解析 把觀念底打穩；想系統化自學的人，這份 UIUX 學習地圖 會是好的起點。

UI 原型是什麼？先把原型、線框圖、Mockup 三個常被混在一起的詞拆乾淨

這三個詞在會議室裡常常被交替使用，但它們指的不是同一件事。實務上習慣用「一張圖能回答的問題」來區分它們，這比死記定義有用得多。

• 線框圖（Wireframe）：用簡化內容、方塊或標註表達資訊層級與版面，通常先降低視覺細節，也可以串接成互動原型。
• Mockup（視覺稿）：呈現色彩、字體、圖片與間距，常以靜態畫面討論外觀。
• 原型（Prototype）：模擬指定流程、狀態或互動，可以從低擬真到接近成品；未實作的分支不會因為畫面可點擊就自動被驗證。 延伸可參考Wireframe 線框圖設計入門。

可以把線框圖想成討論空間配置的平面圖、Mockup 想成呈現外觀的渲染圖、原型想成用來試走指定路徑的模型。這個比喻說明各自重點，不代表每個專案都必須交三份獨立產物；同一份設計檔也能逐步加入視覺與互動。

改動成本取決於已投入的細節、共用元件、相依系統與驗證工作。方向不明時先做較輕量的模型，通常較容易調整；已有設計系統時，高擬真元件也可能很快。不要把「高擬真」直接等同於每改一個像素都會增加開發工時。

為什麼原型適合放在開發之前？從電商結帳流程看代價

是否先做原型，要看尚未解決的風險。新流程、複雜表單或跨角色操作，適合先用原型討論；成熟元件的小幅修改，也可能直接在可回復的實作環境中驗證。重點是有沒有測到關鍵假設。

以電商結帳為例，除了成功購買的快樂路徑（happy path），還有返回修改、折扣碼無效、離島運費、付款失敗與庫存不足等分支。靜態稿也能逐張畫出這些情境；互動原型則能進一步串接路徑，觀察使用者如何理解回饋與選擇下一步。

若原型有模擬返回、錯誤與完成狀態，就能觀察資料保留方式、錯誤說明與訂單資訊是否清楚。鍵盤遮擋需要合適的實機原型或實作，庫存競爭與金流結果需要系統測試；單純連接畫面的原型不會自動揭露這些問題。

原型的價值，是在正式實作前把部分假設變成可討論、可測試的操作。它可能減少後續返工，但節省多少取決於問題類型、原型成本與系統架構，不能用固定幾天換幾週來估算所有專案。

這些問題越早暴露，後面越不會翻案；實務上，光是這一步就經常能攔下「上線前大改」的危機。

涉及多步驟流程、表單、金流或會員的專案，值得先列出高風險分支，再決定用原型、技術驗證或兩者搭配。成功與例外路徑的比例沒有通用數字；應依真實任務與失敗後果安排測試。

原型精度的關鍵在對的階段用對的顆粒，越細不等於越好

原型有擬真度（fidelity）的高低之分，而新手最常犯的錯，是一進場就做高擬真，把每個圓角、每個漸層、每張圖都塞好塞滿，結果客戶回饋一來，發現要改的是整個流程結構，前面的視覺功夫全部白費。

判斷要用哪種精度，關鍵是「你現在要驗證的是什麼」。

低擬真原型（Low-Fidelity）

紙筆手繪、或用灰階方塊快速拉出來的版本，重點是流程與資訊架構，不在美觀。它適合用在專案最前期，跟團隊或客戶對齊「使用者會走哪些路徑、每個畫面大致放什麼」。這個階段改方向最便宜，一張紙擦掉重畫就好，所以重點是速度，不是精緻度。

中擬真原型（Mid-Fidelity）

在 Figma 製作原型時，可以先以佔位圖片測試版面，再換成正式素材。使用外掛或免費圖庫前仍須核對素材授權，並用接近正式內容的長寬與文字長度測試。 延伸可參考插入免費圖片的外掛。

中擬真版本通常已有較接近使用情境的版面比例、間距與字級，配色或圖片仍可簡化。它適合討論欄位順序、導覽分類與單頁資訊層級；實際投入時間依專案問題而定。

高擬真原型（High-Fidelity）

高擬真版本在選定面向上接近成品，可用來測試視覺理解、動效或較細的互動，也適合交接。視覺與功能擬真度不一定同步；一份很像成品的原型，仍可能只有少量可操作分支。

一種常見節奏是先用簡化模型對齊方向，再增加測試所需細節。但如果要驗證品牌辨識、動效或裝置操作，也可能較早使用高擬真原型。每次增加細節前，先確認它能回答哪個尚未解決的問題。

升高擬真度的依據是下一輪要驗證的問題，而不是假設流程從此不會改。記錄目前已確認、仍有疑問與尚未模擬的部分；新發現可能讓團隊回到較早的假設重新設計。

以報名錶單為例，可以先用簡化方塊討論個人與團體報名的分支，再放入真實欄位長度、必填說明與錯誤訊息，最後測試品牌視覺或送出回饋。這是其中一種推進方式；若已有成熟表單元件，也能直接從較完整的原型開始。 延伸可參考送出後的載入動畫。

互動原型與靜態畫面：依驗證問題選擇呈現方式

要驗證路徑是否可理解，可操作的原型通常比單張畫面更有幫助；要討論色彩、字級或內容層級，靜態稿也有用途。兩者回答不同問題，不能只用是否能點擊判斷價值。

流程與視覺都會影響操作。例如按鈕沒有回應會造成不確定，文字對比不足或標示不清也可能讓人找不到入口。應觀察具體任務的阻礙，不預先把配色、字體或流程排成固定的重要性順序。

互動原型適合把下列設計決策串起來檢查；靜態稿也可先標示這些狀態：

• 狀態轉換：預設、鍵盤焦點、選取、載入、成功與錯誤等適用狀態。
• 流程分支：成功、失敗、返回與空狀態，各自通往哪裡。
• 回饋時機：操作後如何告知處理中、完成或失敗，哪些時序是原型模擬。
• 跨頁一致性：相同操作在不同畫面是否遵循同一規則。

以註冊流程為例，先依實際帳號政策定義輸入規則，再決定何時驗證、錯誤如何說明、送出期間如何回饋，以及驗證訊息能否重新發送。靜態稿能標註這些決策，互動原型則讓團隊試走順序；真實驗證與安全控制仍由系統實作。

互動原型讓使用者實際選擇與操作，靜態稿則便於討論特定畫面的資訊與視覺。原型不必每個部分都精緻，但測試所需的內容、狀態與回饋必須足夠真實，才不會把模型的限制誤判成產品問題。

在專案尚未定案時，與其只把單一畫面修得非常精細，可先將核心流程做成可點擊原型，同時驗證版面、資訊層級與關鍵體驗元素。視覺細節與流程都重要，但越早發現導覽、欄位或操作邏輯問題，通常越容易在進入開發前調整。

互動原型還有一個常被低估的功用：它能讓團隊與利害關係人對著同一條流程溝通。靜態稿不容易回答「按下去會怎樣」「回到上一頁會保留什麼」；可點擊原型則能把對話從假設，轉成具體的操作回饋。靜態稿仍適合討論視覺與單頁資訊，互動原型適合驗證流程，兩者依討論目的搭配使用。

製作原型一定要守的五個設計要點，含一個很多人漏掉的錯誤路徑檢查

原型人人會做，但能不能在測試時撐得住真實操作，關鍵在細節。這五點是製作原型時值得逐條檢查的重點。

要點一：先把核心流程走通，再補邊緣情境

不要一開始就想把所有功能都做成可點。先鎖定一到兩條最重要的路徑（例如註冊、結帳、預約），把它們做到完整可走，再慢慢補次要功能。一個能從頭走到尾的核心流程，比十個半成品功能對測試有幫助得多。

要點二：每個互動元素都要有明確狀態

依元件用途定義需要的狀態，例如預設、鍵盤焦點、指標懸停、按下、停用或處理中。並非每個元件都需要所有狀態，但鍵盤使用者也要知道焦點在哪裡；不要只檢查滑鼠操作。 延伸可參考CTA 按鈕設計。

要點三：用網格與間距系統，不要憑感覺排

原型不是隨便擺一擺就好。使用一致的網格、欄位與間距，除了讓畫面整齊，更重要的是讓後續開發有一套可遵循的規格。Figma 的 Layout Grid 是製作原型時常用的基礎設定，相關操作可參考 Figma 網格系統教學。當原型的間距有明確系統，交接給工程師時就不必用肉眼猜測外距。同樣以網格為基礎的排法還有 便當盒版面配置，用大小不同的方塊組合內容，原型階段就能依欄位系統對齊。

要點四：手機版不能等到最終才想

從規劃核心流程時就考慮目標裝置、不同視窗寬度與輸入方式。可以採手機優先，也可以從主要使用情境開始；重要的是及早檢查窄螢幕、觸控與鍵盤操作，而不是最後才把桌面畫面縮小。 延伸可參考響應式網頁設計 RWD。

要點五，也是最容易被漏掉的：主動設計錯誤路徑

這是多數原型最薄弱的一塊。大家很會畫成功流程，對「出錯時怎麼辦」幾乎沒著墨。在原型裡刻意把這些情境做出來，並整理成下面這張檢查表，每次製作原型時逐項過一次：

• 表單填錯格式時，錯誤訊息出現在哪、寫什麼、什麼顏色。
• 網路斷線或載入失敗時，畫面顯示什麼、能不能重試。
• 權限不足或登入逾期時，使用者被引導去哪。
• 空狀態（沒有資料、沒有訂單紀錄）時，畫面長怎樣、要不要引導下一步。
• 庫存不足、名額已滿等商業邏輯邊界，畫面怎麼告知。

只有成功流程的原型容易漏掉例外情境。補上與任務相關的錯誤路徑，能讓團隊更完整地討論設計；這仍不等於已具備上線條件，還需要實作、無障礙、效能與業務邏輯驗證。 延伸可參考Landing Page 轉換率優化。

工具怎麼選？關鍵在團隊跟得上、交接到開發不斷層，功能最強未必最合適

原型工具百家爭鳴，但不建議照「功能最強」來選。工具是團隊溝通的媒介，選一個大家會用、開發看得懂、檔案好交接的工具，比選一個功能炫但僅有你會用的工具重要得多。

下面是幾款主流工具的特性比較，可依專案類型挑選適合的選項。

怎麼挑？如果團隊多人協作、要做一般網頁或 App 原型，可以先看 Figma；免費 Starter 方案的協作檔案、頁數、版本記錄與 Dev Mode 有限制，採用前要核對方案。需要大量客製動畫或想直接發佈網頁，可比較 Framer；物聯網、車載或需要裝置感測互動的 App，可測試 ProtoPie；充滿條件分支且需要完整規格文件的企業流程，則可評估 Axure。沒有任何一套工具對所有情境都是唯一答案。

選工具時也要讓開發者試用交接方式。以 Figma Dev Mode 為例，它提供設計檢視、變更比較、標註與程式碼片段等功能，目前完整 Dev Mode 需要付費方案及相應席次。這些功能協助讀取規格，仍不能取代實作時的架構決策與測試。

預算有限或剛起步的小團隊，可以先用 Figma 免費方案做一條核心流程；協作檔案、頁數、版本記錄與 Dev Mode 等限制，則要依當期方案核對。先確認原型能支持測試與交接，再評估是否付費。工具是手段，把原型做出來、拿到回饋，才是目的。

拿原型做小樣本、反覆測試

原型做好不是拿來自我欣賞的，是要拿去給人用的。Jakob Nielsen 在 Nielsen Norman Group 的經典文章中主張，用小樣本測試後修正，再進入下一輪，而不是把所有預算押在一次大型測試。「五位」不是所有研究的固定門檻；不同使用者群、任務風險與研究目的，所需樣本都會改變。

非正式的質性測試可以先從少量、同一使用者群的受測者開始，給他們幾個任務，安靜觀察操作，再依發現安排下一輪。重點不是把某個數字當成規則，而是有沒有真的觀察「真人在原型上會卡在哪」。

拿原型做測試時，有幾件事值得注意：

1. 先給任務與情境，不直接教操作步驟，觀察入口是否容易找到。
2. 盡量避免引導；如果為了繼續研究而提供協助，要記錄介入點，區分自行完成與受助後完成。
3. 記錄行為與說明，也追問視覺意見是否與辨識、可讀性或信任有關，不把所有美感回饋一律忽略。
4. 把觀察與原因假設分開；卡住可能與標示、流程、模型限制或使用情境有關，需要進一步確認。

整理發現時，同時看任務影響、發生情境、嚴重程度與修正成本。小樣本中只出現一次的阻礙，也可能涉及付款失敗或無障礙問題，不能只按多數票決定。純偏好意見可以與實際操作證據分開記錄，再安排下一輪驗證。

遠端測試可分為主持式與無主持式。主持式可以即時觀察、溝通與追問；無主持式則需要清楚的任務、停止條件與錄影或記錄方式。選擇時要考慮受測者裝置、招募、資料同意與研究問題，不能把所有遠端測試都視為無法當場追問。

原型測試能提早收集操作證據，協助決定哪些假設值得修改。它無法保證後續不會返工；原型未涵蓋的功能、真實資料與技術限制，仍需要其他驗證。

原型交接到開發：交付的標準是讓工程師不用猜

原型通過測試、準備進開發時，最常出問題的環節往往在交接這一步，原型本身反倒少有狀況。實務上常見的狀況是，設計師覺得「畫面都畫好了，工程師照著刻就好」，結果工程師收到檔案，滿頭問號：這個間距是多少？這個動畫多快？這個狀態什麼時候觸發？這些沒講清楚的細節，最終全靠工程師猜，猜錯了就是返工。

交接應讓設計決策、待確認事項與實作條件清楚可查，也保留設計和開發共同釐清問題的管道。原型與文件可包括：

• 適用狀態：說明預設、焦點、選取、停用、載入與錯誤等狀態及觸發條件。
• 尺寸與規則：間距、字級、容器與共用元件，包含哪些值可隨內容調整。
• 流程與分支：條件、返回、失敗與資料保留方式，標示未決事項。
• 響應式行為：提供代表性視窗與內容變化規則，不把兩張畫面當成所有寬度的規格。
• 動效與回饋：定義適用時長及減少動態效果的處理；載入完成依真實結果，不用固定假延遲冒充效能。
• 空狀態與邊界：無資料、權限不足、錯誤或長內容如何處理。

Dev Mode 的尺寸、屬性與程式碼片段可減少部分手工查找，但輸出仍需工程師依專案實作。狀態、資料與業務規則若沒有定義，工具不會自動補齊。交接時應一起核對已模擬與未模擬的部分。

交接前可以請設計與開發一起選一個畫面，僅根據原型和註解列出實作規則，再記錄缺少的資訊。這是補足文件的一種方法，可與檢查表、元件規格和實作預覽搭配。

讓原型與規格持續反映已同意的修改，同時保留版本、日期與變更記錄。已驗收的範圍不要無聲覆寫；開發途中增加的狀態或需求，也要說明影響並確認後續安排。

從零開始做一份原型的六步行動清單

講了這麼多觀念，最終給你一份可以照著走的行動清單。不管你是設計師、工程師，還是專案負責人，這六步都能幫你把一個模糊的需求，變成一份可測試、可交接的原型。

1. 界定問題：列出要驗證的使用者、任務與未知事項。
2. 選擇模型：依問題使用紙本、設計工具或程式，細節以足夠測試為準。
3. 建立核心路徑：串接代表性內容與操作，標明尚未模擬的範圍。
4. 補上關鍵分支：依風險加入錯誤、返回、焦點、載入或空狀態。
5. 測試與修正：招募符合情境的人，記錄行為與介入，依風險安排下一輪；小樣本測試的經典論述 可作研究設計的參考。
6. 整理交接：記錄狀態、響應式規則、未決事項與版本，和開發共同核對。

流程、視覺與技術驗證可以反覆進行，不必一律先低擬真再高擬真。若邊做原型邊開發，應標示哪些假設尚未驗證、哪些變動可回復，避免把示範效果當成正式規格。

先挑一條風險較高的使用者路徑，列出要回答的問題，再做足夠驗證的原型。觀察實際操作後，保留證據、修改設計並補做必要的系統測試，才能知道這份原型解決了什麼、還留下哪些不確定性。