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

前幾篇文章從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協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部