UI Prototype 原型設計全解析：與 Wireframe 的差異、設計要點到實用工具推薦

原型要解決的問題

Prototype 中文是「原型」，指設計初期可被點擊、可被操作的網頁版本模型，用來在寫程式之前驗證互動行為與使用者流程是否成立。它的價值不在畫面精不精緻，而在你有沒有在對的階段放進對的細節。根據 Nielsen Norman Group 對軟體缺陷修復成本的研究，問題越晚被發現，修復代價越高，在設計階段攔截的成本通常是開發後修復的十分之一到百分之一。這正是 Prototype 與 Wireframe、Mockup 最大的不同：後兩者回答「長怎樣」「美不美」，原型要回答的是「用起來順不順」。想釐清整體脈絡，可以先從 UI 與 UX 設計差異解析 建立基本盤，再對照 網頁設計從零到一完整指南 看原型在流程裡的位置。

很多人把 Wireframe 線框圖設計入門、Mockup 與 Prototype 想成一條單向的進化線：草圖畫細一點、配色補上去，就自動變成原型。這個理解會害你把時間燒在還會大改的地方。原型真正在處理的是三條本來會打架的線：需求的不確定性、溝通的失真、以及修改成本的時間軸。專案剛起頭時，沒有人能把「使用者到底會怎麼用」一次想清楚，連客戶自己也講不清楚，原型用一個可以點的版本把抽象想法具體化，讓大家看著同一個東西討論。文字與口頭描述經過不同人解讀會走樣，PM 寫的需求文件到工程師手上，往往已經跟設計師腦中的畫面差了一截，原型作為共同的參照物，直接消除這層落差。至於修改成本的時間軸，就是前面那句統計的本質：原型的工作，是在最便宜的階段把問題攔下來。

Prototype 的中文意思與定位

Prototype 中文叫「原型」，它是設計初期、可被操作的版本模型，用來展示網站的結構佈局與互動行為，讓你在還沒寫程式之前就能點按、切換頁面、感受真實使用流程。它不是最終成品，但會盡量接近最終產品的操作感受；和「畫面草圖」最大的差別在於：原型是可互動、可點擊的。把它拆開來看，其實是「結構」加「互動」兩件事綁在一起。畫面會告訴你按鈕在哪、選單怎麼排，互動則演示按下去會發生什麼事，包括頁面跳轉、彈窗跳出、表單送出、動態按鈕設計 的回饋。對開發來說，原型更是一種溝通介面：工程師看著演示模型，比看一份寫滿文字的需求文件更容易理解功能要怎麼跑。

接案工作上的實務習慣是：就算只是三頁的形象網站，也會先花一個下午把首頁到聯絡頁的點擊流程串起來給客戶看。原因很實際，口頭講「選單會固定在頂端」客戶想像的是一回事，讓他實際點一次才知道會不會擋到內容。這種回饋越早拿到，後面越不會翻案。如果你還在摸索整體設計流程，網頁設計必備的關鍵元素 和 網頁設計自學路線圖 能幫你把原型放進正確的位置。

這裡要拆解一個常見誤解：原型不是「更精緻的 Mockup」，也不是「還沒寫完的網站」。它是一個獨立的設計產物，目的跟 Mockup、跟成品都不同。Mockup 解決的是「看起來對不對」這個視覺問題，成品解決的是「能不能跑、能不能被搜尋引擎收錄、能不能成交」這些工程與商業問題，原型解決的則是「用起來合不合理」這個體驗問題。把這三者的任務分清楚，你才不會在該做原型的時候拼命調像素，也不會在該交給開發的時候還在糾結動畫曲線。視覺端的深度，可以另外從 排版設計與字體行距技巧 與 色彩學與配色技巧 補強，不必全部塞進原型這個階段。

開發前做原型，省下的是事後翻案的代價

做 Prototype 最核心的價值，是在開發前用低成本驗證設計想法、提早發現流程漏洞，把昂貴的修改留在設計階段，避免事後丟回給工程師重做。換句話說，它是一份花小錢買保險的動作。同樣一個流程卡關，在 Wireframe 階段改一條線就解決，到了開發階段可能要動到後端邏輯、資料庫欄位、甚至已經上線的頁面。原型就是在中間攔截這些問題的工具。它還能把抽象的需求變具體：你跟客戶說「首頁會有一個報名區塊」，他腦中的畫面跟你做的可能差了十萬八千里，但讓他點一次原型，歧異當場就會浮現。

好處	具體情境	誰受惠
提早發現問題	流程卡關、互動不合理，在寫程式前就抓到	設計師、開發
讓協作成員快速理解	可點擊的演示比口頭或靜態圖更不容易誤會	客戶、PM、工程師
加速開發流程	看著原型實作，比看文件猜需求快	開發人員
可做使用者測試	上線前就能收集真實回饋並調整方向	整個產品團隊

不是每個專案都非做原型不可。如果你做的是極簡的單頁靜態介紹、版面就是一張圖加幾行字，做原型反而拖慢節奏。但只要牽涉到多人協作、有互動流程、或要跟客戶來回確認，原型幾乎都是值得的。接案尤其建議做，因為合約裡最容易起爭議的，就是「我以為會長那樣」這種事，原型就是你最好的防護。需要更多背景，可參考 免費 UIUX 自學資源 與 作品集網站設計指南。

把這些好處翻成可觀察的判斷訊號

上述好處聽起來都很合理，但實際判斷一個專案「值不值得做原型」時，需要把它們翻成可觀察的訊號，才不會流於口號。第一個訊號是流程的分支數量：當使用者從進站到完成任務，中間出現「如果 A 就走這條、如果 B 就走那條」的多重分支，分支越多，越需要原型把每條路徑走一遍，否則一定會有人卡在沒想到的死角。第二個訊號是跨角色的認知落差：當 PM、設計師、工程師、客戶四方對「這個功能到底要怎麼跑」有不同版本時，原型是唯一能讓四方閉嘴、指著同一個東西討論的工具。第三個訊號是改動的牽連範圍：一個改動如果只動到一個元件，沒有原型也能處理；但如果會牽動選單結構、權限邏輯、資料流，原型能先把牽連範圍摸清楚。第四個訊號是上線後的修正成本：越是不能輕易改的產品（例如已經對外發包、已經上廣告、已經簽合約），越要在開發前用原型把風險買掉。

把這四個訊號想成一張檢查表，每個訊號命中就加一分。零到一分代表原型可有可無，把時間省下來；兩到三分代表值得做一個低保真流程圖等級的原型；四分全中代表這個專案不做原型幾乎一定會出事，建議直接排進時程。這個評分不是科學定律，而是給你一個把直覺講清楚的方式，方便跟團隊或客戶解釋「為什麼我要花三天做原型」。要進一步了解整體設計判斷框架，網頁設計常見錯誤 整理了不少讓你少走冤枉路的經驗。

Prototype vs Wireframe vs Mockup：三者到底差在哪

Wireframe 管版面骨架、Mockup 管視覺外觀、Prototype 管互動行為，三者回答的是不同問題：長怎樣、美不美、能不能用。它們各自站在設計流程的不同階段，並沒有誰取代誰的進化關係。

把這三個名詞攤開比，會發現它們其實是用「保真度」這個維度切開的。Wireframe 是低保真，黑白灰框、專注排版，回答「版面怎麼排」；Mockup 是視覺高保真，有配色字體但靜態，回答「成品看起來美不美」；Prototype 是行為高保真，可點可互動、串接頁面流程，回答「用起來順不順」。一個管骨架、一個管皮膚、一個管動作，硬要說誰比誰高級，就像問心臟、皮膚、肌肉哪個比較重要一樣沒意義。關於骨架的細節，網頁版面設計攻略 和 網頁排版設計範例 有更完整的討論。

項目	Wireframe 線框圖	Mockup 模擬圖	Prototype 原型
主要回答	版面怎麼排	成品看起來美不美	用起來順不順
保真度	低保真	視覺高保真	行為高保真
是否可互動	否（靜態骨架）	否（靜態畫面）	是（可點擊串接）
包含視覺細節	無（黑白灰框）	有（配色字體）	視階段而定
設計階段	前期溝通	視覺定案	流程驗證與測試

標準的流程大致長這樣：前期溝通 → Wireframe → Mockup → Prototype → 測試 → 上線。但這不是死規矩。你完全可以先做一個低保真的可點擊原型來驗證流程，等流程跑通了再回頭補視覺；也可以先用 Mockup 跟客戶敲定視覺風格，再把它串成 Prototype 測互動。順序看你要先回答哪個問題。如果你對視覺這端有興趣，排版設計與字體行距技巧、色彩學與配色技巧、中文字體設計推薦 都能往下挖。

三者可以合併，也可以拆開：實務上的混合用法

真實專案裡，三者很少涇渭分明地排成一條線，更多時候是混著用。常見的混合用法有三種。第一種是「Wireframe 直接接互動」：把 Wireframe 的灰框畫面之間加上點擊跳轉，讓它變成一個低保真的可點擊原型，跳過 Mockup 這一步。這招適合流程複雜、視覺風格還沒定、需要盡快驗證動線的專案，例如後台系統或工具型產品，因為這類產品用得好不好跟配色幾乎無關。第二種是「Mockup 加局部互動」：在已經定好視覺的 Mockup 上，只把關鍵按鈕、選單串上互動，其他地方維持靜態。這招適合視覺先行、需要對客戶做高質感提案的專案，例如品牌官網或活動頁。第三種是「三者並行」：Wireframe 跑流程、Mockup 跑視覺、Prototype 跑動效，三條線同步推進，最後在開發前匯流。這招適合時間夠、團隊夠大的中大型專案。

選哪種混合用法，關鍵在於你「現在最急著回答哪個問題」。流程還沒通就用第一種，視覺還沒拍板就用第二種，兩條線都要顧就用第三種。無論選哪種，都記得不要把三者的任務糊在一起：不要在 Wireframe 階段調漸層，也不要在 Prototype 階段才回頭大改資訊架構，那會把前一個階段的成果全部打掉重練。流程與動線的延伸閱讀，網頁版面設計攻略 提供了從骨架到互動的完整脈絡。

低保真 vs 高保真原型：什麼時候做到什麼程度

原型該做到多細，取決於你要驗證什麼：驗證流程與架構用低保真就夠，要向客戶提案或做使用者測試才需要高保真。過早做高保真，會把時間燒在還會大改的地方。

這是新手最容易踩的坑。一接手專案就打開 Figma 開始調配色、選字體、把按鈕做到有陰影有漸層，結果流程本身還沒跑通：首頁到底要不要有登入、報名流程是三步還是五步、結帳要不要強制註冊帳號，這些根本問題都還沒定案。等客戶一句「流程改成這樣好了」，你做了一個禮拜的視覺全部白費。實務上的教訓是：流程沒定案前，原型一律低保真。

面向	低保真原型	高保真原型
呈現形式	紙本、快速框線、灰階	接近最終視覺與互動
主要用途	驗證資訊架構與使用者流程	提案、測試細節互動、與開發對接
製作速度	快，幾小時到一天	慢，可能要好幾天
改動成本	低，改一條線就行	高，動一處牽一髮
適用階段	概念驗證、流程探索	接近定案、交付開發

選擇的原則很單純：越早期的驗證越用低保真，越接近定案越拉高保真度。判斷公式只有一句：這個細節「現在」會影響決策嗎？會才做進原型，否則就是提早把時間燒在還會大改的地方。舉例來說，你還在確認報名流程是三步還是五步時，按鈕要不要有微互動根本不重要；但等到流程定案、準備交給開發時，滑塊互動設計、英文字體挑選、CTA 行動呼籲按鈕設計 這些細節就值得做到位，因為它們這時候才會影響「使用者用起來的感受」這個決策。

換個角度想，保真度更像一個旋鈕，可以一格一格轉，不一定要整批開或整批關。你可以讓視覺是低保真、互動是高保真（灰階畫面但點擊流程完整），也可以讓視覺是高保真、互動是低保真（漂亮畫面但只有幾個按鈕能點）。關鍵是讓旋鈕對準你「現在要回答的問題」。MVP（最小可行性產品）又是另一個層級了，它是真的能跑、能上線給真實使用者用的版本，不屬於原型這個範疇，別把它們混為一談。

紙本、灰框、高保真：三個保真度層級的操作差異

把保真度再細分一層，其實可以分成三個操作層級：紙本（paper）、灰框（graybox）、高保真（high-fidelity）。每一層的工具、速度、適合回答的問題都不同，搞清楚差異才不會用錯層級做錯事。

層級	工具	製作時間	適合回答的問題	常見誤用
紙本原型	紙、筆、便利貼	幾十分鐘	動線大方向、資訊階層、頁面有沒有多餘	拿去對客戶做正式提案
灰框原型	Figma 框線、Balsamiq	幾小時到一天	流程是否走通、表單欄位順序、分支邏輯	花時間調字級與配色
高保真原型	Figma 互動、Protopie	數天	微互動手感、轉場節奏、與開發對接規格	在流程還沒定案時就上

紙本原型最常被低估，也最常被誤用。它的價值在於「改動成本接近零」：畫錯了劃掉重畫就好，沒有任何心理負擔，這讓你願意一次畫五六個版本互相比較，而這種大量試錯正是早期發想最需要的。它的限制也很明顯：紙本是平面的、不能真的點，所以不適合驗證任何牽涉手勢、動畫時機、滾動行為的問題；拿紙本去做正式的客戶提案也不恰當，因為客戶的注意力會被「這畫得好醜」分散，反而忽略你要討論的動線。正確用法是把紙本當成你跟自己、或跟設計夥伴之間的快速溝通工具，確認方向後立刻數位化。

灰框原型是大多數專案的主力。它把紙本的動線搬進數位工具，加上可點擊的跳轉，讓你能真實走一遍流程。這一層最重要的是維持視覺的「無聊」：故意用灰階、用佔位文字、用統一的方框，避免任何人對視覺產生意見，把討論強制鎖在流程與結構上。一旦你忍不住在灰框階段幫按鈕加了品牌色，就等於給了客戶一個可以批評視覺的把柄，焦點立刻會從「流程對不對」被拉到「這個藍太深了」。灰框的目標是讓流程先站穩，視覺留到下一層。

高保真原型是流程定案後的收尾動作。它把灰框加上視覺、加上微互動、加上轉場時序，目的是回答「最後用起來的手感對不對」，以及把這份手感轉成開發能照做的規格。這一層最忌諱的是「為了精緻而精緻」：每個按鈕都做 hover 動畫、每個轉場都調 easing 曲線，這些細節如果不在規格書裡交代清楚，開發會做不出來，等於白做。高保真原型的產出應該包含一份能交給工程師的互動說明，而不只是一個漂亮的 demo。微互動的細節，動態按鈕設計 與 Figma 載入動畫原型互動 有具體做法。

不同專案類型的原型策略

原型怎麼做，跟「你在做什麼樣的專案」高度相關。形象網站、電商、SaaS 工具、行動 App，這幾類產品的使用者任務、流程複雜度、轉換關鍵都不一樣，硬套同一套原型流程只會浪費時間。下面把常見專案類型拆開，說明各自的原型重點放在哪。

專案類型	原型重點	建議保真度	必驗證的關鍵流程
形象／品牌官網	資訊動線、視覺提案	視覺高保真	首頁到聯絡頁的引導、選單結構
電商／購物網站	結帳流程、商品瀏覽	流程高保真	加入購物車、結帳、註冊與訪客結帳
SaaS／後台工具	操作邏輯、權限	灰框為主	資料新增編輯、篩選、批次操作
行動 App	手勢、單手操作	高保真＋實機	核心任務路徑、推播與返回邏輯
活動／促銷頁	轉換動線、CTA	視覺高保真	從進站到報名／購買的最短路徑

形象與品牌官網的原型重點不在「能不能用」，而在「動線順不順、視覺對不對」。使用者來這類網站多半是瀏覽性質，任務很輕，所以你要驗證的是他們能不能在三秒內抓到重點、能不能順著選單找到想看的頁面。這類專案適合用視覺高保真原型，因為品牌調性本身就是產品的一部分，灰框無法呈現「高不高級」這個關鍵判斷。重點流程是首頁到聯絡頁的引導、選單的分類邏輯、以及手機版選單會不會擠爆畫面。品牌色與字體的取捨，品牌色彩挑選指南 與 中文字體設計推薦 是直接相關的參考。

電商專案的原型重點只有一個字：結。結帳流程是電商的命脈，一個步驟多一個欄位、一次轉頁多一次載入，轉換率就會掉。原型必須把「瀏覽商品、加入購物車、進結帳、填資料、付款、完成」這整條路徑完整走一遍，特別要驗證訪客結帳與註冊結帳的取捨、運費與折扣的顯示時機、表單欄位能不能自動帶入。這類專案建議用流程高保真，因為卡住使用者的往往是流程邏輯，視覺在這裡反而是次要考量。如果你用 WordPress 架電商，WordPress 頁面編輯器比較 與 Elementor 完整教學 能幫你把原型落地成真實商店。

SaaS 與後台工具類專案，使用者任務重、操作頻繁、容錯率低，原型的核心是驗證「操作邏輯會不會讓人出錯」。新增一筆資料要點幾下、批次刪除有沒有防呆、篩選條件能不能組合、不同權限看到的功能差在哪，這些都是要在原型裡走通的問題。這類專案視覺不是重點，灰框就足以回答多數問題，反而應該把時間花在狀態與邏輯的完整度上：空狀態長怎樣、載入中長怎樣、出錯時長怎樣、權限不足時長怎樣，這些邊界狀態往往比主流程更容易出包。

行動 App 的原型有一個網頁沒有的維度：手勢與單手操作。點擊之外還有滑動、長按、拖曳，這些互動在電腦上點不出感覺，必須把原型推到手機上實機操作才知道順不順。原型要特別驗證拇指能不能摸到主要按鈕（ thumb zone ）、返回邏輯會不會把使用者卡死、推播點進來會落在哪個頁面。這類專案建議直接用高保真原型搭配實機預覽，Figma 的行動裝置預覽功能就是為此設計。響應式與行動版的基礎觀念，響應式網頁設計 RWD 與 Figma 響應式設計排版 是必讀。

活動與促銷頁的原型目標極度明確：讓使用者用最少的點擊完成報名或購買。這類頁面壽命短、流量集中、轉換至上，原型要把「進站到完成轉換」的最短路徑磨到沒有多餘步驟。CTA 按鈕的位置、表單欄位的數量、社群登入的選項，每一個都直接影響轉換率。這類專案適合視覺高保真，因為促銷頁的視覺本身就是轉換的推力，灰框無法評估「這樣夠不夠吸睛」。CTA 的設計細節，CTA 行動呼籲按鈕設計 有完整的策略討論；想看不同頁面類型的原型怎麼套，Landing Page 銷售頁製作 與 一頁式網頁設計攻略 是直接的參考。

讓原型真正有用的設計要點

好的原型重點在於互動直觀、風格一致、符合使用者習慣、且能被拿來測試修正，畫面做得漂不漂亮倒不是重點。差別往往出在這幾個取捨有沒有想清楚，跟會不會用進階技巧關係不大。互動要直觀，指的是按鈕、連結、動畫模擬真實使用情境，流程不要過於複雜，能一步到位的就不要拆成三步，能自動帶入的欄位就不要讓使用者重複填；這部分的常見地雷，可參考 網頁設計常見錯誤。風格保持一致，真正在解決的是認知負擔，每換一頁樣式都變，使用者腦袋就要重新適應一次，字體與配色的深入討論見 網頁字體 Webfont 指南 與 網頁配色計畫實戰。最後，原型是用來測試的，完成後要不斷收集回饋、調整優化，不是做完就定案；同時保留可改動的彈性，用元件與樣式變數管理，方便後續迭代。

這幾點其實指向同一件事：原型是給「別人」看的，不是給你自己看的。你是設計師，你看得懂自己畫的任何東西；但客戶、使用者、工程師不是。所以做原型的時候要一直問自己：如果是我媽來點這個按鈕，她知道接下來會發生什麼事嗎？如果工程師看著這份原型，他知道這個表單送出後資料要往哪送嗎？只要這兩個問題有任何一個答不出來，就是原型的資訊還沒給夠。視覺端如果想再求精進，Bento Grid 網頁排版設計、最新網頁設計趨勢、Figma 毛玻璃質感設計 都值得參考。

把「互動直觀」翻成可檢查的清單

「互動要直觀」這句話太抽象，做完原型後常常不知道怎麼自查。把它拆成幾個具體的檢查項，會比較好落地。第一，每個可點擊的元素，游標移上去有沒有給出「我可以被點」的視覺暗示，例如變色、底線、或指標變手勢。第二，點下去之後，系統有沒有在合理時間內給出回饋，哪怕只是一個 loading 動畫，讓使用者知道「我有收到你的點擊」。第三，發生錯誤時，訊息有沒有講清楚錯在哪、怎麼修正，還是只丟一句「發生錯誤」就把人打發掉。第四，使用者做到一半離開再回來，之前的進度有沒有被保留，還是全部要重來。第五，能不能用鍵盤完成主要任務，這對無障礙與效率使用者都很重要。

這五個檢查項不需要什麼高深理論，但絕大多數原型都會在其中某一兩項出問題，因為設計師自己測的時候不會踩到這些情境。把這份清單當成原型完成後的例行檢查，每跑完一輪測試就對照一次，問題會比你想像的多。載入與回饋的動畫做法，Figma 載入動畫原型互動 提供了具體的設計方向；無障礙與易用性的延伸，網頁設計常見錯誤 列了不少容易忽略的細節。

Prototype 製作工具推薦：主流軟體比較

Figma 是目前跨平台、協作最順的首選；Sketch 適合 macOS 使用者；Adobe XD 整合 Adobe 生態；InVision 已於 2024 年底正式停止服務，新專案建議優先考慮 Figma，避免工具汰換造成設計資產搬家成本。

這邊要特別提 InVision。根據 InVision 官方公告與 Fast Company、LogRocket 等媒體的報導，InVision 已於 2024 年 12 月 31 日正式停止服務，所有文件與原型在那之後被永久刪除。所以如果你還看到舊文章把 InVision 列為推薦工具，請直接跳過，它已經不能用了。根據 Fast Company 的分析，它退出市場，很大一部分原因是被 Figma 和 Adobe 夾殺。選工具時把「這東西三年後還在不在」納進考量，才不會做到一半發生設計資產無處可搬的窘境。

工具	平台	協作	費用	適合誰
Figma	瀏覽器、跨平台	即時多人	免費版可用；Professional 為付費方案，實際金額請以 Figma 官方方案頁為準	新手、團隊協作首選
Sketch	僅 macOS	支援	訂閱制，官方提供 30 天免費試用	macOS 單機、重視向量繪圖
Adobe XD	macOS、Windows、iOS、Android	支援	訂閱制，官方提供 7 天免費試用	重度 Adobe 生態用戶
InVision	—	—	已於 2024 年底停服	不再推薦，請改用 Figma

選擇建議很直接：新手與團隊協作選 Figma，它瀏覽器即用、跨平台、即時多人協作，做 Prototype 像連連看一樣拖曳串接，免費版就能完成多數原型需求。macOS 單機且重視向量繪圖選 Sketch。重度 Adobe 用戶選 Adobe XD。如果你想從 Figma 入手，Figma 中文完整教學、Figma 完整指南與註冊教學 是起點；進階互動可看 Figma 視差互動效果、Figma 環形文字效果、Figma 載入動畫原型互動。排版與外掛相關還有 Figma 網格排版系統、Figma 必裝外掛推薦、Figma 圖示外掛匯入、Figma 圖庫外掛資源。

工具是手段不是目的。Figma 免費版就足以完成絕大多數原型，不用一開始就糾結要不要付費。等專案量大、需要無限頁面與團隊協作時再升級就好。Professional 方案定價請直接查詢 Figma 官方方案頁，避免在這裡寫死金額而與實際脫節。關於其他設計資源，商用免費圖庫網站、免費 Icon 圖示網站、免費 3D 素材資源、Lottie 動畫為網站加動態特效 都能在原型階段幫上忙。

選工具的隱性成本：協作、資產繼承、學習曲線

工具的選擇很少只看功能清單，真正會咬人的是三個隱性成本。第一個是協作成本：Figma 的即時多人編輯是瀏覽器原生，開連結就能進來改；Sketch 的協作則需要額外的網路服務與同步設定，跨辦公室的順暢度差一截。如果你的團隊分散在不同地點，或常需要跟客戶即時共編，這個差距會直接決定工具能不能用。第二個是資產繼承成本：今天選的工具，三五年後還在不在、能不能匯出開放格式、能不能被其他工具讀取。InVision 的停服就是最慘的案例，所有設計資產一夕歸零；Figma 雖然目前穩定，但把所有設計資產綁在單一廠商本來就有風險，重要專案定期匯出備份是基本動作。

第三個是學習曲線與人才成本。一個工具再強，如果團隊沒人會用、招募時找不到人，等於把生產力卡死。Figma 目前在設計圈的人才池最大，新人上手最快，這個現實因素讓它在多數情境下成為最低風險的選擇。Sketch 與 Adobe XD 雖然各有強項，但 macOS 限定、或被母公司戰略邊緣化的疑慮，都會讓招募與長期維護變麻煩。把這三個隱性成本想一遍，你會發現工具的「功能強不強」往往是最不重要的考量，能不能長期穩定地用下去才是重點。想深入了解 Figma 生態，Figma 中文完整教學 與 Figma 必裝外掛推薦 是系統性的入口。

原型做完之後：接下來該做什麼

原型做完只是測試的起點，還沒到終點。你要把它拿給真實或潛在使用者操作，觀察他們在哪卡住、哪猶豫、哪直接放棄，再根據回饋迭代。這一步如果跳過，原型就只是好看的自爽作品。

測試不用搞到很正式。找三五個目標使用者，給他們一個任務（例如「請你在這個網站完成報名」），然後閉嘴觀察。不要在一旁指揮「你點那個按鈕就對了」，你一旦提示，回饋就失真了。記錄他們卡住的地方，那些就是你下一輪要改的點。這個循環可能要跑兩三輪，直到多數人能順利完成任務為止。完成後才進入開發，把驗證過的流程交給工程師實作。如果開發端用的是 WordPress，WordPress 頁面編輯器比較、Elementor 完整教學、Divi 主題架站全攻略、Bricks Builder 視覺化編輯器 都是把原型落地成真實網站的選項。非程式路線也可以看 Canva Pro 進階設計技巧、Canva 新手設計教學。

使用者測試的實務操作：從找人到記錄

原型測試要產生有用的回饋，需要幾個環節到位。第一個環節是找對人。理想的受測者是你的目標使用者，同事或朋友並不適合，因為同事跟朋友會客氣、會腦補、會用設計師的思維操作，給你的回饋已經被污染。找人的管道看預算：有預算可以透過使用者測試平台招募並給予車馬費，沒預算就從既有的客戶名單、社群、或相關社團裡找自願者。人數不必多，業界常用的是五到八人，因為研究經驗顯示，多數明顯的可用性問題在前幾位受測者身上就會重複出現，再多人的邊際效益會快速遞減。

第二個環節是設計任務腳本。測試前要先寫好你要請受測者完成的任務，任務要具體但不暗示做法。例如「請你在這個網站找到並報名週末的課程」是好的任務，它有明確目標但不告訴受測者要點哪裡；「請點右上角的報名按鈕」是壞的任務，因為你直接把答案講出來了。一次測試準備三到五個任務就夠，太多任務會讓受測者疲勞，回饋品質下降。第三個環節是測試當下的引導。開始前先說明這是測試原型不是測試他們、鼓勵他們邊操作邊把心裡的話說出來（放聲思考）、並明確告訴他們卡住也沒關係。測試中盡量閉嘴，忍住想幫忙的衝動，只有在他們完全卡死、可能放棄時才最低限度地引導。

第四個環節是記錄與分析。最好同時錄影與錄音，事後再回頭整理；如果無法錄影，至少做詳細筆記，記下每位受測者在哪個步驟猶豫、問了什麼問題、走錯哪條路。分析時的重點是找「重複發生的模式」：如果只有一個人卡在某個地方，可能是個案；如果三個人都在同一個步驟猶豫，那就是設計問題，必須改。把這些問題按嚴重度排序，嚴重的先改，次要的放進下一輪。一輪測試改一輪，改完再測一輪，通常跑兩三輪就能讓主要流程穩定下來。這套方法不花錢也不複雜，但能避免你把沒驗證過的流程直接交給開發，事後才發現整條路走不通。流程驗證的觀念基礎，UI 與 UX 設計差異解析 有更脈絡化的說明。

原型設計常見錯誤與疑難排解

做完原型不等於做對原型。很多原型表面上能點、能跑，卻在真正交給開發或上線測試時才爆出問題，這些問題往往源自幾個重複出現的錯誤。把這些錯誤列清楚，做完原型時逐一檢查，能省下大量返工。

常見錯誤	為什麼會發生	修正方向
只畫快樂路徑	只想像使用者順利完成的情境	補上錯誤、空、載入、權限不足等邊界狀態
互動跟規格脫鉤	只做 demo 沒寫文件	每個互動附上觸發條件與預期行為說明
忽略手機版	全程在桌面機設計	每個畫面同步做行動版並實機預覽
死連結與斷頭頁	串接時漏掉分支或回到上一頁	逐條走過所有點擊，確認沒有走到死路
過早固化視覺	流程還沒通就調配色	流程定案前維持灰框
沒有無障礙考量	只考慮滑鼠點擊	測試鍵盤操作與對比度

「只畫快樂路徑」是原型最普遍的缺陷。快樂路徑指的是使用者一路順利、不出錯、不猶豫的理想情境。真實世界裡，使用者會填錯表單、網路會斷線、庫存會賣完、權限會不足，這些非快樂路徑如果原型裡沒有畫，開發時就會用各自想像的方式兜，結果上線後每個邊界狀態都長得不一樣。修正的方法是針對每個流程，列出至少四種狀態：成功、失敗、空資料、載入中，並把它們都做出對應畫面。這個動作看起來費工，卻是原型跟開發之間最大的摩擦來源，補齊後開發速度會明顯加快。

以這類電商結帳專案的情境為例，最能看出快樂路徑的代價。常見的狀況是，原型只把「選商品、加購物車、結帳、付款成功」這條主流程串起來就交差，訪客結帳與註冊結帳的差異、優惠碼失效、庫存剛好賣完、第三方付款被擋下這些分支都沒畫。依這類站上線後的典型表現幅度，結帳流程中每多一個強制欄位或一次不必要的轉頁，完成率大約會往下掉幾個百分點；而一旦使用者在那個被省略的邊界狀態（例如付款被擋卻沒有明確訊息）卡住，多半直接離開且不會回來。換算成幅度，一個中等流量的購物站，若結帳原型漏掉邊界狀態、上線後才靠客服與開發補救，反覆修改的成本往往落在原型階段就先做齊狀態的數倍以上，這也是為什麼業界普遍把「狀態完整度」當成原型能不能交付開發的硬指標。不過要誠實說明一點，上述幅度是依這類專案的常見區間推估，不是某一個實測專案的精確數字，實際落差會因流量規模、客單價、品類而有差異；決策角度上與其糾結絕對數字，不如把力氣放在「每個分支都有對應畫面與訊息」這件可檢查的事上，因為那才是原型階段真正能攔下的風險。

「互動跟規格脫鉤」則是另一個讓工程師頭痛的問題。原型做得很漂亮、動畫很順，但工程師看著 demo 不知道觸發條件是什麼、動畫時長多少、不同狀態之間怎麼切換。一份只會跑的 prototype，對開發來說跟一份靜態圖沒兩樣，因為他們無法從中讀出規格。修正的方法是養成「每個互動都附說明」的習慣，在原型檔案裡用註解或獨立頁面，把每個互動的觸發條件、目標畫面、過渡效果、預期時長寫清楚。這份說明就是後續規格書的草稿，等於一次做完兩件事。

「死連結與斷頭頁」聽起來低級，卻因為原型串接容易漏而反覆發生。一個選單點進去發現沒有對應畫面、一個返回按鈕按了沒反應、一個分支走到一半接不上主流程，這些都會讓測試中斷、讓客戶質疑專業度。修正的方法很機械：原型完成後，逐個畫面、逐個按鈕手動走過一遍，確認每一條路徑都能走到底或能合理返回。這個動作枯燥但必要，最好交給一個沒參與設計的人來走，因為設計師自己會下意識避開自己埋的斷頭路。響應式與斷點的處理，AWD 與 RWD 設計比較 與 Figma 響應式設計排版 能補上規格面的細節。

Prototype 常見問題：新手最常搞混的幾件事

前面幾節已經把 Prototype 與 Wireframe 的差異、是不是非做不可、低保真與高保真的取捨、工具選擇、做完是否定案都講過了，這裡不重複，只補充幾個正文沒展開、但新手常卡關的實務問題。

Q：原型可以當正式網站用嗎？
不行。原型是演示用的，仍需開發實作。顏色模式與輸出規格可參考 RGB 與 CMYK 色彩模式。更多靈感來源看 網頁設計靈感網站；想用 AI 加速可參考 AI 繪圖網頁設計實戰、ChatGPT 加速 UIUX 設計指令。

Q：原型要不要連後端資料庫一起做？
多數情況不必。原型的目的是驗證流程與互動，用假資料或寫死的內容就足以回答問題；真正接後端是開發階段的事。除非你要驗證的是「真實資料量下的效能與呈現」，那才需要考慮接資料。

Q：原型要做幾個版本（桌面、平板、手機）？
至少桌面與手機兩個。平板視專案受眾決定，如果分析數據顯示平板流量很低，可以暫時用桌面的響應式縮放應付；手機版則因為操作邏輯跟桌面差很多，必須獨立做。行動裝置的流量目前在全球已經過半，手機版屬於必須驗證的核心流程，不能當附加選項看待。

把原型觀念串進你的設計流程

原型扮演的是整個設計流程裡驗證想法的樞紐，並非一個孤立環節。它把 Wireframe 的骨架、Mockup 的視覺、使用者測試的回饋串在一起，讓你在開發前就把「用起來順不順」這件事確認清楚。做好這一步，後面的開發與上線會順很多。

如果你還在規劃整個架站專案，可以對照 Landing Page 銷售頁製作、Landing Page 轉換率優化、一頁式網頁設計攻略 看原型怎麼套進不同類型的頁面。想看別人怎麼做，作品集網站設計指南、作品集網站製作實戰、作品集範本與模板 是現成參考。響應式規格別漏了 AWD 與 RWD 設計比較。最後，如果你是接案者，給品牌網站的關鍵建議、網頁設計費用與報價、網頁設計公司推薦與挑選 能幫你把原型這項服務包進報價與提案裡。

觀念通了，工具會用了，剩下的就是實做。先從一個低保真、可點擊的小流程開始，給三五個人測試，再慢慢把保真度拉高。不用一開始就追求完美，原型本來就是要拿來改的。重點是你開始用它來回答問題，拿來展示畫面只是順帶的好處。