产品原型对于每一个产品经理而言，都有着至关重要的作用。作者结合实际经验，将从原型设计角度出发，主要阐述如何设计产品原型图，产品原型图包括哪些部分以及设计组件库搭建这几个方面阐述，希望对你有所帮助。
前几篇文章从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协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
