今天我们不聊产品设计方法，我想和你聊聊这9年里我对产品认识的一些变化，希望能够给正在成长的你带来一些启发。
我的第一次产品启蒙
产品设计不仅仅是画画，更应该思考怎么去解决用户在某个场景下的具体问题
9年前是2010年，我刚上大学，学的是工业设计，对于未来要做什么，并不清晰。
与其说不清晰，不如说不喜欢，我不喜欢画画，也很难想象这可能是我未来的饭碗、我不喜欢学设计史，因为我觉得太乌托邦了，只有信念，却没有实际应用的地方。
直到大学二年级，开设了产品设计课程，那是我第一次将产品与用户联系起来，也是一次感受到专业上的重生。我喜欢分析问题，喜欢在课堂上表达，这让我仿佛回到了高中，拿到了一个很难物理题，非常兴奋！这是我第一次对产品有了理解：“画画只是一种表达，产品设计更应该去思考怎么去解决用户在某个场景下的具体问题”。
这个意识对我影响很大，有次我爷爷让我帮他看一下这个药怎么吃，我下意识地思考我该怎么解决爷爷看不到药品上非常小的药品信息这一类问题；后来我设计了一个带有触点的二维码的药盒，只需扫一下，就可以听到关于这个药该怎么吃。后来这个作品获得了中国太湖奖一等奖，政府奖励了两万现金。
工业产品设计思维上的积累与成就让我误以为我同样可以驾驭互联网产品设计，结果被打脸了，很疼的那种。
从工业产品到互联网产品思维转化失败的原因
对于互联网产品设计细节的缺失
2014年工业设计毕业的学生多了一个新的选择–互联网产品设计，遗憾的是，我未能抓住这样的机遇。我当时一直没想明白一个问题，为什么我测试题表现很好，一到面试就嗝屁！后来我终于找到了原因，在工业产品到互联网产品思维转化过程中，我没准备好。我知道可以在药品盒上贴上一个可以让用户识别药品服用信息的二维码，却不知道在登录页标记用户上次使用的快捷登录方式可以省去用户来回尝试的成本。
第一次实习面试失败的原因是没回答出某类设计细节有哪些具体的应用；第一次大厂校招面试失败的原因是没能回答出怎么给父母规划一次旅游；第一次大厂社招面试失败的原因是没能解释清楚作品集中的一个细节点；第一次中厂面试失败原因是我没能回答出对方产品的改进细节点。
我喜欢火影忍者里面佩恩对鸣人说的一句台词：“感受痛苦吧，体验痛苦吧，接受痛苦吧，了解痛苦吧，不知道痛苦的人是不会知道什么是和平”；我稍微改了一下这个台词：“感受细节吧，体验细节吧，接受细节吧，了解细节吧，不知道细节的人是不会知道什么是互联网产品设计的。”
为了理解细节，我迈上了互联网产品设计的自我救赎之路…
互联网产品设计的自我救赎
落好地并不容易，且行且珍惜
毕业后，进入一家社交领域的公司，这里节奏非常快，两周一个迭代，我们曾经只用了国庆7天的时间，就做出一款别人可能需要两个月的应用。
加入这家公司之前，我还是那个空有愿景，但却从未感知过细节的伪互联网产品设计者。第一次版本的迭代是老板带着我做的，他经常把我喊到会议室，然后他用水笔在白板上描述他设计的细节，当时我是震惊加激动的，震惊的是原来产品设计细节可以被构思的如此巧妙，并且这个细节确实能够很好地解决对应的用户问题！激动是，我幻想着有一天我也可以成为他那样的人。
不仅是白板上的演示，我第一次看到老板的原型、流程图也是非常震惊的，他的想法已经淋漓尽致地拆解到这些细节上面，而且几乎没有任何多余的修饰。
国庆前夕，老板召集了一帮自愿加入X项目的小伙伴们，老板给我们每个人发了一个牌子，我的是“首席产品经理”，这个项目由我来跟。我以为前期跟老板已经学到了到很多，这些经验足以让我胜任这个项目。但实际做的过程中，我的问题还是暴露了出来：细节考虑不全、规则描述不清晰、已经制定好的规则对其他场景产生了冲突。我很庆幸那段时间，后端老大经常批评我，这种批评让我感到很充实，每天都在进步。国庆后，我们顺利完成了这个产品。
之后我又负责了一个超级复杂的需求，这次我又犯了同样的错：规则、细节没交代清楚；已经交代清楚的细节，他们已经忘记在哪看了。这直接导致我这个项目失控了，我不知道开发已经做了哪些，我不知道开发当前正在做的有遇到什么困难，后来这个项目不仅延期，而且还做错了很多细节。这件事对我打击很大，我想解决这个现状，避免下次再遇到。后来我发明了一种需求-测试一体的需求规格描述文档：开发之前，我会把方案涉及的所有规则按照该文档的格式去做一个清单，便于开发查找；上线前再对照这些清单进行产品自测。后来这个需求规格描述文档，我一直沿用至今。
离过年还有两个多月，老板让我完全负责一个版本的迭代，这次为了能够让需求稳稳地落地，我充分汲取了前面的教训，将需求按照需求规格文档进行拆解，并做好上线前的自测与跟进，最后我拿到了一个还原度非常高的迭代版本，那次之后，我们的次日留存从最差的30%多，提升到50%多。
经过一年的高强度锻炼，让我感觉互联网产品设计的自我救赎之路已经走的差不多了，这次来到了十字路口，要么继续向前，要么左转，我选择了左转，走向了我的进阶之旅。
互联网产品设计的进阶
如何让我们再靠谱点～
做好一个产品光靠落好地还是不够的，虽然做产品与做功能的落地流程是一摸一样的，但最后产出的结果却截然不同：一个推动产品有条不紊地向鼓心迭代，而另一个则永远在鼓边徘徊，直到把体力耗进，临死都不知道鼓心长啥样。滴滴为了避免这一不靠谱的现象，90%的产品都需要经过俞军的亲自面试。
之所以会有不靠谱，就是因为我们只记得怎么执行却忘记了如何做事，而这次左转让我学到了如何做一件靠谱的事：
做一件事之前，请先了解现状是什么
明确当前产品现状是什么，从数据上来看产品当前的问题是什么，这个问题值不值得去解决，价值的天花板在哪？
别总关注我要怎么做：我要优化一下这个首页，比起某个竞品，这个实在太难看了；我想到一个改变整个行业的idea，巴拉巴拉…
做之前，不去了解现状，很可能会导致你之后的一切努力都是白费，因为那可能就不太是个问题，只是你以为。
这里补充一个比较失败的故事：
背景是这样的，很多摇一摇进来的用户都是沉默用户，即这部分用户可能是误操作进来的，业务目标是降低这样的沉默用户数量，提升有效用户转化率。
但会上讨论讨论着，看到招商银行的摇一摇加载动画，于是就变成我们要做一个加载动画，并且衡量这个加载动画的指标是降低新用户的跳出率，接下来我坑痴坑痴做了几套加载动画方案，最终选择一个开发上线了。
尴尬的是，总结的时候，发现之前压根就没有新用户跳出率这一数据，即新用户跳出到底是不是个问题，我也不知道。
所以，做之前一定要把现状、问题确定清楚！这些是你的主线，不至于被别人乱发散，本来要做一个A问题，最后给出了一个B解决方案，关键是B问题到底是不是个问题，只是听别人YY的。
明确现状过程中，我们只需要关注整体数据即可，如某个功能的日活/留存，而无需关注功能内的细节数据，如某个节点转化情况情况。
找到导致产品当前问题的“用户因素”是什么
这里的用户因素可能是心理层面的考量，也可能是认知层面的行为影响。需要注意的是这些因素必须有数据支撑，或者至少经过验证。挖掘“用户因素”时，需要根据研究对象确定数据范围，从数据细节/节点中找出“用户因素”。具体的挖掘方法有两种：一种是自上而下推导出用户因素，然后再找数据验证；另一种自下而上分析现有数据模型，从数据节点中抽象出用户因素。
以自下而上分析现有数据模型为例，比如从分享率指标上来看，产品当前问题是关于某个分享使用情况比较差，对应到用户因素就可能有以下几点：
用户不想分享（心理层面考量）：因为从数据上来看：有1000人主动触发了分享，只有200人尝试，分享意愿只有20%；
误操作（行为影响）：因为从数据上来看：1000人主动触发了分享，但有800人却未表态，误操作率高达80%；
流程导致的（行为影响）：因为从数据上来看，有200人进入分享，只有60人最终点击了分享入口，流失率高达70%；
社交因素影响（心理层面考量）：因为从数据来看，60人调出了分享入口，只有5人选择分享到微信朋友圈，流失率高达91%。
结合当前产品设计，分析导致“用户因素”的体验细节问题是什么
这是我在自我救赎中获得的技能，即所有问题最终必须归结到产品自身，只有这样才能落地，造成用户当前所思所想，一定是由于产品当前的体验细节引起的，我们需要掘地三尺把这些细节问题找出来。比如从数据上来看用户误操作情况比较严重，归结于产品自身的设计是因为入口位置距离其他触控地方很近，比较容易误点到。
改进当前产品细节
做方案不是考试，作弊、抄袭并不可耻，明确要改的产品细节点，剩下的就是出方案，我们的目标是找到最好的方案，解决用户问题/用户因素。闷头憋大招，大概率憋出的都是蹩脚的方案，然而市面上已经有更好的解决方案了，你还在那傲娇“抄袭可耻，我就要蹩脚”。
总结. 我这9年的成长心得
一定要坚持定期复盘
你可能会困惑为什么今年啥沉淀也没有，原因就是你只顾着往前跑，却不曾停下来，回头看看。工作中很多人其实并没有很好的复盘意识，每天把自己搞的很忙，不停的做，不管对不对，企图通过这种战术上的勤奋来掩饰战略上的懒惰。不经复盘的项目经验只是在初级水平阶段重复无谓的量变，而每次复盘都可能是一次经验质变的过程。我最近更新的文章都是源于我复盘后的思考，这些思考也在未来指导我该怎么做可以更好。
复盘的最直接方法就是写作。2015年10月我的第一段实习结束，抱着尝试的心态在人人都是产品经理社区投了一次稿，审核竟然通过了，社区的认可给了我很大的写作动力与坚持下去的兴趣。
2015年10月28日，我分析了支付宝9.2.0改版，人人都是产品经理社区将这篇文章推荐到网易新闻科技频道，当晚我刷到了自己的文章，激动地叫起了室友。后来认识了主编Nario，我成为了社区的一名专栏作家，这让我更加用心对待写作这件事。
随着后面越来越用心，自己的产出越来越多，文章也会陆续被人人都是产品经理公众号转载、登上社区官网的首页推荐、被推荐到36氪、创业邦等优秀媒体，2016年入围了人人都是产品经理优秀专栏作家。
但后面有点飘了，开始随性所欲地表达，结果经历了几次退稿。我挺不好意思的，但主编Nario还是很耐心地帮我指出了文章中的问题，并给了我很多的建议。
我开始思考我写作的目的到底是什么，为了获取更多的粉丝？保持更新频率，向关注我的粉丝刷存在感？在主编Nario这儿，我得到了答案，我希望自己产出的东西是优质且深度的，能够在别人遇到相似问题时帮助到他们，启发他们解决当前的问题，这才是我写作的目的。于是我删除了近期质量与深度还不够的内容，我宁可两个月用心产出一篇有质量、有深度的干货，也不要为了涨粉去做一些营销，伤害对我有期待的人。
如果你热爱，那么请一直坚持下去，时间会给你答案
如果说在人人都是产品经理社区写作给我带来的最大改变是什么，那一定是把热爱的事情认真地坚持下去。没有什么比认真做一件事更可怕了，写这篇文章时，已经是我坚持细节积累打卡的第7天了，他给我带来了一个非常明显的变化，就是做方案时，思路比一个星期前要开阔多了；我朋友圈有个同学坚持英语学习打卡已经第八十二天， 她每天都在坚持在做这一件事。
机会始终是留给有准备的人的，张无忌之所以能够战胜八大门派是源于平时的内功积累，又是九阳神功又是乾坤大挪移，所以明教教主的机会就是为张无忌准备的。希望我们在工作当中也要做这样的张无忌，潜心积累，少点浮躁，时间一定会给你答案。
最后，贴上一段我每天用来警示自己的话
1.发现问题
明确自己在每个阶段要做什么：
a.能够自我驱动，不是等着别人安排活，自己只有多用，才能发现别人看不到的问题；
b.不趋炎附势，有独立主见，不是上游/领导说什么就是什么。
知道自己为什么要做这个，从业务上来看，到底是提升产品营收还是获取更多用户或者提升用户忠诚度：
不瞎做，不要做成某种感觉、某种愿景，那都是不能分辨主要矛盾，纠结次要矛盾的温室产品，在那闲着没事自我扯淡。
2.定义问题
理解产品问题/产品目标下的具体用户问题是什么：
a.拒绝模糊、空洞的需求，必须拆解到用户具体的使用/体验问题（1、2、3…），没有拆解到这种颗粒度，就不要提需求；
b.假设为主，调研为辅，可能的用户问题有哪些，最好在这之前就有假设，带着假设去问，而非盲目问用户到底需要什么；
c.不拍脑袋、不迷行，要坚持科学发展观，任何一条用户问题在没经过验证之前都只能叫假设。假设不能知道方案设计，无论这条假设是谁提出来的，哪怕是某个资深用户，或者是你的上司、老板，验证的唯一手段就是数据，因为数据不会骗人。如果你已经有了原始数据，直接验证即可，如果还没有就做A/Btest。
3.解决问题
针对一个个具体的用户问题，我们对应的方案有哪些：
a.脱离问题去整方案乃大忌，流程上的优化、UI上的改进或者其他手段，必须映射到具体的用户问题，如果映射不到就别浪费实践去设计；
b.不会做请老老实实抄，这里不是考试，多看别人是怎么解决这个问题的，不要闭门造车。
以上就是我的故事，希望能够在工作中给你带来一些启发。
