原创： Kevin改变世界的点滴 Kevin改变世界的点滴 昨天
周末两天在忙于PMTalk深圳产品经理大会，每天晚上想更新的时候已经超过了凌晨12点。所以在今天才更新，2天与500余产品经理们碰撞了一些不同的火花，接下来会在后续的原创中不断整理输出。
产品经理在日常工作中，沟通、文档、原型是主要的3个聚焦点。其中原型的输出质量，是可以有效降低沟通，也可能会占据接近1/3的产品经理工作时间
至于原型的评判好坏不仅是可能需要美感，最重要的是产品经理能不能把需求讲的透彻。例如：开发、设计如果第一眼看到原型后，即可明确需求或本次的任务是否合理，假设本次给的开发时间就一个星期，你却原型给出了要3个月才可以完成的任务。显然是对需求没有抓准。
在实际工作中，测试会看产品PRD外，开发与设计都是以原型查看为多。因为原型的图文阅读高效、快捷。
围绕产品经理的原型工作，如何避免开发与设计说：“你的原型我看不懂”或“你的需求整理的不行”等怼场景，今天将围绕3个关键词
分别是：产品框架表达、边界表达、注释说明，谈谈我个人的几点建议。
产品框架表达
产品的框架不管是移动端还是web端，都是从依靠的业务或用户路径来搭建的。我们梳理出业务是什么范围，用户路径有多少。以页面来表达
比如在社区产品中，用户的路径分：作者与游客
1.作者用户的主路径
注册——投稿——结束
2.游客用户的主路径
注册——阅读——结束
上面2个不同的角色中，所使用的产品的核心路径一个是投稿、一个是阅读。私人作者也会阅读，但以主路径来看，其实投稿只有他们这个角色才产生的。
针对这样的表达，我们要想避免开篇所提出的开发与设计的怼话。建议在一开始首先把页面链接给出，如下图。
上面只是罗列的页面，但还缺少路径。也就是页面与页面之间的链接，把业务与用户路径加上，原型的表达整体就非常清晰明了了。
边界表达
边界表达，最好的方式是在原型给予注释。注释的说明在原型中并不要想文档那样针对每个页面都加上。而是以边界或带有逻辑甚至是计算需求的地方进行解释。
例如上图中，所注释的包含了生命数据的计算算法、控件的状态、功能调整入口的说明。这一点也是原型中要求产品经理需求调研的能力，初级产品经理可能一个页面：每一个按钮、每一个文案、每一个弹窗都有注释。
这样显然会增加了原型中需求消化成本，所以针对边界点在原型中注释，常见的是计算方法、条件、状态判断、数值边界等说明是需要注释的。
注释说明
在原型中，一套好的注释可以帮助开发尽可能不去看文档都可以理解需求。我在产品工作中，认为优秀的产品经理输出原型开发或设计的疑问会较少。
在实际工作中，产品经理能力高低的比较场景也是通过开发、设计能不能看懂来评判的。还有要说，每个产品经理都希望自己输出的原型应该是“分分钟”被看懂，因为天天被同事吐槽，工作能愉快吗？
注释说明除了上面的边界外，还要注意几点
区域注释
产品框架说明
功能目的与背景
区域注释是面向功能集合的区域说明，比如在移动端中常见的入口集合
例如美团点评的服务集合，在不同城市会有对应的展示逻辑。为此区域权重注释是大于功能注释的。
区域注释需要与上面的边界注释区分出，保证开发或设计同学在看对应解释不会分不清。另外区域注释的要注意分清什么地方可以使用，什么地方应该使用边界注释。比如功能集合的入口，整体几个功能的逻辑会有成套的条件，区域注释是非常好的。
例如美团点评虽然服务功能都不同，但他们都会有地理位置因素，这是需要区域注释来说明。
做好产品经理，从原型基本功开始
在周末与产品经理们交流的时候，发现在现实工作中也存在原型都不怎么画的产品经理。可能几个截图，加上无数次沟通，还是把产品做出来了。
但我认为，原型技能为什么说是产品经理的基本技能，核心在于你连原型都不会做，如何表达你的需求呢？尤其是当你从产品新人开始，逐渐进阶期间。难道没有经验的你，还能自然的嘴炮说出需求吗？
好啦，今天的原创就在这里，我会坚持每周分享2篇产品案例
推荐阅读：
网友评论