学习 B 端产品，就看「司马特小分队」
记得文末领资料哦~
产品经理的3重痛苦：
1、画原型，写文档
2、周五晚上被通知周一要交文档
3、基于前2项，改别人的文档
就是这么突然，上周五接了个最高痛苦的活。痛定思痛，我决定分析下痛苦的根源。
01活就是这么突然在公司，产品经理分工的幸福度：
1、幸福指数10：多个人负责一个产品，每人负责部分模块
2、幸福指数8：一个人负责一个产品
3、幸福指数5：一个人负责2-3个产品
4、幸福指数3：只有1个产品经理
5、幸福指数1：合作方的产品经理跑路了
负数就不说了，毕竟不管怎样，我们还是要给自己找点幸福感。
前期从来没有跟进过这个产品，不知道任何信息，突然发来一份原型，对方原稿人已跑路，其他了解部分信息的成员用了1个小时介绍完项目。
硬着头皮上吧，对着需求指标补原型。
02只有页面，规则你猜借用下我们星友群的讨论
虽然把业务规则写清楚是产品文档的必须，但实际上我也发现，很多公司的原型主要停留在页面上，业务规则写的很简单，或者写些无关紧要的点，还有干脆不写的。
关于原型的详略，和团队人员的默契也是有关的，前期开发和产品经理配合不默契，特别是新人加入时，对原有的规则不清楚，产品经理觉得这是常识，但开发觉得没有说明就是不要做。
对产品经理来说，有些规则重复写觉得不耐烦，哪怕是复制粘贴都懒得做，有时候就把规则写在第一页上，比如说统计页面：按组织合并排列，下同。结果不同的开发做的，有的没看到第一页，做出来的结果不尽相同。
那么在交接的时候，不详尽的文档对后面的产品经理是一个灾难，有些规则要靠自己去线上试，先把文档补全，才能开始后面的设计。
所以规范一定是要有的，另一方面是交互的规范。
03交互差异太大不是每个公司都有交互设计师，但产品经理可以拿到市面上的标准规范文档，把适合自己用的规范拿出来。组件就不用说了，Element等组件可以去参考。
但是弹窗规则、编辑方式、返回按钮，面包屑定义等是一定要的。而且全局，最好全项目组，全公司都能形成相对一致的规范。
不然就会像我看这份文档时的诧异：表格上直接编辑？有点诡异。
关于文档的模板，请在公众号回复“需求文档”领取
这次送出交互规范，请在公众号回复“交互”领取
更多完整资料可在星球领取。
规范示例
我创建了一个产品话题讨论群，给大家提供一个讨论产品的地方
加过吐槽群和活动群的小伙伴，就不用重复加群啦
更是有多位小伙伴，通过我们的「系列课程」和「改简历」，成功拿到心仪的offer。每天不用 1 块钱，得到的是可见的成长。悄悄的说，回复「星球」，会有 50 元优惠券哦