B端产品设计之原型设计

前几篇文章从B端产品设计的业务、流程设计角度出发，给大家阐述了自己的想法，这篇文章将从原型设计角度出发，主要是原型设计工具，如何设计原型，设计边界，设计规范以及PRD结合这几个方面阐述。

话不多说，开始干货～

一、原型设计工具与选择

现在我们可用的原型工具很多，且大多软件越来越成熟，最初的axure，到现在的摹客RP、mockplus、墨刀、pixso等等。

其中我用的最多的是axure和​​摹客RP​​，所以我从这两款设计工具展开来讲。

axure算是原型设计工具的鼻祖，到现在已经是到RP10了，我个人从RP7开始使用的。axure本身就是最底层的原型设计工具，所以单个拆分的设计单元很多，需要用户来完成组件设计，比如简单的轮播图，现在mockplus已经做好封装组件，直接拖拽即可使用，而在axure中需要用户自己通过动态面包进行组件设计。交互设计的事件较于其他工具来说其内容丰富，例如基于容器的表格设计，可以实现交互上表格的增减。axure就像一块块小的积木（设计单元），用户可以根据自己的需求实现最终呈现形状（原型图），它是丰富多变的，变量可变性大，当然越是底层的东西，需要投入学习的精力就更多。

​​摹客RP​​经过这几年的迭代，内容也变得很丰富，特别是我看到组件库不断丰富，从很大程度上提升了用户输出原型的效率，本身基于底层设计软件开发，会不断完善底层所欠缺的地方，比如直接提供常用组件库、图标库，这一部分大大节省了设计时间，并且还在不停的丰富库内容，相比传统的axure需要倒入组件库更加方便，同时也契合他们“更高效、更易用、更流畅”的产品核心。

（常用组件库&图标库）

（模拟设计airbnb首页）

基于摹客RP我临摹了airbnb首页，差不多10-15分钟的时间就完成了设计（不含交互），可以看出，摹客RP的原型产出速度是很快的，而且适配移动端，可以直接呈现在移动端。

以上来看，axure更适合设计底层系统及中后台系统，有复杂的业务流程，需要较为详细的交互逻辑设计，文字描述等。摹客RP更适合简单明了的业务流程及需求，同时可以快速满足原型产出，其也更适用移动端，可以适配布局，在移动端体验其交互。另外摹客RP在响应频繁变更需求时更具有优势，变动成本低，这一点比axure要好。

简单来说，基于业务、逻辑流程、原型产出时间（deadline）等因素共同决定当下需求通过什么工具实现，任何事情都无需固化，不是选择了axure就不能再适用摹客RP了，工具之间可以相辅相成产出设计成果，更及时的响应用户需求，更好的为用户呈现解决方案，这才是我们最终的诉求。

二、如何设计B端原型

1、二八法则设计

结合上一篇文章《B端产品之业务设计》，基于流程与功能的设计，就能完成80%原型，功能为页面布局设计提供基础，流程为交互设计提供基础。同样的是二八法则，产品经理根据自己前期的调研结果，比如功能架构、流程图等进行原型设计，完成80%的原型设计以及PRD，剩下20%是需要和团队一块头脑风暴，补充或调整原型，输出最终100%的原型设计，当然也有可能存在返工，比如UI设计发现这里布局紧凑调整，开发发现原先的交互方式无法实现，或实现出来与预计的结果要差，都会导致原型调整，调整不可怕，可怕的是推到重新设计，所以提到80%的原型设计输出后就要和团队进行沟通与澄清，降低返工率，保证产品业务设计核心不偏离。

2、原型设计包含的内容

·全局说明

原型部分的全局说明主要是指页面设计规范与逻辑设计规范，保持全局统一，该部分贯穿原型设计-UI/UE设计-开发-测试整条线。考验的是各阶段负责人的提炼能力，因为需要站在更高维度去审视自己所负责的部分。产品经理和设计师需要全局把握页面与交互设计规范，产品经理和开发团队需要把握逻辑设计规范。

页面设计规范：与交互设计师/UI设计师共同完成；这部分主要是规范设计上的尺寸大小，交互体现等。

例如警告类型弹窗，颜色大小，以及交互（倒计时2s自动消失）。

例如一级标题大小24px，二级标题大小20px等。

这一部分可以去看看各大厂出的设计规范，可以作为参考，例如优酷、饿了么等设计规范。

逻辑设计规范：与开发团队共同完成；这部分主要是规范通用逻辑的规则设计，相比于页面设计规范，这部分规范要少些。

例如新用户校验规则，接口调用规则，成功返回，失败返回/告警等 。

常用的逻辑规则可以提炼出来写在全局设计中，这样就不用每一处再去强调了。

其实规范全局设计的同时也在规范各个阶段之后的参与，提高效率的同时也在规范整体的设计。

·功能流程设计

将前期整理的功能流程设计一并放入到原型中，便于功能原型/交互设计的时候对照流程进行设计，也便于开发团队看原型与流程一起。

·原型图设计

我看过很多产品经理本身就是追求完美的，所以原型设计耗时非常长，因为他们总想交付最好的原型图，能够做细致的地方要做细致。其实原型图在我们这里，我们只需要通过图形设计实现需求表达即可。大部分情况下留给产品经理的时间不多，即使时间较为充裕的情况，我们也会因为需求变动或其他情况导致原型设计时间紧张，常见的就是甲乙方，甲方最开始表达的确实是A，当看了原型后，可能会变成A+1，所以最终我们输出的可能是A+N或者是A-N，其实变动都不可怕，我们只要掌握好自己的节奏即可。

例如可以先通过简单的线框图+文字的方式表达，也可以用摹客RP这种方便快捷的工具输出初稿，当然我们无论采取哪种方式，过程和结果可能都是一直在改，这确实是一直存在的问题，乐观面对，通过自己的方式去适应就好了～

关于是否高低保真根据当前的需求情况而定，大部分情况还是低保真，一是可以快速完成原型设计阶段响应需求，二是留给设计师更多空间，不要限制了设计师的想象与发挥，虽然这二者间的关系也很微妙～

最后就是一直在提的设计边界，原型设计同样的要注重边界感。结合上部分提到的，功能设计不要冗余复杂，都是逐步完成的，就像我们实现代步工具，不是一开始造车轮，而是一开始可能就是各滑板车，能够将产品或业务功能主线运转起来才是核心。因为我自己也是这样走过来的，原型设计中会有很多新想法，不断的去丰富了某个主线内容，其实花费了时间还不一定最后会采纳，不仅产品经理会有这种想法，设计师，开发团队都会有，作为产品经理，一定要把握主线，懂得取舍，能够快速实现产品价值，获取商业价值或回报也是很重要的。

三、与PRD的结合

这算是个人设计偏好吧，我在此也与大家分享下。

在产品前3年，我的原型设计稿和PRD是分开的，在一次次和开发团队确认需求实现的时候，发现他们大多时候要么只看设计稿，要么只看PRD，二者都看的人少之又少。对于每一个个体来说，他们优先都会选择更节省时间或利己的方式，但是往往PRD和设计图是不可单独阅读的，需要结合起来阅读。

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

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

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

以上是个人原型设计阶段的一点小心得～供大家参考，谢谢～

摹客RP下载地址：​​https://www.mockplus.cn/rp-event/​​