把握用户及需求者对项目的了解程度
分开来说，先说用户。用户的了解度，是用户在体验项目前或体验项目时所要达到的对项目了解的程度。通常为了达到这个目的，所用的手段就是用户帮助及说明书。
在互联网产品的设计过程中免不了这个部分，为了让用户更好的了解使用方法和使用过程，我们会在每个环节都设计一些小提示，在用户错误操作的时候给出说明，还有就是有个假设性的帮助中心。
这一切都是为了给用户解决问题。
项目本身是给用户解决一个大问题，而这些丰富了解度的内容就是给项目体验过程中解决问题。
曾经一度在犯错，错在项目的后期QA中，非常着重对内容解释的强调。告诉用户怎么做固然没错，但很可能出现的问题就是不断和用户去分享项目心得，以为用户会理解或花时间来欣赏。出现最多的就是用大段的文字去解释一些功能，其实是非常愚昧的，因为实际的数据证明，用户根本看不到，并且不会去看，因为他根本不关心这是怎样设计的，为什么要这么设计，对于他来说一点用处没有。
只要给他解决问题，再难用的都能习惯，太过用心有时反而会误导用户。所以对于一项商业计划而言，成功的因素固然有很多，但最最重要的还是必须切合需求，这句是弦外之音。
我的观点是，真正要让其了解项目是怎么设计的，为什么要这么设计的人，是需求的提出者，当然这在一些项目中可能是重叠的。而解释这些问题的原因，就是让其参与来改进一些功能上的需求，解决如何让用户在达到目的的同时也用得舒坦，不用去了解太多就能简单操作，同时也让其更加了解主体项目团队给出的方案很合适。不过需求提出者会分很多类型，根据项目的大小，PM也必须主动把握交待项目细节的程度，适当让需求的提出者给出一些自己的意见，保证不在后期环节来补课（后期的变更会让开发疯掉的），也不过度听从，由于对方的不专业而为公司带来反反复复的负担。
还需要把握这点的就是设计师，因为PM只是完成了内容设计，用户的第一感官必定存在于UI设计上。
记住，用户只需解决问题，知道怎么做就行。除非需要其承担风险或成本，否则不用告诉他用意。