產(chǎn)品原型對于每一個產(chǎn)品經(jīng)理而言，都有著至關(guān)重要的作用。作者結(jié)合實際經(jīng)驗，將從原型設(shè)計角度出發(fā)，主要闡述如何設(shè)計產(chǎn)品原型圖，產(chǎn)品原型圖包括哪些部分以及設(shè)計組件庫搭建這幾個方面闡述，希望對你有所幫助。

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

關(guān)于原型設(shè)計軟件，各有千秋，大家根據(jù)自己的喜好或習(xí)慣選擇合適的工具，能夠呈現(xiàn)需求設(shè)計即可。

話不多說，開始干貨～

一、如何設(shè)計產(chǎn)品原型圖

1. 將需求轉(zhuǎn)化為原型圖

在這部分我們需要把文字轉(zhuǎn)化成圖像，更直觀的讓用戶感受到需求的實現(xiàn)，以來確定需求設(shè)計的正確性。這一環(huán)節(jié)也是大部分產(chǎn)品經(jīng)理的核心工作。

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

簡單來說到這一步，就是將每個頁面的需求通過各組件及交互設(shè)計進行實現(xiàn)。如果前面的信息足夠多和詳細，那原型設(shè)計是非?？斓摹?/p>

當然，不是到這就結(jié)束了。在原型設(shè)計過程中，需要考慮功能設(shè)計合理性，比如這里我是用彈窗承載信息還是用頁面承載信息？

別看這么一個小的設(shè)計，都會影響開發(fā)團隊的工作量，所以產(chǎn)品經(jīng)理在原型設(shè)計環(huán)節(jié)要思考每一步設(shè)計，為什么要這樣設(shè)計，這樣設(shè)計的好處是在哪兒？多反問下自己，多思考。這樣在原型評審環(huán)節(jié)，才會有理有據(jù)，而不是簡單的拋出一句“xxx產(chǎn)品也是這樣設(shè)計的”。

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

eg：創(chuàng)建飛行員人員訓(xùn)練計劃。

流程設(shè)計：創(chuàng)建訓(xùn)練計劃-選擇訓(xùn)練人員-下發(fā)訓(xùn)練計劃-訓(xùn)練結(jié)果查看。

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

按照這個流程設(shè)計，即使是統(tǒng)一的業(yè)務(wù)流程，各產(chǎn)品經(jīng)理設(shè)計的原型都不一樣，因為他們的思維方式與思考的點都不一樣。有些就是根本不考慮外在的條件，例如訓(xùn)練計劃是否涉及線下預(yù)約會議室，人員是否有休假沖突等，有些就過度考慮了，導(dǎo)致什么條件都拿來自己判斷，整個系統(tǒng)就很復(fù)雜，確實很細致，但是設(shè)計周期就會很長。

最好的原型設(shè)計是可以清晰表達需求及功能點，各參與方（需求方、開發(fā)實現(xiàn)團隊）都可以很清楚的了解自己的部分。

所以原型設(shè)計說簡單也簡單，說復(fù)雜也很復(fù)雜，這考驗的是產(chǎn)品經(jīng)理對于需求的把控度、原型設(shè)計合理性，能夠在為用戶更好的詮釋解決方案的同時，盡量的降低開發(fā)成本。

2、二八法則設(shè)計

結(jié)合上一篇文章《B端產(chǎn)品之業(yè)務(wù)設(shè)計》，基于流程與功能的設(shè)計，就能完成80%原型，功能為頁面布局設(shè)計提供基礎(chǔ)，流程為交互設(shè)計提供基礎(chǔ)。同樣的是二八法則，產(chǎn)品經(jīng)理根據(jù)自己前期的調(diào)研結(jié)果，比如功能架構(gòu)、流程圖等進行原型設(shè)計，完成80%的原型設(shè)計以及PRD，剩下20%是需要和團隊一塊頭腦風暴，補充或調(diào)整原型，輸出最終100%的原型設(shè)計。

當然也有可能存在返工，比如UI設(shè)計發(fā)現(xiàn)這里布局緊湊調(diào)整，開發(fā)發(fā)現(xiàn)原先的交互方式無法實現(xiàn)，或?qū)崿F(xiàn)出來與預(yù)計的結(jié)果要差，都會導(dǎo)致原型調(diào)整，調(diào)整不可怕，可怕的是推到重新設(shè)計，所以提到80%的原型設(shè)計輸出后就要和團隊進行溝通與澄清，降低返工率，保證產(chǎn)品業(yè)務(wù)設(shè)計核心不偏離。

切記，產(chǎn)品經(jīng)理最忌諱閉門造車，埋頭苦干設(shè)計了很久的原型，有可能在評審階段就當頭一棒。我們同樣要在設(shè)計上預(yù)留備選方案，這樣在調(diào)整的時候才不會覺得全都重新設(shè)計，如果有組件庫那么會更快的完成調(diào)整，后面會講到～

節(jié)奏要學(xué)會自己把控，被動轉(zhuǎn)主動，才不會有那么大的壓力～

3. 原型設(shè)計包含的內(nèi)容

（1）全局說明

原型部分的全局說明主要是指頁面設(shè)計規(guī)范與邏輯設(shè)計規(guī)范，保持全局統(tǒng)一，該部分貫穿原型設(shè)計-UI/UE設(shè)計-開發(fā)-測試整條線。考驗的是各階段負責人的提煉能力，因為需要站在更高維度去審視自己所負責的部分。產(chǎn)品經(jīng)理和設(shè)計師需要全局把握頁面與交互設(shè)計規(guī)范，產(chǎn)品經(jīng)理和開發(fā)團隊需要把握邏輯設(shè)計規(guī)范。

頁面設(shè)計規(guī)范：與交互設(shè)計師/UI設(shè)計師共同完成；這部分主要是規(guī)范設(shè)計上的尺寸大小，交互體現(xiàn)等。

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

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

這一部分可以去看看各大廠出的設(shè)計規(guī)范，可以作為參考，例如優(yōu)酷、餓了么等設(shè)計規(guī)范。

邏輯設(shè)計規(guī)范：與開發(fā)團隊共同完成；這部分主要是規(guī)范通用邏輯的規(guī)則設(shè)計，相比于頁面設(shè)計規(guī)范，這部分規(guī)范要少些。

例如新用戶校驗規(guī)則，接口調(diào)用規(guī)則，成功返回，失敗返回/告警等?。

常用的邏輯規(guī)則可以提煉出來寫在全局設(shè)計中，這樣就不用每一處再去強調(diào)了。

其實規(guī)范全局設(shè)計的同時也在規(guī)范各個階段之后的參與，提高效率的同時也在規(guī)范整體的設(shè)計。

（2）功能流程設(shè)計

將前期整理的功能流程設(shè)計一并放入到原型中，便于功能原型/交互設(shè)計的時候?qū)φ樟鞒踢M行設(shè)計，也便于開發(fā)團隊看原型與流程一起。

（3）原型圖設(shè)計

我看過很多產(chǎn)品經(jīng)理本身就是追求完美的，所以原型設(shè)計耗時非常長，因為他們總想交付最好的原型圖，能夠做細致的地方要做細致。其實原型圖在我們這里，我們只需要通過圖形設(shè)計實現(xiàn)需求表達即可。

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

關(guān)于是否高低保真根據(jù)當前的需求情況而定，大部分情況還是低保真，一是可以快速完成原型設(shè)計階段響應(yīng)需求，二是留給設(shè)計師更多空間，不要限制了設(shè)計師的想象與發(fā)揮，雖然這二者間的關(guān)系也很微妙～

最后就是一直在提的設(shè)計邊界，原型設(shè)計同樣的要注重邊界感。結(jié)合上部分提到的，功能設(shè)計不要冗余復(fù)雜，都是逐步完成的，就像我們實現(xiàn)代步工具，不是一開始造車輪，而是一開始可能就是各滑板車，能夠?qū)a(chǎn)品或業(yè)務(wù)功能主線運轉(zhuǎn)起來才是核心。

因為我自己也是這樣走過來的，原型設(shè)計中會有很多新想法，不斷的去豐富了某個主線內(nèi)容，其實花費了時間還不一定最后會采納，不僅產(chǎn)品經(jīng)理會有這種想法，設(shè)計師，開發(fā)團隊都會有，作為產(chǎn)品經(jīng)理，一定要把握主線，懂得取舍，能夠快速實現(xiàn)產(chǎn)品價值，獲取商業(yè)價值或回報也是很重要的。

二、與PRD的結(jié)合

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

在產(chǎn)品前3年，我的原型設(shè)計稿和PRD是分開的，在一次次和開發(fā)團隊確認需求實現(xiàn)的時候，發(fā)現(xiàn)他們大多時候要么只看設(shè)計稿，要么只看PRD，二者都看的人少之又少。對于每一個個體來說，他們優(yōu)先都會選擇更節(jié)省時間或利己的方式，但是往往PRD和設(shè)計圖是不可單獨閱讀的，需要結(jié)合起來閱讀。

當時在一個產(chǎn)品群里面，也有各大佬分享自己的經(jīng)驗，最后我選擇了將重要交互或說明貼在原型設(shè)計中的方式。采用該方式后，我發(fā)現(xiàn)和開發(fā)團隊的溝通會更順暢一些，當然也還是會存在依然只看文字或圖畫的人，但基于這樣的設(shè)計去溝通，會更快一些，包括復(fù)雜交互的說明也更加容易的溝通。

圖文結(jié)合也往往是人們最容易閱讀和接受信息的方式。

（原型設(shè)計某截圖，重要信息已屏蔽）

三、關(guān)于組件庫的搭建

現(xiàn)在有很多成熟的開放設(shè)計平臺供我們參考，比如阿里的Antdesign Vue、餓了么Element UI、騰訊的TDesgin、Clarity UI Library等平臺。這些會提供基礎(chǔ)的組件樣式，但大部分沒包括交互設(shè)計，但對于我們原型基礎(chǔ)功能的應(yīng)用還是有很大的幫助的。

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

我們有了基礎(chǔ)的組件庫后，可以把自己每一次大的改動或新設(shè)計的組件放在一起，不要為了節(jié)省時間放在一個畫布里面，還是要分類，框架設(shè)計、表單設(shè)計、按鈕設(shè)計等等。

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

我們搭建個人組件庫，是更好的幫助我們?nèi)ネ瓿稍偷妮敵龊驼{(diào)整原型。一是提升我們自己的效率，二是應(yīng)對一些變動也會更快響應(yīng)，也就是我強調(diào)的，原型設(shè)計階段，產(chǎn)品經(jīng)理要把握自己的節(jié)奏，不要被變動或deadline牽著走。

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

現(xiàn)在的各類平臺或工具都在搭建或規(guī)范組件平臺，不僅是方便原型設(shè)計，UI設(shè)計，開發(fā)等，都是比較快速的去實現(xiàn)一些基礎(chǔ)的需求。其實就是將N次重復(fù)的簡單的設(shè)計轉(zhuǎn)為通用可復(fù)用的設(shè)計，理念旨在更高效。

寫在最后

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

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

即使是按照甲方/領(lǐng)導(dǎo)的要求來做，那么也要有自己的思想在里面，如果過程中不思考，慢慢就變成了原型輸出機，不要特別在意結(jié)果（比如想要設(shè)計部分都完全通過），但是該爭論的地方還是要爭論的 ，在某些點該堅持就是要堅持。我比較享受在設(shè)計過程中，大腦的靈活，自己想法或與團隊想法的碰撞，慢慢沉淀屬于自己的經(jīng)驗。

好的設(shè)計一定會發(fā)光，但是有可能不是當下。

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

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