Prototype不是紙上談兵：設計與工程如何對齊原型思維？

為什麼 Prototype 不是紙上談兵？

原型（Prototype）一詞源自希臘字根，意指「原始型態」。在日常生活中，我們其實經常運用類似的概念。

在工作場域中，除了可以區分 PoC（Proof Of Concept）和 Prototype 外，溝通上可以主要從「工程」和「設計」兩個面向切入。

日常的場景

之前有工程師問：

「Prototype 用紙做哪有用？使用者根本不懂那畫面到底是什麼！」

也會有設計師覺得：

「工程的原型都做太久了！這樣迭代速度太慢，使用者和商機都跑了。」

這是實際在團隊合作中，就算不講出來也會偷偷藏在心裡的對話。

近幾年有機緣帶領兩個不同背景的團隊做 Prototype，進而完成產品。但在大家對 Prototype 定義各自表述的情況下，相對會難以達成共識。

本篇文章探討在「製作成品」時各自都遇到的疑問：

什麼是 Prototype？
Prototype 有哪幾種？
Prototype 能怎麼運用？

讓我們一起看下去。

什麼是 Prototype？

所謂 Prototype，作為名詞主要用於測試概念是否可行，背後是簡單但短暫的「物體/流程」；作為動詞則泛指快速簡單地做點東西測試。

「原型」的單字起源

Prototype 一詞源自希臘單字 prototypon，泛指原始型態（primitive form）。原本的形容詞是 prototypos，指的是最初、原始（original, primitive），由兩個字組成：

protos：第一（first）
typos：印象（impressions）

換句話說，指的是很初期、很原始的型態，甚至就是把印象、想法做出來。

（筆者備註：希臘文部分有些亂碼，故以英文說明）

生活中的 Prototype 案例

我們每天都有 Prototype 的應用。

最常見的是沒有自拍棒時，為了喬合照，我們會現場拿書疊一疊，作為一種快速、短暫、能使用的「原型（Prototype）」，驗證其功能是否能順利支撐大家拍照。

學生時期若發現椅子高度不合，常見做法是拿橡皮擦、衛生紙或文宣紙疊成小堆，放在較短的椅腳上。

這些「簡單但短暫」的動作，可以說是「原型（Prototype）」的核心想法。

有哪幾種 Prototype？

Prototype 的翻譯——雛形品 vs 原型

當我們談 Prototype 時，有兩種翻譯方式：

雛形品：通常指功能較完善，準備測試的解決方案。
原型：涵蓋從「概念」到「功能」驗證的廣泛稱呼。英文中還會區分 PoC Prototype（Proof of Concept，概念驗證），但中文通常不特別區分，甚至都叫原型。這種「沒特別區分」常常導致誤會。

不論哪種，都是概念測試和確認產品方向的過渡產物。

「概念驗證」的誤區——是動詞還是名詞？

常見誤解是中文講「概念驗證」（Proof Of Concept）時，可能指：

動詞，Prototype 的功能或目的之一。
名詞，Prototype 的一種類型，即 PoC Prototype，用於「展示」可行性。工程上常用「麵包板」接電路來展示、驗證想法是否可行。

團隊常說要「驗證概念」，但沒有特別指出是什麼概念。有時是指功能上的 PoC Prototype，有時則尚未釐清要驗證什麼。

Prototype 的兩種切入法 — 「設計」和「工程」

根據經驗，Prototype 主要應用於兩種場景：

工程團隊談 Prototype 時，偏向「功能出發」，大假設是「做一個好產品滿足所有需求」。
設計團隊則強調回應「使用者需求」，大假設是「先針對特定受眾進行產品方向的限縮」。

兩者常因角度不同而產生衝突。

不過兩種原型的「終點」都是希望有「產品」，共同目標是「解法優化與確認方向」。

若雙方能從這層目的與角度考慮，將減少摩擦。

以「登山杖」為例

假設一個團隊正在開發登山杖，分為「設計」和「工程」兩個小團隊。

工程團隊假設是做一個好產品滿足所有需求，希望先設計「可伸縮」登山杖，讓使用者快速測試並買單。
設計團隊希望先收斂使用者習慣與高度，透過受眾切割與需求調整，迅速改變解法方向。

因此會出現設計覺得工程太龜毛，工程覺得設計變來變去的情況。

此時可以先核對兩者對 Prototype 的想法，假設兩者不衝突，一起思考：

設計先抓出特定使用者，收斂登山杖所需高度。
工程針對這個高度設計版本，再進行延伸。

有時也可以以「如何讓使用者登山」為目的，重新討論需求。

工程與設計的考量都正確，透過疊加想法，能讓產品更順利收斂。

Prototype 時要注意什麼？

一、明確 Prototype 是偏「工程」還是「設計」？

一開始就要先釐清彼此對「Prototype」的定義及要驗證的假設。

設計偏向從使用者出發，強調解決使用者痛點。這種驗證方式常被工程質疑「太陽春」，因為重點在看使用者反應。
工程偏向產品功能完成，常被設計師批評「太複雜，使用者不一定喜歡」。

兩者目的都是完成產品，建議雙方嘗試取得平衡，或由 PM 協助協調。

二、核對雙方對 Prototype 的理解

專案初期建議不斷調整彼此對 Prototype 的理解。

因為每個人的脈絡不同，有人認為 Prototype 必須「完整」才能給使用者測試，有人則認為只要有東西就能測試。

雙方脈絡都需尊重。

提醒： Prototype 是個很大又模糊的名詞，常造成代溝。使用時要有心理準備，需溝通與磨合詞彙的意義。

三、核對專案目標與團隊策略方向

團隊與企業重要的是定義每一層交付的「終點」是什麼。

Prototype 是協助在終點前建立多個里程碑（Milestone），幫助早期核對、驗證是否朝向大家同意的終點前進。

補充——工程上的 Prototype 脈絡

工程常用的 Prototype 分類有兩軸：

實體 vs 分析
聚焦 vs 理解型

細分出多種種類。

設計上則有功能性（Work like）、PoC 型、視覺型（Look like）、感覺型（Feel like）等。

提到相關關鍵詞時，要先釐清是工程脈絡還是設計脈絡的 Prototype。

結論

提到 Prototype 時，可以先區分 PoC 是指很早期的原型。

在脈絡上，要讓工程背景的夥伴理解設計中原型的概念。

運行相關議題時，核心是理解 Prototype 的價值在於「測試概念或流程」，業界中就是為了創造產品。

參考資料

Design prototyping methods: state of the art in strategies, techniques, and guidelines
https://en.wikipedia.org/wiki/Prototype
Benchmark Pre-Production Practice in Manufacturing Engineering
https://www.nesta.org.uk/blog/proof-of-concept-prototype-pilot-mvp-whats-in-a-name/