產品原型對於每一個產品經理而言，都有著至關重要的作用。作者結合實際經驗，將從原型設計角度出發，主要闡述如何設計產品原型圖，產品原型圖包括哪些部分以及設計元件庫搭建這幾個方面闡述，希望對你有所幫助。

前幾篇文章從B端產品的業務梳理、業務及流程設計角度出發，為大家分析了在設計產品之前的一些基礎工作，這些準備做好後我們原型設計也會相對來說更加順暢與清晰。本篇文章將從原型設計角度出發，主要闡述如何設計產品原型圖，產品原型圖包括哪些部分以及設計元件庫搭建這幾個方面闡述。

關於原型設計軟體，各有千秋，大家根據自己的喜好或習慣選擇合適的工具，能夠呈現需求設計即可。

話不多說，開始乾貨～

一、如何設計產品原型圖

1. 將需求轉化為原型圖

在這部分我們需要把文字轉化成影象，更直觀的讓使用者感受到需求的實現，以來確定需求設計的正確性。這一環節也是大部分產品經理的核心工作。

當我們根據某個需求進行原型設計的時候，首先要考慮的是基於前期的流程設計，需要拆分幾個頁面去完成這個需求，每個頁面實現什麼樣的功能。這部分不再贅述，可以看上一篇文章《B端產品設計之業務設計》。

簡單來說到這一步，就是將每個頁面的需求透過各元件及互動設計進行實現。如果前面的資訊足夠多和詳細，那原型設計是非常快的。

當然，不是到這就結束了。在原型設計過程中，需要考慮功能設計合理性，比如這裡我是用彈窗承載資訊還是用頁面承載資訊？

別看這麼一個小的設計，都會影響開發團隊的工作量，所以產品經理在原型設計環節要思考每一步設計，為什麼要這樣設計，這樣設計的好處是在哪兒？多反問下自己，多思考。這樣在原型評審環節，才會有理有據，而不是簡單的丟擲一句“xxx產品也是這樣設計的”。

之前在做航空公司的一個小需求，給大家分享下。

eg：建立飛行員人員訓練計劃。

流程設計：建立訓練計劃-選擇訓練人員-下發訓練計劃-訓練結果檢視。

需求很簡單，就是一個新增計劃的需求。

按照這個流程設計，即使是統一的業務流程，各產品經理設計的原型都不一樣，因為他們的思維方式與思考的點都不一樣。有些就是根本不考慮外在的條件，例如訓練計劃是否涉及線下預約會議室，人員是否有休假衝突等，有些就過度考慮了，導致什麼條件都拿來自己判斷，整個系統就很複雜，確實很細緻，但是設計週期就會很長。

最好的原型設計是可以清晰表達需求及功能點，各參與方（需求方、開發實現團隊）都可以很清楚的瞭解自己的部分。

所以原型設計說簡單也簡單，說複雜也很複雜，這考驗的是產品經理對於需求的把控度、原型設計合理性，能夠在為使用者更好的詮釋解決方案的同時，儘量的降低開發成本。

2、二八法則設計

結合上一篇文章《B端產品之業務設計》，基於流程與功能的設計，就能完成80%原型，功能為頁面佈局設計提供基礎，流程為互動設計提供基礎。同樣的是二八法則，產品經理根據自己前期的調研結果，比如功能架構、流程圖等進行原型設計，完成80%的原型設計以及PRD，剩下20%是需要和團隊一塊頭腦風暴，補充或調整原型，輸出最終100%的原型設計。

當然也有可能存在返工，比如UI設計發現這裡佈局緊湊調整，開發發現原先的互動方式無法實現，或實現出來與預計的結果要差，都會導致原型調整，調整不可怕，可怕的是推到重新設計，所以提到80%的原型設計輸出後就要和團隊進行溝通與澄清，降低返工率，保證產品業務設計核心不偏離。

切記，產品經理最忌諱閉門造車，埋頭苦幹設計了很久的原型，有可能在評審階段就當頭一棒。我們同樣要在設計上預留備選方案，這樣在調整的時候才不會覺得全都重新設計，如果有元件庫那麼會更快的完成調整，後面會講到～

節奏要學會自己把控，被動轉主動，才不會有那麼大的壓力～

3. 原型設計包含的內容

（1）全域性說明

原型部分的全域性說明主要是指頁面設計規範與邏輯設計規範，保持全域性統一，該部分貫穿原型設計-UI/UE設計-開發-測試整條線。考驗的是各階段負責人的提煉能力，因為需要站在更高維度去審視自己所負責的部分。產品經理和設計師需要全域性把握頁面與互動設計規範，產品經理和開發團隊需要把握邏輯設計規範。

頁面設計規範：與互動設計師/UI設計師共同完成；這部分主要是規範設計上的尺寸大小，互動體現等。

例如警告型別彈窗，顏色大小，以及互動（倒計時2s自動消失）。

例如一級標題大小24px，二級標題大小20px等。

這一部分可以去看看各大廠出的設計規範，可以作為參考，例如優酷、餓了麼等設計規範。

邏輯設計規範：與開發團隊共同完成；這部分主要是規範通用邏輯的規則設計，相比於頁面設計規範，這部分規範要少些。

例如新使用者校驗規則，介面呼叫規則，成功返回，失敗返回/告警等 。

常用的邏輯規則可以提煉出來寫在全域性設計中，這樣就不用每一處再去強調了。

其實規範全域性設計的同時也在規範各個階段之後的參與，提高效率的同時也在規範整體的設計。

（2）功能流程設計

將前期整理的功能流程設計一併放入到原型中，便於功能原型/互動設計的時候對照流程進行設計，也便於開發團隊看原型與流程一起。

（3）原型圖設計

我看過很多產品經理本身就是追求完美的，所以原型設計耗時非常長，因為他們總想交付最好的原型圖，能夠做細緻的地方要做細緻。其實原型圖在我們這裡，我們只需要透過圖形設計實現需求表達即可。

大部分情況下留給產品經理的時間不多，即使時間較為充裕的情況，我們也會因為需求變動或其他情況導致原型設計時間緊張，常見的就是甲乙方，甲方最開始表達的確實是A，當看了原型後，可能會變成A+1，所以最終我們輸出的可能是A+N或者是A-N，其實變動都不可怕，我們只要掌握好自己的節奏即可。

關於是否高低保真根據當前的需求情況而定，大部分情況還是低保真，一是可以快速完成原型設計階段響應需求，二是留給設計師更多空間，不要限制了設計師的想象與發揮，雖然這二者間的關係也很微妙～

最後就是一直在提的設計邊界，原型設計同樣的要注重邊界感。結合上部分提到的，功能設計不要冗餘複雜，都是逐步完成的，就像我們實現代步工具，不是一開始造車輪，而是一開始可能就是各滑板車，能夠將產品或業務功能主線運轉起來才是核心。

因為我自己也是這樣走過來的，原型設計中會有很多新想法，不斷的去豐富了某個主線內容，其實花費了時間還不一定最後會採納，不僅產品經理會有這種想法，設計師，開發團隊都會有，作為產品經理，一定要把握主線，懂得取捨，能夠快速實現產品價值，獲取商業價值或回報也是很重要的。

二、與PRD的結合

這算是個人設計偏好吧，我在此也與大家分享下。

在產品前3年，我的原型設計稿和PRD是分開的，在一次次和開發團隊確認需求實現的時候，發現他們大多時候要麼只看設計稿，要麼只看PRD，二者都看的人少之又少。對於每一個個體來說，他們優先都會選擇更節省時間或利己的方式，但是往往PRD和設計圖是不可單獨閱讀的，需要結合起來閱讀。

當時在一個產品群裡面，也有各大佬分享自己的經驗，最後我選擇了將重要互動或說明貼在原型設計中的方式。採用該方式後，我發現和開發團隊的溝通會更順暢一些，當然也還是會存在依然只看文字或圖畫的人，但基於這樣的設計去溝通，會更快一些，包括複雜互動的說明也更加容易的溝通。

圖文結合也往往是人們最容易閱讀和接受資訊的方式。

（原型設計某截圖，重要資訊已遮蔽）

三、關於元件庫的搭建

現在有很多成熟的開放設計平臺供我們參考，比如阿里的Antdesign Vue、餓了麼Element UI、騰訊的TDesgin、Clarity UI Library等平臺。這些會提供基礎的元件樣式，但大部分沒包括互動設計，但對於我們原型基礎功能的應用還是有很大的幫助的。

說到這，作為產品經理，我個人也會經常找UI朋友要一些設計網站看看，知道當前流行的設計元素、設計風格等，對於原型設計也有一定的幫助，其實還是需要豐富自己的設計思維的。

我們有了基礎的元件庫後，可以把自己每一次大的改動或新設計的元件放在一起，不要為了節省時間放在一個畫布裡面，還是要分類，框架設計、表單設計、按鈕設計等等。

例如：常見的登陸頁面，會涉及到的，密碼輸入隱藏明文，密碼輸入錯誤彈窗、勾選登陸協議等等。另外包括表單設計、搜尋框等，這些很常用的都可以作為元件的元件庫。

我們搭建個人組件庫，是更好的幫助我們去完成原型的輸出和調整原型。一是提升我們自己的效率，二是應對一些變動也會更快響應，也就是我強調的，原型設計階段，產品經理要把握自己的節奏，不要被變動或deadline牽著走。

當然還有一點，一些複雜的不常用的元件，不經常使用或設計，不要因為頻次低而不放入元件庫中，正因為使用頻次低，所以才會忘記當初的設計方式，再去百度，也就是花了雙倍或多倍時間來完成這個元件設計。我們有自己的元件庫，就可以直接用，想要知道如何設計，根據設計邏輯就可以拆分，快速熟悉。

現在的各類平臺或工具都在搭建或規範元件平臺，不僅是方便原型設計，UI設計，開發等，都是比較快速的去實現一些基礎的需求。其實就是將N次重複的簡單的設計轉為通用可複用的設計，理念旨在更高效。

寫在最後

我知道現在好多產品經理會自嘲自己是“原型仔”，雖然有一定玩笑話在裡面，但是這一部分確實也反應了，很多時候產品經理的設計被吐槽，甲方、領導、開發團隊、甚至測試等，甚至所有人都可以吐槽產品經理的設計，別怕，也別有壓力，如果我們設計的東西都沒人吐槽，那這個產品也就不需要了我們了吧，哈哈。

放輕鬆，坦然面對就好了，壓力很多時候來源於自身。

即使是按照甲方/領導的要求來做，那麼也要有自己的思想在裡面，如果過程中不思考，慢慢就變成了原型輸出機，不要特別在意結果（比如想要設計部分都完全透過），但是該爭論的地方還是要爭論的 ，在某些點該堅持就是要堅持。我比較享受在設計過程中，大腦的靈活，自己想法或與團隊想法的碰撞，慢慢沉澱屬於自己的經驗。

好的設計一定會發光，但是有可能不是當下。

我記得在設計活動營銷平臺 ，因為某一處的設計和公司的黑帶大佬（屬於鳳毛麟角的那種開發大佬），爭論了一兩個小時，上線後可能一個月了，大佬說我當時堅持的想法是對的，我聽到當然很開心，這就是產品經理的小確幸吧。

Tag是自己定義的，從不屬於他人。

本文由 @SLJwu 原創釋出於人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。