原型图绘制,不是画几张图就好了

7 评论 22464 浏览 104 收藏 14 分钟

画原型是产品经理们的工作日常之一,不过每个行业每个公司关于输出原型的要求都不一样,如何结合场景具体输出就成了考验产品经理的一点,而要想输出好看的原型就更考验产品经理的能力了。

绘制产品原型是互联网产品经理的基本功,也是从业者的必备基础能力之一。但由于每个公司对产品的原型要求都不同,因此业界也没有一个标准,去衡量一个绝对统一的原型模板。于是当一些产品新人在入职、跳槽到别家公司后,经常会被吐槽原型画的太“粗犷”,或者又过于“精美”导致浪费时间…

原型策划时,具体的产出物虽然无法用统一的标准去衡量,也无法一概而论规定使用何种规格,但是产品经理们还是可以具体场景具体输出。

01 原型绘制的三种场景和形态

业内通识,画原型是产品经理的基本功,但是又有多少人思考过,产品经理为什么需要画原型。同时也正是很多人因为意识不到画原型的目的,所以往往就会忽略这个基本功的积累。

根据产品经理的工作内容和岗位职责,先说说需要画原型的三种场景:

  1. 描述需求:产品经理通过客户调研或发掘,又或者是老板or领导直接向下传达的需求,此时需要产品经理将对方口中所说、心中所想的需求概述可视化,需要形象地描绘出来,以便对方可直观理解、快速达成共识;
  2. 设计协作:在产品开发流程中,对于确定的需求和功能策划,需要在进入UI设计阶段之前将原型稿确认,便于在正式投入精美的设计之前可以先把产品的方向以及功能结构确定下来,避免因为设计返工造成的内耗;
  3. 客户展示:对于一些外包服务型公司,在跟甲方或者客户爸爸确定需求后,需要第一时间将双方理解的内容快速展示出来,以便快速发现问题然后沟通调整,为之后交付正确的解决方案做准备,也同时尽量避免因前期客户信息不同步造成的项目风险;

针对以上三个场景,就诞生了三种典型的原型稿绘制形态:草绘线框图、低保真原型、高保真原型

  • 草绘线框图:三种形态中最为“简陋”的一种,只展示大概的原型界面框架、关键内容和核心的页面流,可以是手绘或使用软件工具。该种形态多用于上述第一种场景,更多是内部协作时需要,快速绘制快速调整,以便尽快得到正确的反馈;
  • 低保真原型:相较于草绘线框图要完整一些,属于工作中常见的一种,尤其是在产品职责分工较细的公司,也是经常使用的一种方式。可展示完整的界面框架、页面内容和页面流,绘制时多采用黑白灰的视觉风格。该种形态多用于上述第二种场景,多用于在工作流程中的交互、设计协作,在保证原型基础的规范性基础上,还可以让专业的交互、视觉设计师有一定的发挥空间;
  • 高保真原型:顾名思义,原型的保真度较高,要求原型页面细节、交互完整且原型视觉饱和,近乎于已开发完成的线上界面,可以亲自示范点击,就像在浏览线上产品一样,只是里面大多为静态数据而非真实的线上实时动态交互。该种形态多用于上述第三种场景,即在向客户交付方案前的成果展示,为了便于趋近真实的产品,方便客户可以快速理解和决策是否要直接投入开发成本,甚至有时会为了更加逼真,会快速开发一个产品demo以供测试和体验。

了解了绘制原型的场景,就可以知道自己在实际工作中的原型,到底需要画到什么程度了。

当然有些公司会制定规则,要求统一使用某个保真度,还有一些比较规范的公司会有通用的原型规范,可以直接拿过来稍加改动,变成符合业务设计的内容即可复用。总之,很多时候其实“画”不是最重要的,而是先搞明白为什么画、为谁画才可以输出匹配任务场景的成果。

02 产品原型如何匹配价值点

产品经理在日常工作中输出产品原型时,也应该时刻清晰一点:画只是过程,不是目的

从产品创意诞生到产品开发上市,原型在其中的作用堪比承上启下。承上可描述顶层需求,启下通过绘制的原型,可以帮助在产品开发流程中下游的设计、技术同事们快速理解、高效开发。

那么既然想要提高效率,就必须在承上启下的中间形成标准和规范,因此就需要思考如何能够在基于公司规范下,快速实现目的以及交付。

产品经理岗位的天然属性就是协作能力,既然要协作就会有协作对象,在工作中经常需要拿自己的输出与上下游进行对接,并争取达成共识。

按照日常的工作内容来讲,产品经理的协作对象无非就是市场/销售、设计/开发,因此产品经理画的原型也应该既要让市场运营、销售人员看得明白,也要让设计、开发理解的清楚。

通过简单拆解协作方的需求,就会明白:

市场/销售人员:更看重解决方案,需要验收你画的原型是否达到他们的需求要求。但因为他们大多属于非产品相关专业人士,因此就要求你的原型需要形象、直观,功能逻辑简洁明了,直接图形化表述方案即可;

设计/开发人员:经常和产品经理打交道,对产品的日常输出也比较清晰,甚至不乏有相关从业经历的同事,因此如果要满足他们的要求,你的原型还需要经得起复杂逻辑的推敲和梳理,除了具备主业务流程之外,异常场景的逻辑也理应充分表示;

  • 对设计来讲,可能更关注原型的交互样式和体验,专业的设计会考量你的原型交互是否符合系统、平台规范,是否还有其它更加符合用户体验的设计方式;
  • 对技术来讲,可能更关注原型的交互逻辑和性能,会考量功能设计的逻辑性和耦合性,对于正常、异常的边界阈值是否都定义清晰,甚至还会要求你决定技术方案。

为满足协作方的需求,或许可以整理出一个完整的、通用的原型标准:结构可视化、交互高质量、技术可读性。

与此同时,还可在交付时针对不同交付对象体现对方关注的点,比如前期给市场、销售验收时,界面美观整洁,页面流转逻辑清晰,在取得认可的基础上完善功能设计规范细节以及交互说明,便于后续工作跟进。

如果具备了这些要求,再结合具体的公司规范,你的原型就可以匹配协作方的的价值点,也就会是一个“好看”的原型了。

03 画出“好看”的原型,需要具备哪些基础能力

一份高质量的原型产出,通常要求产品经理们首先要具备相关专业能力,同时还需要有较高的执行力、审美能力、逻辑能力,恰好这些能力也是可以在工作中培养的。

  • 高的执行力是职场人应具备的通用能力和职业素养。在需求任务传达后,基于对需求的准确理解,可以快速产出合格的原型,同时在任务前期不必执著于细节,快速将完整的流程、逻辑跑通,然后在完善细节内容,这样可以有效减少任务延迟的风险;
  • 审美能力的提升虽然不需要像设计人员那样经常临摹高质量的作品,但是也需要经常体验行业标杆产品,通过多次、深度体验别人的家产品为何如此设计,从而感受产品优良体验的细腻之处。如苹果系列的产品,不论是硬件还是软件界面,都倾注了无数经典的设计原则,是值得我们去思考和体验的。
  • 逻辑能力在原型上主要表现在描述交互说明方面,一个是书面化的逻辑能力,另一个是业务逻辑能力,这两个缺一不可。书面化的逻辑能力欠缺,产品想法再完美也会因为别人看不懂而来回扯皮;业务逻辑能力欠缺,书面化能力再强,业务逻辑跑不通、异常场景缺失,直接导致技术无法开发也会来回扯皮。因此为了提高协作效率,减少扯皮内耗,就需要产品经理们提升自己的综合能力,同时也体现自己对工作负责任的态度。

专业输出直接体现对当前所从事工作的态度和能力。如果基本的原型产出不合格,很容易被认为是工作态度或者能力不行。能力不行,如果有合适的平台也可以培养,但是态度不行就说明不适合从事相关工作,无法为工作负责,也就很难让别人信服你可以为他们设计出人人都喜爱的产品。

04 原型图绘制的“价值观”

原型的概念意义和价值不仅体现在互联网产品上,最早也体现在硬件产品的建模设计、影视剧的分镜稿等,此类工作场景都是运用“先粗后细”、不同阶段交付不同程度成果的思路,通过及时协作来达到最终的目的。

上述的三种程度的原型,其实也是在策划需求时不同阶段的产物,随着需求的确认,原型也会逐步丰富起来,因此在多数公司也并不是明文规定只允许输出某种规格的原型文件,还是需要产品经理们根据实际需要、任务周期以及交付目标综合考量,同时秉承着“先完成、再完美”的绘制思路,在正式交付前可以输出一份高质量的产品原型。

这里所谓的高质量并不是要求原型有多好看、配色多饱满,而是在具备上述原型标准的基础上,在交付时体现出来的理想态,交付时的输出越贴近理想态,你的原型就越合格,当然也就越“好看”。

由此思考下来,产品经理的原型基本功也就并没有想象的那么轻松了,自然也不会只是打开axure、墨刀随便拖几个矩形、图标就可以的,而是需要产品经理在明确原型的场景、交付对象以及需求业务后,通过专业的图形设计来清晰的表达解决方法的过程。

 

作者:王曙,公众号:曙Ouba,分享产品思维、职业经验,一起知“曙”达理,做自己的产品经理。

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

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 直接做成 gif 不就行了
    画也是画线框图, 线框图画好后拿给 UX 参考,UX 觉得没问题, UX 最后确定布局, 做成可点击的原型, 然后做成 gif

    来自加拿大 回复
  2. 内容有点水,基本上相当于废话。

    来自河北 回复
  3. 挺纠结的,所在的公司原型是做个领导看的,相当于一个高保真无交互的原型。前期领导会抠各种原型的样式问题,例如一个区域是卡片列表还是分割线列表。常常给到设计师的时候,设计师只剩下填色和简单的优化。

    回复
  4. 呃…这是怎么了?磕到键盘上了哈哈😄

    回复
  5. 码字无图就别侃侃原型图了,误人子弟

    来自浙江 回复
    1. you can you up。误人子弟

      来自广东 回复
    2. you can you up

      来自北京 回复