2023年B端产品设计之原型Demo设计

B端产品设计之原型Demo设计前几篇文章从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和设计图是不行单独阅读的，需要结合起来阅读。

当时在一个产品群里面，也有各大佬共享自己的阅历，最终我选择了将重要交互或说明贴在原型设计中的方式。采纳该方式后，我发觉和开发团队的沟通会更顺畅一些，当然也还是会存在依旧只看文字或图画的人，但基于这样的设计去沟通，会更快一些，包括简单交互的说明也更加简单的沟通。

图文结合也往往是人们最简单阅读和接受信息的方式。

（原型设计某截图，重要信息已屏蔽）

三、关于组件库的搭建

现在有许多成熟的开放设计平台供我们参考，比如阿里的AntdesignVue、饿了么ElementUI、腾讯的TDesgin、ClarityUILibrary等平台。这些会供应基础的组件样式，但大部分没包括交互设计，但对于我们原型基础功能的应用还是有很大的关心的。

说到这，作为产品经理，我个人也会常常找UI伴侣要一些设计网站看看，知道当前流行的设计元素、设计风格等，对于原型设计也有肯定的关心，其实还是需要丰富自己的设计思维的。

我们有了基础的组件库后，可以把自己每一次大的改动或新设计的组件放在一起，不要为了节约时间放在一个画布里面，还是要分类，框架设计、表单设计、按钮设计等等。

例如：常见的登陆页面，会涉及到的，密码输入隐蔽明文，密码输入错误弹窗、勾选登陆协议等等。另外包括表单设计、搜寻框等，这些很常用的都可以作为组件的组件库。

我们搭建个人组件库，是更好的关心我们去完成原型的输出和调整原型。一是提升我们自己的效率，二是应对一些变动也会更快响应，也就是我强调的，原型设计阶段，产品经理要把握自己的节奏，不要被变动或deadline牵着走。

当然还有一点，一些简单的不常用的组件，不常常使用或设计，不要由于频次低而不放入组件库中，正由于使用频次低，所以才会遗忘当时的设计方式，再去百度，也就是花了双倍或多倍时间来完成这个组件设计。我们有自己的组件库，就可以直接用，想要知道如何设计，依据设计规律就可以拆分，快速熟识。

现在的各类平台或工具都在搭建或规范组件平台，不仅是便利原型设计，UI设计，开发等，都是比较快速的去实现一些基础的需求。其实就是将N次重复的简洁的设计转为通用可复用的设计，理念旨在更高效。

写在最终

我知道现在好多产品经理睬自嘲自己是“原型仔”，虽然有肯定玩笑话在里面，但是这一部分的确也反应了，许多时候产品经理的设计被吐槽，甲方、领导、开发团队、甚至测试等，甚至全部人都可以吐槽产品经理的设计，别怕，也别有压力，假如我们设计的东西都没人吐槽，那这个产品也就不需要了我们了吧，哈哈。

放轻松，坦然面对就好了，压力许多时候来源于自身。

即使是根据甲方/领导的要求来做，那么也要有自己的思想在里面，假如过程中不思索，渐渐就变成了原型输出机，不要特殊在意结果（比如想要设计部分都完全通过），但是该争辩的地方还是要争辩