設計思考 Prototype 怎麼做？快速原型流程與測試重點

設計思考 Prototype 是什麼？

設計思考 Prototype 是把想法做成可被看見、操作或體驗的原型，用來在正式開發前驗證假設、蒐集回饋，並降低錯誤方向帶來的成本。

Prototype 的重點不在精緻度，而在能不能幫團隊回答關鍵問題。它通常有三個目的：

• 把抽象概念轉成使用者能理解的產出物。
• 讓團隊在早期看見流程、介面、服務或產品的風險。
• 透過測試回饋決定要修改、重做，或推進到下一階段。

Prototype 在五步驟中的位置

在設計思考五步驟中，Prototype 位於 Ideate 發想之後、Test 測試之前。前面階段負責理解使用者與產生想法，Prototype 則負責把想法變成可測試的形式。

常見流程是：同理使用者、定義問題、發想解法、製作原型、進行測試。這裡的原型不需要完整，只要足以讓使用者完成一個任務或回應一個情境。

原型不是成品，而是驗證假設的工具

Prototype 容易被誤會成 Demo 或正式產品預覽，但兩者的任務不同。Demo 通常用來展示成果，Prototype 則用來找出問題。

項目	Prototype	Demo
目的	驗證假設與風險	展示已完成或接近完成的成果
完成度	可粗糙、可修改	通常較完整、較穩定
使用時機	開發前或早期探索	提案、銷售、發表或驗收

為什麼 Prototype 要快速、粗糙、可修改？

快速原型的價值，是用低成本讓錯誤提早發生。原型越早被測試，團隊越能在投入設計、工程與預算前修正方向。

太早追求高擬真，常會讓團隊把時間花在視覺細節，而不是使用者是否理解、是否願意操作、流程是否合理。我的判斷是，Prototype 階段最怕的不是做得醜，而是做得太像成品，讓大家不好意思推翻。

• 速度：能在短時間內做出可測試版本。
• 成本：用紙、便利貼、簡單線框或角色扮演就能驗證初步想法。
• 可迭代：測完可以立刻修改，不會因投入太多而捨不得改。
• 焦點清楚：每次原型只回答一組關鍵假設。

快速原型的 4 個判斷標準

標準	判斷方式
可理解	使用者看得懂情境、任務與操作入口。
可操作	使用者能點、選、移動、說出下一步，或完成模擬流程。
可測試	原型能對應明確問題，例如是否找到功能、是否理解價值。
可修改	測試後能快速替換畫面、流程、文案、接觸點或模型部件。

做 Prototype 前，先把 POV 與 HMW 定清楚

Prototype 製作前，必須先定義使用者、情境、需求與假設。POV 和 HMW 能把洞察轉成可原型化的問題，避免做出看似熱鬧但測不出結論的原型。

如果問題沒有被定清楚，原型通常會變成點子展示。好的 Prototype 應該能回應一個具體問題：這個使用者在這個情境下，是否需要這個解法？

POV 公式：誰在什麼情境下需要什麼

POV 可以用一句話整理：某一類使用者，在某個情境下，因為某個洞察，需要某種支持。

範例：第一次使用線上蛋糕訂購服務的上班族，在午休時間需要快速完成客製化選擇，因為她不想花太多時間比較款式，也怕送錯日期。

這句 POV 已經提供原型方向：原型要測的可能是客製化流程、日期提醒、款式比較方式，而不是整個購物網站。

HMW 問題如何導向原型

POV 洞察	HMW 問題	可做的 Prototype	要驗證的假設
使用者怕客製化選錯	我們如何讓選擇過程更安心？	三步驟客製化紙上原型	分步選擇能否降低猶豫感
使用者不確定服務流程	我們如何讓交付狀態更透明？	通知訊息與狀態頁原型	狀態提示能否減少詢問客服
使用者不想花時間比較	我們如何快速推薦合適方案？	篩選問答互動原型	問題式推薦是否比分類瀏覽有效

Prototype 有哪些類型？

Prototype 可以是紙上草圖、低擬真線框、Clickable Prototype、服務角色扮演或實體模型。選哪一種，要看你想驗證的是理解、流程、互動、服務情境還是物理可行性。

類型	適合驗證	常見產出	擬真程度
紙上原型	概念、流程、資訊架構	手繪畫面、便利貼流程	低擬真
互動原型	操作路徑、介面反應	Clickable Prototype	中到高擬真
服務原型	接觸點、角色分工、等待體驗	情境劇、服務藍圖片段	依情境而定
實體產品模型	大小、握感、結構、使用動作	紙板模型、3D 列印樣品	低到高擬真

紙上原型與低擬真原型

紙上原型適合在想法還不穩定時使用。它可以是 App 畫面、網站版型、表單流程、服務接觸點，也可以只是幾張便利貼排出的流程。

低擬真的優點是討論成本低。當使用者說「這裡我看不懂」或「我以為下一步會是付款」，團隊可以立刻改順序、改標籤、刪掉多餘步驟。

互動原型、Mockup 與 Clickable Prototype

產出	主要用途	是否可互動
Mockup	呈現介面視覺與版面	通常不可互動
Clickable Prototype	模擬點擊路徑與任務流程	可互動
高擬真互動原型	測試接近真實產品的操作感	可互動，視覺更完整

服務原型與角色扮演

服務原型常用在餐飲、醫療、教育、門市、客服或公共服務情境。團隊可以用角色扮演模擬使用者進店、詢問、等待、付款、收到通知等接觸點。

例如測試取貨流程時，一人扮演顧客，一人扮演店員，一人觀察顧客在哪個步驟卡住。這種原型不一定漂亮，但很容易暴露人員訓練、標示、話術與等待時間問題。

實體產品模型

材料	適合目的
紙板、泡棉板	測試尺寸、比例、攜帶方式
樂高、積木	快速組合結構與零件關係
3D 列印	測試握感、外型、裝配概念
現成物件改造	模擬使用情境與操作動作

低擬真還是高擬真？Prototype 類型怎麼選

Prototype 類型要依驗證目標選擇。若要測概念與流程，低擬真通常更快；若要測真實互動、視覺信任感或細節操作，才需要高擬真。

我的建議是先問「這次測試失敗時，我想知道哪裡錯？」如果答案是需求或流程，做太精緻只會拖慢學習速度；如果答案是操作細節或轉換信任，高擬真才有必要。

依驗證目標選：理解、流程、互動、可行性

驗證目標	適合原型	原因
使用者是否理解概念	紙上原型、故事板	重點在情境與價值，不必做完整介面。
流程是否順暢	低擬真 wireframe、流程卡	方便快速調整步驟與資訊順序。
互動是否直覺	Clickable Prototype	能觀察點擊、返回、選擇與錯誤路徑。
外觀是否影響信任	高擬真原型	視覺品質可能影響使用者對品牌或服務的判斷。
技術是否可行	POC 或工程樣品	需要驗證技術風險時，Prototype 不一定足夠。

依時間、預算、團隊能力選

• 時間少於一天：優先選紙上原型、流程卡、簡單線框。
• 需要跨部門溝通：選可被非設計成員理解的流程圖、故事板或服務劇本。
• 已有清楚介面方向：可進入 Figma 類型的互動原型。
• 預算有限：避免先做昂貴模型，先用替代材料驗證尺寸與情境。
• 風險在工程端：Prototype 測使用者反應，POC 測技術可行性，兩者應分開處理。

設計思考 Prototype 製作流程

設計思考 Prototype 製作流程可以分成五個核心動作：定假設、選情境、做原型、設計測試、蒐集回饋並迭代。每一步都要對應可判斷的問題。

1. 決定要驗證的假設

先寫下這次原型要回答的問題，例如「使用者是否能在三步內完成預訂」、「這個推薦邏輯是否比分類瀏覽更容易選擇」。

成功條件可以是任務是否完成、是否看懂價值、是否主動詢問下一步，也可以是錯誤點是否集中在同一段流程。

2. 選定使用者情境與任務

原型測試應該放在具體情境裡，而不是讓使用者自由評論。任務範例可以是：「你想訂一個週五送到公司的生日蛋糕，請從首頁開始完成選擇」。

任務越接近真實情境，回饋越有價值。只問使用者喜不喜歡，通常得到的是禮貌答案，不會得到流程問題。

3. 選擇原型形式並快速製作

根據驗證目標選擇紙上原型、wireframe、互動原型、服務原型或實體模型。製作時只放入測試需要的元素，避免把整個產品都做出來。

如果要測付款流程，不需要做完整會員中心；如果要測門市取貨體驗，不需要先完成全套品牌視覺。這是很多團隊第一次做 Prototype 時最容易失焦的地方。

4. 設計測試問題與觀察重點

測試項目	觀察方式	可能代表的問題
完成率	使用者是否完成指定任務	流程過長、入口不清楚、資訊不足
理解度	使用者能否說出功能用途	文案、標籤或價值主張不明
錯誤點	在哪一步點錯、停住或返回	資訊架構或互動提示有問題
情緒反應	是否猶豫、焦躁、驚喜或不信任	流程壓力、信任感或期待落差

5. 蒐集回饋並決定迭代方向

測試後不要只整理意見清單，要把回饋轉成決策。若多數使用者卡在同一步，先改流程；若使用者理解錯價值，先改情境與文案；若使用者根本不需要這個解法，就要回到問題定義。

好的迭代不是把所有建議都加進去，而是找出最影響假設成立的問題。

Prototype 可以驗證哪些商業與產品假設？

Prototype 可以驗證需求、價值主張、使用流程、服務接觸點與初步信任感，但不能單獨證明商業模式一定成立。它適合降低早期不確定性。

需求假設、價值主張假設、流程假設

假設類型	可用 Prototype 驗證的問題	常見測試方式
需求假設	使用者是否真的遇到這個問題	情境故事板、任務訪談
價值主張假設	使用者是否理解並認同解法價值	概念頁、服務劇本、低擬真流程
流程假設	使用者是否能順利完成任務	wireframe、Clickable Prototype
服務假設	接觸點、等待、通知是否合理	角色扮演、服務原型

哪些問題不適合只靠 Prototype 驗證

• 工程可行性：需要 POC、技術研究或工程評估。
• 營運成本：需要估算人力、供應鏈、交付時間與維護成本。
• 定價接受度：需要價格測試、訪談或真實交易資料輔助。
• 長期留存：Prototype 能測第一次使用，較難測長期習慣。
• 市場規模：需要搜尋資料、競品研究、問卷或銷售測試。

Prototype、MVP、Wireframe、Mockup、POC 有什麼不同？

Prototype、MVP、Wireframe、Mockup、POC 都是產品開發常見產出，但驗證對象不同。Prototype 重點在使用者與假設，MVP 更接近真實市場測試。

名詞	主要用途	典型問題
Prototype	驗證想法、流程、互動與需求	使用者看得懂、用得順嗎？
MVP	用最小可行產品進行市場驗證	使用者願意使用、付費或持續回來嗎？
Wireframe	規劃介面架構與資訊層級	內容與功能放在哪裡？
Mockup	呈現視覺設計與版面樣貌	畫面看起來是否符合品牌與信任感？
POC	驗證技術或方法是否可行	這個技術做得出來嗎？

Prototype vs MVP

Prototype 多半用於正式開發前，幫助團隊找出方向是否值得投入。MVP 則是能被真實使用者使用的最小版本，通常需要更完整的功能、資料處理與上線條件。

如果還不知道使用者要不要這個解法，先做 Prototype；如果已經知道核心需求成立，想測真實使用、轉換或留存，再考慮 MVP。

Prototype vs Wireframe / Mockup

Wireframe 偏向介面骨架，Mockup 偏向視覺樣貌，Prototype 則可以包含互動與任務測試。Wireframe 和 Mockup 可以成為 Prototype 的一部分，但不等同於完整的原型測試。

Prototype vs POC

POC 關心技術可不可行，Prototype 關心使用者是否理解、需要並能完成任務。若一個想法同時有技術風險與需求風險，通常要分別做 POC 與 Prototype。

三個設計思考 Prototype 範例

好的設計思考 Prototype 範例都會清楚標出假設、測試方式與修改方向。沒有驗證假設的案例，只是作品展示，對決策幫助有限。

App 功能原型範例

情境：一個烘焙品牌想測試「三題問答推薦蛋糕」功能。假設是使用者不想瀏覽太多分類，只想快速得到適合場合的推薦。

團隊可用低擬真互動原型做三個問題：收禮者年齡、場合、口味偏好。測試時觀察使用者是否能完成問答、是否信任推薦結果、是否想修改條件。若使用者反覆回頭改答案，表示問題設計或推薦邏輯需要調整。

服務流程原型範例

情境：一家門市想改善預訂取貨流程。假設是顧客卡住的原因不是付款，而是不知道到店後要去哪裡報到。

團隊可用角色扮演模擬顧客進店、看標示、報到、取貨與確認商品。觀察重點是顧客是否找到櫃台、是否理解取貨編號、店員話術是否清楚。若多數人第一眼找不到報到點，優先改標示與動線。

實體產品原型範例

情境：團隊想設計一款可重複使用的蛋糕提盒。假設是使用者需要更穩定、好拿、不容易傾斜的包裝。

初期可用紙板與提把做低擬真模型，請使用者模擬提取、放進機車置物箱、走樓梯與打開盒蓋。若回饋集中在提把壓手或盒身晃動，下一版再調整結構，不必一開始就做高成本模具。

Prototype 測試要看哪些指標？

Prototype 測試應同時看量化行為與質化回饋。常見指標包括完成率、理解度、錯誤點、情緒反應，以及原本假設是否被支持。

完成率、理解度、錯誤點、情緒反應

指標	怎麼看	適合判斷
完成率	使用者是否完成指定任務	流程可用性
理解度	使用者能否說出功能目的與下一步	概念清楚度
錯誤點	使用者在哪裡停住、點錯或誤解	資訊架構與互動問題
情緒反應	觀察猶豫、焦躁、放心、驚喜等反應	信任感與體驗壓力
假設結果	回到原本假設，判斷支持、部分支持或不支持	下一步決策

如何判斷要迭代、重做或進入 MVP

測試結果	建議下一步
使用者理解需求，但流程卡住	迭代流程與介面，再測一次。
使用者完成任務，但價值感不強	重修價值主張、文案與情境設定。
使用者不認為問題存在	回到 POV 與 HMW，重新定義問題。
多數使用者能完成任務，且核心假設被支持	評估工程、營運與商業條件後，再進入 MVP。

常見錯誤與檢核表

Prototype 最常見的錯誤，是做太精緻、問錯問題、沒有明確假設。測試前用檢核表確認目的、任務與觀察方式，能大幅提高回饋品質。

把原型做太精緻

當原型太像正式產品，使用者容易把注意力放在顏色、圖片、字距與品牌感，反而忽略流程是否順。團隊也可能因為投入太多時間，不願意接受推翻性回饋。

高擬真不是不好，但要用在對的問題上。若只是要確認使用者是否需要這個功能，低擬真通常更適合。

只問使用者喜不喜歡

「你喜歡嗎？」很容易得到模糊答案。Prototype 測試應設計任務，例如請使用者完成預訂、找到某個功能、選出適合方案，並觀察他們實際怎麼做。

使用者的行為比禮貌評論可靠。尤其在台灣訪談情境裡，受測者常會避免直接否定設計，觀察卡點比聽表面稱讚更重要。

Prototype 製作前與測試前檢核表

• 是否已寫出 POV 與 HMW？
• 是否知道這次要驗證哪一個假設？
• 原型是否只包含測試必要元素？
• 是否定義使用者情境與任務？
• 是否準備觀察重點，而不是只收集喜好？
• 測試後是否有判斷標準：迭代、重做或進入 MVP？

設計思考 Prototype 的限制

設計思考 Prototype 能降低早期決策風險，但不能取代工程評估、營運規劃、定價測試與真實市場驗證。它是學習工具，不是保證成功的流程。

原型測試常能告訴你使用者是否理解、是否卡住、是否感興趣，但無法完整回答產品是否能被穩定開發、長期維運、規模化交付。成熟團隊會把 Prototype 的結果放進更大的決策脈絡，而不是把一次測試當成全部答案。

設計思考不是萬用流程

設計思考適合處理需求不明、體驗複雜、需要跨部門協作的問題。但如果問題主要來自法規、成本結構、供應鏈或核心技術限制，只靠 Prototype 會低估風險。

最務實的做法，是用 Prototype 快速排除使用者端的不確定，再用工程、財務、營運與市場資料補上其他判斷。Prototype 的價值在於讓團隊提早看見錯誤，並知道下一步該改、該測，還是該推進到 MVP。

設計思考 Prototype 是什麼？

設計思考 Prototype 是把想法轉成可被體驗、操作或討論的原型，用來在正式開發前驗證使用者需求、流程與假設。它可以是紙上草圖、互動原型、服務角色扮演或實體模型。

Prototype 一定要做得很漂亮嗎？

不一定。早期 Prototype 應該快速、低成本、可修改。只有當測試目標涉及信任感、視覺感受或細節互動時，才需要提高擬真程度。

沒有設計背景也可以做 Prototype 嗎？

可以。Prototype 的重點是驗證假設，不是展示設計技巧。工作坊、創業團隊或非設計背景成員，都可以用便利貼、紙張、流程卡、簡單模型開始測試。

Prototype 和 MVP 有什麼不同？

Prototype 多用於早期驗證想法與流程，通常不需要真正上線。MVP 是最小可行產品，已經能讓使用者實際使用，適合測市場反應、轉換、留存或付費意願。

Prototype 和 Wireframe、Mockup 有什麼不同？

Wireframe 是介面骨架，Mockup 是視覺畫面，Prototype 則用來模擬體驗與測試任務。Wireframe 和 Mockup 可以成為 Prototype 的素材，但本身不一定能完成使用者測試。

設計思考 Prototype 要花多久完成？

時間取決於驗證目標。紙上原型可能在工作坊中快速完成，互動原型或實體模型則需要更長製作時間。判斷標準不是花多久，而是能否回答當前最重要的假設。

Prototype 測試要找幾位使用者？

早期 Prototype 測試不追求統計代表性，重點是快速找出明顯卡點。可以先找少量符合目標情境的使用者測試，當問題重複出現，就先迭代再進行下一輪。

低擬真原型和高擬真原型怎麼選？

若要測需求、概念與流程，先選低擬真原型。若要測操作細節、視覺信任感或接近真實產品的互動，才選高擬真原型。

服務設計也可以做 Prototype 嗎？

可以。服務原型常用角色扮演、情境劇、服務藍圖片段或接觸點模擬，測試顧客等待、報到、付款、通知、客服回應等流程。

Prototype 測試後，怎麼判斷要修改、重做或進入 MVP？

若使用者理解需求但流程卡住，優先修改並迭代。若使用者不認同問題或價值，就回到 POV 與 HMW 重做。若核心假設被支持，且工程、營運與商業條件可行，再評估進入 MVP。