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

設計稿再漂亮，也回答不了「使用者點下去之後會發生什麼事」這個問題。按返回鍵整張表單被清空、手機版那顆結帳按鈕被鍵盤整個蓋住、載入轉圈轉太久讓使用者以為當機就直接關掉，這類缺陷幾乎不會出現在靜態畫面上，它們僅在你真的用手去走一遍流程時才會現形。

UI 原型（UI Prototype）要解決的就是這件事。它把一張張不會動的畫面，串成「可以點、可以照著真實路徑走完」的互動版本，讓你在寫任何一行程式之前，先用手指驗證一次使用者的真實操作。換句話說，它跟 Wireframe（線框圖）最大的差別僅有一句話：線框圖回答「這個畫面要放什麼」，原型回答「使用者點下去之後會發生什麼事」。

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

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

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

• 線框圖（Wireframe）：低擬真、通常黑白、用方塊與線條標示每個區塊的位置與層級。它回答「這個畫面要放哪些元素、誰在上誰在下」。想深入線框圖的畫法與工具，可以看這篇 Wireframe 線框圖設計入門。
• Mockup（視覺擬真稿）：把線框圖加上真實的色彩、字體、圖片、間距，看起來幾乎跟成品一樣。它回答「做起來會長什麼樣」，但它還是不會動。
• 原型（Prototype）：在 Mockup 或線框圖之上加上互動邏輯，按鈕點了會跳頁、表單填錯會顯示錯誤訊息、流程可以從頭走到尾。它回答「使用者實際操作時會發生什麼事」。

換個方式想：線框圖是房子的平面圖，Mockup 是 3D 渲染圖，原型是你實際走進去開門、開燈、開水龍頭的樣品屋。三者在設計流程裡是接力關係，不是替代關係。把原型當成線框圖的高階版本，或把 Mockup 當成原型，都是常見的誤解，會讓你在跟客戶、跟工程師溝通時雞同鴨講。

項目	線框圖 Wireframe	Mockup 視覺稿	原型 Prototype
主要問題	放什麼、怎麼排	看起來如何	用起來如何
擬真度	低（黑白方塊）	高（真實視覺）	視階段而定
互動性	無	無	有，可點擊走流程
主要用途	確認結構與資訊層級	確認視覺風格	驗證流程與操作體驗
常見產出	紙筆、灰階方塊	Figma、Sketch 視覺稿	Figma、Framer、ProtoPie、Axure

這三者的接力順序也決定了它們各自的修改成本。越靠前端、擬真度越低的產出，改動越便宜；越靠後端、越接近成品的產出，改動越貴。正因如此，建議團隊：在線框圖階段盡量吵、盡量改方向，等進到高擬真原型就要收斂，因為這時候每改一個像素，後面都會牽動開發工時。把爭論留在最便宜的階段，是原型流程裡最基本的紀律。

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

很多人覺得「畫面都設計好了，直接刻程式不就好了，幹嘛多花時間做原型？」這個念頭很常見，但實務上多半要踩過幾次坑，才會真正理解原型為什麼不能省。

以保健食品電商的結帳流程為例，這類專案最能看出僅畫快樂路徑（happy path）的代價。所謂快樂路徑，就是「使用者乖乖填完資料、乖乖結帳成功」的那條線。設計稿通常僅畫這條線，因為它最漂亮、最順。但真實世界長怎樣？使用者填到一半切去查折扣碼、回來發現表單空了；運費算到一半發現離島要分開計價；信用卡刷失敗要回到哪一步；庫存僅剩最終一件、兩個人同時結帳怎麼辦。這些分支，靜態稿一個都不會告訴你。

把結帳流程做成可以點的原型，自己用手從頭走一遍，往往會立刻踩到幾個問題：折價券輸入框被鍵盤擋住、回到上一步時填過的資料全部清空、結帳成功頁沒有訂單編號讓使用者無法查詢。這些問題如果在開發後才發現，改的是已經寫好的程式碼與串好的金流邏輯；實際成本差距依架構而異，但通常比調整原型高得多。

這就是原型最核心的價值：把「在使用者真實操作下才會暴露的問題」，提前到改動成本最低的階段。設計稿改一行，可能十分鐘；程式碼改一個流程，可能是三天加上重新測試。原型的成本是幾小時到幾天，它攔下的是幾週的返工。這筆帳，怎麼算都划算。

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

所以如果團隊問到「能不能跳過原型直接開發」，答案基本上是：流量小、頁面少、流程單純的活動頁可以；但凡牽涉多步驟流程、表單、金流、會員系統，原型不是選配，是地基。快樂路徑僅佔真實使用的一半，另一半的分支與例外，才是決定產品會不會翻車的地方。原型存在的意義，就是把這另一半提前搬到檯面上檢驗。

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

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

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

低擬真原型（Low-Fidelity）

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

中擬真原型（Mid-Fidelity）

在 Figma 製作中擬真原型時，可先用插入免費圖片的外掛填滿圖框，之後再替換成正式素材。

開始有真實的版面比例、間距、字級層級，但配色與圖片可能還是佔位素材。它適合用來驗證單一畫面的易用性，例如「這個報名表單欄位順序合不合理」「導覽列分類清不清楚」。這也是多數專案花最多時間的階段。

高擬真原型（High-Fidelity）

視覺接近最終成品，互動也盡量擬真，包含轉場動畫、微互動、錯誤狀態。它適合用在開發交接前的最終驗證，或拿去做接近真實情境的使用者測試。這個階段成本最高，也最不適合拿來做大方向的調整。

擬真度	適合驗證	常見產出	改動成本
低擬真	流程架構、資訊層級	紙筆、灰階方塊	極低
中擬真	版面易用性、欄位邏輯	Figma 灰階排版	中
高擬真	視覺細節、微互動、開發交接	Figma 或 Framer 完整互動	高

理想的推進節奏是：低擬真對齊方向、中擬真打磨流程、高擬真做最終驗證與交接。把高擬真留到最終，原因很單純：它太貴了，重要性從來不是問題，問題在於太早做會把你綁死在細節裡，反而失去調整大方向的彈性。記得一件事：原型是要被推翻的，越早被推翻、成本越低。所以前期請刻意讓它「醜一點、糙一點」，你反而比較捨得砍掉重練。

那麼，什麼時候該從低擬真升到中擬真、再從中擬真升到高擬真？判斷時用的標準是「共識與細節」。低擬真要解決的是大家對流程有沒有共識，這個共識一旦成形，再往下爭論黑白方塊就沒有意義，這時就該進入中擬真，把版面比例與欄位邏輯落實。中擬真要解決的是單一畫面用起來順不順，當主要畫面的易用性都驗證過、流程也走得通，就進入高擬真，把視覺、動效、狀態細節補到位。每往上一級，都應該建立在「已經確定不會再大改」的前提上。如果你還在為流程順序吵架，卻已經在做高擬真，那就是把資源花在錯的地方。

用一個報名表單來走一遍這三級的差異，你會更有感覺。低擬真階段，僅用灰階方塊標出「標題、姓名欄、電話欄、送出鈕」的位置，確認欄位順序與流程分支（例如要不要分個人報名與團體報名兩條路）。進到中擬真，再把欄位的實際比例、字級、必填標示、錯誤訊息位置都排出來，開始驗證單一畫面的易用性。最終到高擬真，才把品牌色、字體、按鈕互動、送出後的載入動畫都補上，讓它看起來跟成品幾乎一樣。同樣一個表單，三個階段回答的問題完全不同，這也是為什麼精度要分級，而不是一開始就衝高擬真。

互動原型 vs 靜態畫面：為什麼點得到比看起來漂亮更能挖出問題

這一點跟很多設計師看法不同。不少人把心力全押在畫面好不好看，但實務上，一個「長得普通但能完整點完」的原型，比一個「美到得獎但不能動」的 Mockup 有價值得多，尤其是在驗證階段。

原因很實際：使用者的痛點大多藏在「互動」裡，鮮少藏在「視覺」裡。一個按鈕顏色不對，使用者頂多覺得怪，但還是按得下去；可是一旦按鈕點了沒反應、或跳到一個不知所措的頁面，使用者會直接迷路、放棄。流程類的問題（找不到下一步、回不去上一步、狀態不清楚）對轉換率的殺傷力，遠大於配色與字體。

互動原型能逼出靜態稿挖不到的問題，至少包括這幾類：

• 狀態轉換：點擊、懸停、選取、停用、載入中、錯誤，這些狀態在靜態稿裡僅能用想像的，互動原型會逼你一個一個定義清楚。
• 流程分支：成功路徑、失敗路徑、返回路徑、空狀態（沒資料時長怎樣），走一遍才知道哪條路斷了。
• 回饋時機：按下按鈕後多久要有反應、載入要顯示什麼、成功要怎麼告知，這些微小的時間差會直接決定體驗成敗。
• 跨頁面一致性：同一個操作在不同頁面的行為有沒有一致，靜態稿很難看出來，互動原型走一遍就破功。

舉一個具體的例子。假設你設計一個會員註冊流程，靜態稿可能畫得很好看：輸入框、送出按鈕、成功頁。但把它做成互動原型、自己點一遍，你會立刻被逼著回答一連串問題：密碼少於八碼時要即時提示還是送出才報錯？信箱已被註冊時，要引導登入還是直接顯示錯誤？送出後伺服器回應的那兩秒，畫面要顯示什麼？驗證碼倒數完可以重新發送嗎？這些問題在靜態稿裡都不存在，但它們每一個都會決定使用者最終有沒有註冊成功。互動原型就是把這些「原本會被略過的決策點」，一個一個逼到你面前。

換句話說，靜態稿驗證的是「視覺感受」，互動原型驗證的是「行為預期」。前者靠眼睛，後者靠手。而真實使用者在真實情境裡，是用手的。所以哪怕你的互動原型視覺很糙，若流程能走通、狀態能切換，它帶回來的洞察就比任何精美的 Mockup 都具體。

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

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

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

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

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

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

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

一個按鈕至少要有四個狀態：預設、懸停、點擊中、停用。很多人僅畫預設狀態，結果測試時使用者問「我到底點到了沒」，你才發現缺了回饋狀態。這件事跟 CTA 按鈕設計 的邏輯是相通的：按鈕不僅是視覺元素，它是一段對話，每個狀態都是對使用者的一次回應。

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

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

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

很多人習慣先做桌面版，最終再「擠」出手機版，結果發現桌面上橫排的東西在手機上塞不下、流程要整個重設計。實務上的做法是，從中擬真階段就同時想手機版，甚至直接手機優先（mobile-first）去設計核心流程。響應式不是事後補丁，是從原型階段就要內建的觀念，這部分觀念可以對照這篇 響應式網頁設計 RWD。

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

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

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

錯誤情境	原型該呈現的內容	沒做好的代價
表單格式錯誤	欄位旁明確錯誤訊息、紅色邊框、聚焦回該欄位	使用者不知道哪裡錯，直接放棄填寫
網路斷線或逾時	載入失敗提示、重試按鈕、保留已輸入內容	資料遺失，使用者要全部重填
權限不足	引導登入或申請權限的明確路徑	使用者卡在錯誤頁，找不到出路
空狀態（無資料）	說明文字、引導新增或探索的行動按鈕	畫面一片空白，使用者誤以為壞掉
庫存或名額已滿	明確告知、提供替代方案或通知選項	使用者撲空，轉往其他服務

這些錯誤路徑處理得好不好，往往是專業原型與業餘原型的分水嶺。一個僅會走快樂路徑的原型，會給人「流程很順」的錯覺；一個把錯誤路徑都想清楚的原型，才是真的能上線的設計。如果你的原型最終是要導向轉換，這些細節跟 Landing Page 轉換率優化 講的原則一樣：每一個讓使用者猶豫或卡住的瞬間，都是流失的破口。

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

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

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

工具	最擅長的場景	互動能力	協作與交接
Figma	多數網頁與 App 原型的主力，團隊協作首選	中高，智能動畫與條件式互動夠用	極強，多人即時、Dev Mode 交接成熟
Framer	需要接近上線質感、或想直接發佈成網站的進階互動	高，動畫與元件邏輯細緻	中高，可發佈真實網址，學習曲線較陡
ProtoPie	手機感測器、相機、震動、多裝置同步等硬體級互動	極高，能模擬真實裝置能力	中，適合高擬真驗證，交接要單獨處理
Axure RP	條件邏輯、變數、動態面板，文件需求重的企業或 B2B 流程	高，邏輯表達能力強	中，規格輸出完整，介面較傳統
Sketch	macOS 單機老手、搭配 Cloud 做基本協作	中，需搭配外掛補互動	中，生態系成熟但跨平台受限

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

還有一個常被低估的點：選工具時要連「開發端會用什麼看」一起考慮。設計師覺得好用的工具，工程師未必看得懂。Figma 之所以成為主流，很大一部分原因是它的 Dev Mode 讓工程師能直接量測間距、抓取變數、複製程式碼片段，把「設計到開發」這段最容易斷層的交接補起來。比起追求工具的極限功能，更要緊的是確保它能在你團隊的整條鏈路上跑得通。

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

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

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

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

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

1. 給任務，別給操作步驟。說「請幫我完成一次結帳」，千萬別說「請點右上角的購物車，再點結帳」。你給了步驟，就測不到他們會不會找到入口。
2. 閉嘴，讓他們邊做邊說。最忌諱的是測試者一猶豫，你就忍不住提示「你試試看點這裡」。你一提示，這次測試就廢了。讓他們說出心裡的困惑，那才是你要的資料。
3. 記錄卡點，不記錄美感意見。使用者說「這個顏色我不喜歡」是次要的；使用者在某一步停了十秒、或點錯地方三次，才是你要修的真問題。
4. 區分真的不會用與需要提示才會用。前者是設計問題，後者可能是教育或文案問題，修法完全不同。

測試完不是把問題全部改掉就好，你要先分類。實務上習慣把測試發現分成三類：第一類是「多數人都卡住」，這種不用猶豫，一定要改，而且通常是流程或資訊架構問題；第二類是「少數人卡一下但自己想通」，這種要看修改成本，改一個文案就能解決就改，要動結構就先記下來觀察；第三類是「個人偏好型的意見」，例如顏色、字體喜好，這種聽聽就好，別為了討好每個人把設計改得四不像。資源有限，把力氣花在第一類，投資報酬率最高。

如果找不到實體空間、或受訪者分散在不同城市，遠端測試也是可行的替代方案。現在不少原型工具都支援把可點擊原型發佈成網址，讓受訪者在自己家裡、用自己的裝置操作，再搭配螢幕錄影或測試平台的點擊熱圖，你一樣能拿到「他在哪一步卡住、點了哪些不該點的地方」這類關鍵資料。遠端測試損失的是當下追問的即時性，換來的卻是更容易招募到真實目標使用者，而且能在他們日常的環境與裝置上觀察，有時反而比實驗室更貼近真實。對預算與時間有限的小團隊，這條路線非常實用，重點是把任務說明寫清楚，讓受訪者在沒有人帶領的情況下也知道要做什麼。

原型測試最大的價值，是它讓你在還沒花錢開發之前就聽到使用者的真實聲音。這種回饋越早拿到，後面越不會翻案；實務上，光是這一步就經常能攔下「上線前大改」的危機。一句話：原型測試不是在花時間，是在買保險。

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

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

好的交接，目標僅有一個：讓工程師在實作時，幾乎不需要回頭問設計師。要做到這件事，原型本身與交接文件至少要涵蓋：

• 所有互動狀態：每個元素在預設、懸停、點擊、停用、載入、錯誤時各長怎樣，不能僅交一個預設態。
• 間距與字級的數值：用網格系統標示，別讓工程師僅能靠目測。
• 流程圖與分支：什麼條件走 A 路徑、什麼條件走 B 路徑、出錯時去哪裡，用流程圖講清楚，不要僅給畫面。
• 裝置與斷點：至少給桌面與手機兩個版本，標明斷點數值，讓響應式實作有依據。
• 動效的時機與時長：載入要顯示多久、按鈕回饋多快、轉場多長，給一個參考值，不要讓工程師自己編。
• 空狀態與邊界情境：沒資料、載入失敗、權限不足時的畫面，這些常常在開發後才被想到，結果要回頭補設計。

工具上，Figma 的 Dev Mode 已經把間距、顏色、字級、甚至部分程式碼片段都自動產出，大幅降低手工標示的負擔。但工具再強，也救不了「設計師自己沒想清楚狀態」這件事。所以交接的品質，其實在你做原型時就決定了：你在原型階段把錯誤路徑、狀態、邊界都想清楚了，交接自然輕鬆；你在原型階段僅畫了快樂路徑，交接就會變成一場無止盡的問答馬拉松。

把交接當成「原型的最終一哩路」來經營，別把它看成原型結束後的附加工作，整個開發節奏會順很多。一個小技巧：交接前自己扮演一次工程師，僅看原型與註解、不靠記憶，試著把其中一個畫面「規格化」寫出來，你立刻會發現哪些地方交代不清。這個自己審自己的動作，往往比任何交接檢查表都有效。

交接文件建議維持一個「活的」狀態，別讓它交出去就凍結。開發過程一定會冒出新的狀態需求、新的邊界情境，設計師要持續把這些更新進原型與註解，讓文件跟實作同步。很多團隊的交接文件在第一天就過時了，因為沒有人維護，結果工程師寫到一半發現規格對不上，又回到口頭問答的老路。把交接當成一個會演進的產物來經營，別把它看成一次性的交付，這個觀念一旦內化，設計與開發的協作品質會明顯提升，返工的次數也會跟著下降。

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

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

1. 釐清要驗證什麼。動手前先問自己：這份原型要回答什麼問題？是驗證流程順不順、還是驗證視覺風格？答案不同，擬真度與重心就不同。沒想清楚就動手，做越多浪費越多。
2. 畫紙本草圖對齊方向。用紙筆把核心流程的每個畫面快速畫一遍，跟團隊或客戶對齊。這個階段醜沒關係，重點是大家對流程有沒有共識。
3. 用中擬真把核心流程做成可點擊。挑一到兩條最重要的路徑，把它們做到能從頭走到尾，先不管邊緣功能。這是你接下來測試的主體。
4. 補上互動狀態與錯誤路徑。把每個元素的狀態補齊，並主動設計出錯時的畫面。這一步是業餘原型跟專業原型的分水嶺。
5. 找少量目標使用者測試、觀察、修正。給任務不給步驟，安靜觀察他們卡在哪，修正後再安排下一輪；樣本數依使用者群與任務風險調整，Nielsen Norman Group 對此有 小樣本測試的經典論述。
6. 拉高擬真、整理交接文件、進開發。確認流程沒問題後，再把視覺細節、動效、響應式斷點補到位，連同狀態清單與流程圖一起交給開發，讓工程師不用猜。

這六步的核心精神僅有一句話：先求走得通，再求走得順，最終才求走得漂亮。順序顛倒，你就會一直在改不對的東西。還有一個容易踩的坑：原型做到一半就被拉去開發。千萬記得，原型在還沒經過真實測試之前，它對流程的假設都還沒被驗證，這時候進開發，等於把未驗證的假設直接變成產品，風險全往後端丟。守住「測試通過才升擬真、交接完整才進開發」這條線，原型的價值才會真正兌現。

原型設計本質上來說就是把「使用者會怎麼用」這件最容易靠想像、也最容易想錯的事，變成一件可以提前用手驗證的事。它不是多餘的工序，本質上是一把把開發風險與返工成本往前搬的槓桿。你願意在前端多花三天做原型，往往就省下後端三週的改程式。現在，就挑一個你手邊最卡流程的專案，用紙筆把核心流程畫一遍，然後把它變成可點擊的原型，親手走一次。你會驚訝於自己能多快發現那些躲在靜態稿裡、等著上線才爆炸的問題。