沟通
1. 用户需求获得不明确
用户需求获取的途径有很多，比如：老板，同事，用户评论等等。
这些人表达观点的时候可能并没有经过深入的思考，提出的问题是片面的，比如同事和我说这里用这个逻辑这样显示一下内容。如果我二话不说的接了这样的需求，恰恰这套逻辑在产品中的其他内容中是互斥的怎么办？这是作为产品经理需要思考的，你作为产品的主人需要对产品了如指掌，不只是前端，最好后端的逻辑、数据库结构也能熟悉，这样就可以避免因为一些需求踩坑。
后来我给到的解决方案是，将系统中的这一内容的显示统一到某个字段上取代复杂的逻辑，用户可以直接修改字段名称，这样系统中的名称就可以确保一致性。
2. 产品需求表达不明确
这种情况在与开发沟通中常常会遇到的，比如你给出的需求中有一些问题，需要进行变更，开发也觉得这个变更很简单，于是就一股脑去开发了，结果做出来发现你们想的根本不一样。
我在工作中就遇到了这种情况，当时我们在开发成绩的修改功能，但是因为一些学校历史数据的原因，我们需要将修改分为两个功能来做，这个拆解的过程我们理所应当的觉得开发明白了，但是实际开发者并不是当时与我们讨论这个需求的那个开发，需求经过二次描述之后就变了。
导致后来这一块花了很久的时间的捋清逻辑。
所以，不要觉得需求小，能写下来或是画出来做个记录最好，做好需求版本记录非常重要，哪怕再小的一个逻辑都可能在未来产生蝴蝶效应。
决策
1.不要乱作决策，但也不要不做决策
一种是瞎蒙，这种状况久了就像烽火戏诸侯，以后开发会知道你整天就在瞎说，不过脑子的，瞎想需求；
一种是害怕决策，对开发说：你们觉得呢，其实都可以。结果后来用户用起来的时候又要改改改了；
如何避免这两种情况的发生呢？简单来说，就是不知道的话就去调研，就去问清楚；如果还是不清楚的话，想想几种方案的利弊，长期的短期的，另外，往往我们有些时候不光想的是：用户希望的是什么，还会想老板希望的是什么，开发希望的是什么，这听上去就非常难分析的清楚，所以只有将用户放在第一位，去想对于他们那种是合适的，这种说服力也是最强的（老板放最后哈哈哈）。
2. 决策的时候需要放长线钓大鱼
决策是规划中最重要的事件，好比一个个岔路口，如果能够步步为营当然可以更快取得成功。但是步步为营非常困难，只有决策的时候多想几步，就好比手中拿着地图，多plan几种方案，总比瞎转悠好。
需求分析
这是最基础的一部分，但是也是最需要锻炼的一部分
1. 整理需求，规划需求
需求是复杂的，维度有很多。往往我们会按照紧急程度，开发的难易程度，开发的价值角度去衡量。一多就乱肯定不行，你给了开发一个不紧急的需求结果开发了一半给上了一个紧急的需求，开发在这种情况下的切换也是有损耗的，就像写文章写到一半断了一样。
2. 对于不同的需求进行重组，化繁为简
做了一遍，但是做的太定制，无法复用，但是现在去做一个通用性的又没时间。
比如，系统中有不少的问卷类的需求，那么我能不能设计一个通用性的问卷模板组件能够兼容更多的需求，提供更多可复用的模块；但这又引来一个问题，通用性和定制性的平衡，往往通用性强的产品在规划时的前期成本是巨大的。
3. 避免交互设计留下的体验问题
想要把交互设计好，无非是让自己进入场景，让自己在不同的情况下都能用好这款产品，想想自己的交互，再参考一下别人的交互，体会使用这种交互时的感受。
我常常会想用户希望怎么用这款产品？如果我写这个产品的说明书会怎么样？
一款具有优秀用户体验的产品，说明也应是简洁的，写起来可以条理很清晰，如果需要繁复的解释，那说明交互设计的存在问题。
交互非常神奇，小到一个按钮的样式，或是按钮文字，一句提示语。这种无形的东西却是用户能否顺利使用的重点。所以不要忘记这些细节，细节往往决定成败。
