聚热点 juredian

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和设计图是不可单独阅读的,需要结合起来阅读。

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

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

(原型设计某截图,重要信息已屏蔽)

三、关于组件库的搭建

现在有很多成熟的开放设计平台供我们参考,比如阿里的Antdesign Vue、饿了么Element UI、腾讯的TDesgin、Clarity UI Library等平台。这些会提供基础的组件样式,但大部分没包括交互设计,但对于我们原型基础功能的应用还是有很大的帮助的。

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

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

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

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

当然还有一点,一些复杂的不常用的组件,不经常使用或设计,不要因为频次低而不放入组件库中,正因为使用频次低,所以才会忘记当初的设计方式,再去百度,也就是花了双倍或多倍时间来完成这个组件设计。我们有自己的组件库,就可以直接用,想要知道如何设计,根据设计逻辑就可以拆分,快速熟悉。

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

写在最后

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

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

即使是按照甲方/领导的要求来做,那么也要有自己的思想在里面,如果过程中不思考,慢慢就变成了原型输出机,不要特别在意结果(比如想要设计部分都完全通过),但是该争论的地方还是要争论的 ,在某些点该坚持就是要坚持。我比较享受在设计过程中,大脑的灵活,自己想法或与团队想法的碰撞,慢慢沉淀属于自己的经验。

好的设计一定会发光,但是有可能不是当下。

我记得在设计活动营销平台 ,因为某一处的设计和公司的黑带大佬(属于凤毛麟角的那种开发大佬),争论了一两个小时,上线后可能一个月了,大佬说我当时坚持的想法是对的,我听到当然很开心,这就是产品经理的小确幸吧。

Tag是自己定义的,从不属于他人。

本文由 @SLJwu 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

搜索建议:
热闻

 挑战者杯KPL战队首败,MTG让...

苦瓜原创,翻版必究!《苦瓜电竞》--让你体验不一样的电竞主播圈!对于喜欢看王者荣耀赛事的小伙伴们来说,又可以热闹起来了,毕竟挑战者杯开始了,等待了这么久,让人期...(展开)