文档
对于大型或复杂的项目，需要文档来解释说明，这是其他任何一种沟通方式也无法取代的。文档的缺失，不利于大家正确理解项目，也不利于发现问题。这样出来的结果很难令人满意。
3. 视觉或前端没看懂交互稿要表达的意思，或者是感到存在问题，却没有提出来。
作为交互设计师，我会尽量把交互稿做的精致些，配上详细的说明，但最后的结果总是不如预期理想。
4. 还有很多大家当初没发现的问题，制作完却成了大问题……
面对这些问题，我也在不断的思考解决方法，目前想到的如下：
1. 作为PM，还是要尽量写需求文档。首先，需求文档对理清PM的思路非常有帮助，可以通过它发现自己还有哪些地方没考虑周全;另一方面，它是设计的重要参考依据，靠简单的沟通不可能遍历到所有的用例和需求点;第三，文档可以帮助其他项目成员有针对性的提出问题，而不是感到困惑和无所适从。
也许有人会问，如果交互设计师从一开始就参与到项目中，甚至是参与需求的确定，还要写需求文档吗?答案是肯定的。需求文档可以规范的把需求要点有序的整理起来，对后续提高项目效率非常有帮助。
2. PM不写需求文档怎么办?
将心比心，没有人不热爱自己负责的产品。PM不写需求文档，一定有自己的立场和原因。作为项目组成员，可以总结自己在项目中需要知道和了解的问题，列出一份清单，请PM回答。相信每个PM都不会拒绝为大家回答问题吧。如果觉得对方回答的不清楚，可以继续细化问题，直至回答清楚为止。
3. 需求文档到底要写什么内容，是一个难题。到底什么样的需求文档能合理的概括重点内容，让后续工作顺利进行呢?我觉得这是一个长期的摸索过程，需要PM和交互、开发等角色一起讨论，通过长期的项目实践逐渐得到最适合当前团队、项目状况的文档格式。
前提是：PM及每一个项目成员要认识到大家是一个共同协作、平等互助的团队，而不是领导和被领导的关系。
4. PM不仅提供需求文档，还应向团队主要成员整体讲述一遍思路。前期沟通主要传递想法;中期沟通解决不断发现的问题，迭代需求;后期沟通确认问题是否得到解决。
5. 其他角色以此类推。
类似的项目如果做的多了，在这个过程中，就会逐渐形成规范机制，使得后面的工作越来越轻松。
通过沟通把握微妙的情感：
沟通过程不总是理性的，也有很多感性成分。
大家在一起工作，但又属于不同的部门或小组，时间长了，难免会产生各种小摩擦。正确的沟通，可以尽量避免这些不快，帮助我们更好的工作，或者说更快乐的工作。要想达到好的沟通效果，需要注意以下几点：
1. 放平心态。
不太计较得失，客观的看待问题，保持心情愉快……这些看起来谁都懂，做起来却困难的很，需要不停的在工作中磨练自己的心性。
2. 换位思考
你有没有对某人很不爽的时候?巧合的是，这个人十有八九对你也抱有同样的想法。对待同一个事情，每个人的立场不同，太过坚持自己的想法，就容易造成误解和矛盾。很难说谁对谁错，重要的是客观认识不同的立场，最后寻求一个好的解决方法。意气用事不会带来任何益处。
当你埋怨PM做的不好，沟通不到位的时候，有没有想想自己是不是也在犯同样的错误?自己有没有认真的把设计意图传达给视觉?每个人都有自己的难处，宽容、谅解，做好自己的事，也帮助别人做好他的事情，才能促使更好的结果。
3. 真正认识沟通的意义
沟通是平等的，而不是一方强势的压过另一方。这是一个协作的时代，不是个人英雄主义的时代。
4. 积极主动
多思考、多提问、多表达自己的意见。遇到不快的事情不要急着下结论，或是越想越歪，而是探清事情因果。其实，事情永远不像我们想的那么乐观，也不像我们想的那么悲观。