产品经理 交互设计

开发与设计说:“你的原型我看不懂”,问题是?


周末两天在忙于PMTalk深圳产品经理大会,每天晚上想更新的时候已经超过了凌晨12点。所以在今天才更新,2天与500余产品经理们碰撞了一些不同的火花,接下来会在后续的原创中不断整理输出。



产品经理在日常工作中,沟通、文档、原型是主要的3个聚焦点。其中原型的输出质量,是可以有效降低沟通,也可能会占据接近1/3的产品经理工作时间


至于原型的评判好坏不仅是可能需要美感,最重要的是产品经理能不能把需求讲的透彻。例如:开发、设计如果第一眼看到原型后,即可明确需求或本次的任务是否合理,假设本次给的开发时间就一个星期,你却原型给出了要3个月才可以完成的任务。显然是对需求没有抓准。



在实际工作中,测试会看产品PRD外,开发与设计都是以原型查看为多。因为原型的图文阅读高效、快捷。


围绕产品经理的原型工作,如何避免开发与设计说:“你的原型我看不懂”或“你的需求整理的不行”等怼场景,今天将围绕3个关键词


分别是:产品框架表达、边界表达、注释说明,谈谈我个人的几点建议。


产品框架表达


产品的框架不管是移动端还是web端,都是从依靠的业务或用户路径来搭建的。我们梳理出业务是什么范围,用户路径有多少。以页面来表达



比如在社区产品中,用户的路径分:作者与游客


1.作者用户的主路径


注册——投稿——结束


2.游客用户的主路径


注册——阅读——结束


上面2个不同的角色中,所使用的产品的核心路径一个是投稿、一个是阅读。私人作者也会阅读,但以主路径来看,其实投稿只有他们这个角色才产生的。


针对这样的表达,我们要想避免开篇所提出的开发与设计的怼话。建议在一开始首先把页面链接给出,如下图。




上面只是罗列的页面,但还缺少路径。也就是页面与页面之间的链接,把业务与用户路径加上,原型的表达整体就非常清晰明了了。


边界表达


边界表达,最好的方式是在原型给予注释。注释的说明在原型中并不要想文档那样针对每个页面都加上。而是以边界或带有逻辑甚至是计算需求的地方进行解释。



例如上图中,所注释的包含了生命数据的计算算法、控件的状态、功能调整入口的说明。这一点也是原型中要求产品经理需求调研的能力,初级产品经理可能一个页面:每一个按钮、每一个文案、每一个弹窗都有注释。


这样显然会增加了原型中需求消化成本,所以针对边界点在原型中注释,常见的是计算方法、条件、状态判断、数值边界等说明是需要注释的。



注释说明


在原型中,一套好的注释可以帮助开发尽可能不去看文档都可以理解需求。我在产品工作中,认为优秀的产品经理输出原型开发或设计的疑问会较少。


在实际工作中,产品经理能力高低的比较场景也是通过开发、设计能不能看懂来评判的。还有要说,每个产品经理都希望自己输出的原型应该是“分分钟”被看懂,因为天天被同事吐槽,工作能愉快吗?


注释说明除了上面的边界外,还要注意几点


  • 区域注释


  • 产品框架说明


  • 功能目的与背景



区域注释是面向功能集合的区域说明,比如在移动端中常见的入口集合



例如美团点评的服务集合,在不同城市会有对应的展示逻辑。为此区域权重注释是大于功能注释的。




区域注释需要与上面的边界注释区分出,保证开发或设计同学在看对应解释不会分不清。另外区域注释的要注意分清什么地方可以使用,什么地方应该使用边界注释。比如功能集合的入口,整体几个功能的逻辑会有成套的条件,区域注释是非常好的。


例如美团点评虽然服务功能都不同,但他们都会有地理位置因素,这是需要区域注释来说明。



做好产品经理,从原型基本功开始



在周末与产品经理们交流的时候,发现在现实工作中也存在原型都不怎么画的产品经理。可能几个截图,加上无数次沟通,还是把产品做出来了。


但我认为,原型技能为什么说是产品经理的基本技能,核心在于你连原型都不会做,如何表达你的需求呢?尤其是当你从产品新人开始,逐渐进阶期间。难道没有经验的你,还能自然的嘴炮说出需求吗?





好啦,今天的原创就在这里,我会坚持每周分享2篇产品案例





推荐阅读:

坚持一年,招募100个产品经理


我的第一本书,给你们



广东省深圳市福田区福中三路

Talking

发表