一、刚入门踩过的坑

1.明确需求和价值
刚入职的时候接到需求，直接上手绘制功能点和页面草图，感觉理解得差不多了，便吭哧吭哧画原型去了。后来发现需求理解不到位以及有疏漏的地方，导致原型要重新绘制，非常浪费时间，这个过程也异常痛苦。
吸取第一次版本迭代的经验教训后，慢慢摸索总结经验开始明白，公司肯定不是招我来来单纯地画画做设计的，产品人的核心价值在于挖掘到用户的痛点，明确产品要开发的需求，并能把需求落地为实际的产品功能，所以产品更多的是业务和需求上的思考，原型只是把我的想法和逻辑最后呈现出来而已，前面每一步都需要走得扎实。
虽然刚开始更多是执行阶段，拿到产品负责人的命题作业，完成某个需求的实现，人会容易习惯，思维也一样，这样长期成为功能的执行者，可怕的是不加以思考之后便再也懒于去思考，所以要常常问自己：
a.明确用户的需求，用户想要做什么？为什么要这样做？这样做能给用户带来什么价值？避免需求理解不到位，造成返工，学会思考要做具有什么价值的功能，什么价值的功能够给用户来益处。
b.用户需求的场景是怎样的？是否能完整地描述并还原用户的真实场景？避免产品设计流程和实际场景有出入，你是用户你也会生气的。
c.我这样实现这个功能是否可用可行地满足了用户的本质需求呢？流程虽然能跑通，思考是否从根本上解决了用户的问题。是否可以更加缩短路径？把一个功能点打磨得更好。

二、明确公司业务背景和逻辑

在刚加入一家公司，产品设计之初，会按照一些固有的思维方式去考虑问题，比如平时购物习惯了电商的评价逻辑是按照商品纬度去进行评价，淘宝里你购物后，会看到订单拆分成了一个一个店铺的订单，点击该店铺的订单里的评价，是对该店铺里一个一个商品进行评价。饿了么美团主要是你在一个店铺里下单后对该店的口味和服务进行一个口碑评价，也可对单个菜品进行点赞。
而在我们的实际业务场景中，是线下的零售生鲜商家入驻到我们农贸市场中，分为了集中收银和分散收银，分散收银也就是你去一家菜摊购物，完成一笔订单交易，而集中收银指的类似我们平时去的大卖场购物，有水果，有零食，选购完了之后直接去收银台进行结算。而当时的业务，集中收银的情况下消费者的小票和会员订单记录里只会显示一笔订单，罗列了购物的商品明细。
针对线上线下的实际场景是消费者去某个店铺购物，不会只关心这家店的葱是不是新鲜的，如果葱不好，我就不在这家店购物了，他更关心的是这个店主营类目是什么，比如我要买一点菠菜、黄瓜还有莴笋，他们家都有吗？以及他们家的整体口碑是不是ok的，比如他们家的菜整体还比较新鲜，所以我决定按照店铺的纬度去进行评价，但是针对集中收银这一特殊情况，我没有考虑到，结果就是消费者只能对这笔订单做评价，而集中收银的这笔订单里面可能出现消费买了多家店铺的东西，难道对一笔订单做出好评，所有店铺都好评了吗？（致命的逻辑出现了）这个致命的问题就在于不了解公司的实际业务，不了解商家的实际场景。
a.当时我去上海生鲜商家那儿驻店了三天，了解了什么是分散收银和集中收银，商户在使用过程中有什么槽点，刚进入一家公司首先先去了解公司服务的人群他们的业务模式是什么，另外做商家服务的产品贴近商家才能帮助商家解决问题。
b.了解公司的产品现在的业务逻辑，有什么功能，自己去体验产品，将业务流程和功能清单都绘制一遍，这样在产品设计的过程当中才会知道会影响到哪些模块。
c.B端产品需要有很强的逻辑性，谨慎，不放过每个细节。

三、产品设计过程中

执行层面的：
1.先评估需求是否合理性（是否需要做，通用，真实场景等维度考量）
2.具体了解下需求的业务场景（谁用，怎么用，用来干啥，是否形成一个体系）
3.拆解需求（信息结构，目前技术的结构怎么设计合理，迭代拆分等）
4.需求设计（交互设计，产品设计）
（下期拆解总结下如何将需求落地产品设计）
宏观层面的：会发现产品的业务规划小到一个版本大到未来季度到半年的规划产品负责人将为之负责，我们也许会很快掌握如何将一个小需求转化为功能点的技能，但是我们无法在短期内决定一个产品的走向和判断他的商业价值，这个还需慢慢磨练，了解公司的商业模式和盈利模式，多看行业相关的信息。

四、克服挫败感
最后说说，现在在一家小几百人的小公司，一来在没人指导的前提着手做一个比较大的功能模块，第一次内部小的开发团队评审，被怼得一半进行不下去回去重做了（w(ﾟДﾟ)w）。在后续的过程中，被开发怼，被UI设计师友善地嘲笑，需求评审完了业务方开始疯狂插需求，小伙伴开发过程中因为文档不清楚经常来回反复沟通，产品开发完了进行提测发现有一些需求进行改动，产品上线后接收反馈有各种的声音，这些都需要小心脏去对抗，更重要的是给自己一些时间，成长得足够专业，让嘈杂的声音和窘境更少一些，做出让自己和用户足够满意的产品。