2020年全球物联网10大事件盘点

我觉得大部分的业务逻辑，通过这两个图都能表达清楚。一图胜千言，希望你能充分利用好这些利器。

另外，当你真正开始设计一个需求的具体方案的时候，难免会需要再次向提出方确认一些细节问题。这个时候除了确认细节，你还需要确认以下两件事：

1. 时间节点。包括出方案的时间节点，上线的时间节点。这个目的是，将双方的预期做一个校准，免得你这边觉得进度差不多，业务方觉得开发效率太低。
2. 方案的方向。这个目的是，只有这样才能发挥你作为产品经理的主观能动性和创造力，在双方都认可的方向上考虑解决方案，而不仅仅非得100%照着提出者的想法来实现。另外，确定下来的方向也是产品经理和技术人员评估方案可行性时作出取舍的重要参照。

/02 原型设计/

01 突出主次

一个完整的业务场景，必然是有主次的，有主线、有支线。所以我们在基于PRD做原型设计的时候，需要不断思考：

• 什么模块要突出?
• 什么模块要弱化?
• 背后的思考和原理是什么 ?

最怕的就是在一些次要的模块上大费周章，在核心模块反而草草了事。这样会导致技术人员花费过多的时间在低价值的方向上工作，最终的产品效果自然不会太好，甚至会变形。

02 保持一致性

对于某个概念，在整个原型里的体现应该是一致的，小到每个按钮的上的提示，大到一个模块。比如，不要在这个地方叫“汇总”，在另一个地方叫“合计”，这样的问题如果到处存在，给人的感觉是这个原型好乱。

另外，对于在整个产品里多次出现的模块，比如快捷登录的弹窗。有些产品经理会到处复制黏贴，这样很容易改了一个地方漏了其它地方，导致不一致。这

个时候你应该想办法把它提炼出来，让它可以复用。比如Axure里的母版功能。

好了，暂时就想到这么多，你有什么不同的想法或者有补充的，欢迎和我交流哦。

在很多公司，产品经理都是单独一个团队，并不直接与技术人员属于一个团队。在这样的情况下，其实对产品经理的要求是非常高的，PRD和原型设计上需要更加有责任心才行。如果仅仅作为一个“信息的传递者”，出现衰减是必然的。

如果产品经理没有起到粘合剂的作用，其实不如将产品经理团队划分到技术团队里。在我看来，和开发人员穿同一条裤子，总比多衰减一次更好一些。

总结一下。

这篇呢，Z哥和你分享了我对产品经理如何更好地描述需求这件事的看法。

产品经理最基本、也是花时间最多的工作就是写PRD和画原型，前者源于业务，后者输出给技术。但是做同样的事情，并不是所有产品经理都能把需求描述的准确、清楚。

要写出好的PRD，需要：

1. 认真对待需求的获取，接到需求的第一时间，做好判断和记录。
2. 在讨论和设计的时候，多画流程图和时序图。并且在和业务方确认需求细节的时候，同时明确好时间节点和方案的方向。

要做好原型设计，需要：

1. 突出主次
2. 保持一致性

（编辑：盐城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!