二、提供尽量客观的依据
1、有业务数据尽量提供业务数据作为支撑。
2、没有业务数据寻找第三方数据平台作为支撑。
3、没有数据提供竞品作为参考。
三、拉上双方的负责人
涉及到一些比较大的需求的时候，一定要拉上两边的领导，让他们参与到需求中，因为最后都是要他们拍板的。
最关键是，占用人力资源比较多的时候，可能因为各种各样的原因，你很难去推送这个需求落地，拉上自己的领导可以很好地帮助你。
沟通工作：
一、明确告知开发需求目标
1、不要只告诉开发做什么，而不说明为什么要这么做。你以为不需要了解或者他们一看就明白的东西，往往容易产生理解的歧义。同时这样可以避免没有技术背景或者技术背景一般的人（比如我自己）替开发多想，认为这样实现简单而那样实现复杂。开发可以寻找到实现成本最低的方案，而不是盲从产品的需求定义。对于小公司来说，实现成本尤其是时间成本，是一个非常重要的问题。
2、开发参与到需求的讨论中，这样能调动开发的参与意识和积极性，加深对需求目标的理解，从而避免无用功和不符合需求的情况。
二、给出需求的流程或者结构图
在给出具体功能设计之前，如果是比较复杂的需求，一定要给流程图，主要为了加深需求的理解，形成完成的需求概念。
很多时候，运营或者产品会觉得，这么简单的东西我都说得这么清楚了，你TM怎么不明白啊？ 其实主要就是因为在这个环节上运营或者产品对整个需求的背景，结构和目标早已有了代入感，所以觉得每个细节都理所当然是这样的，但是对研发而言，他们并没有得到完整的背景信息，对细节的理解往往就出现偏差和误判。对彼此功能点的关系，相互的联系了解的支离破碎，那么实现起整个系统来难免会出现问题。

三、具体视图设计的三要素
涉及到具体app的功能时，运营或者产品提供以下三点要素：
1、界面元素：比如哪里是文字，哪里是下拉框，哪里是按钮，怎么排版，如何展现，是浮动还是静止？
2、数据逻辑：简单说就是数据从哪里获取的，要按照什么样的逻辑展现。 获取数据的接口一般是之前单独定义的，每次附上需要调用的接口即可。
按照什么样的逻辑展现，比如说游戏中心有个“热门游戏”版块，前三位可以强运营，三位之后可以根据下载和付费等数据进行一个加权算法的排序，如果你懂这些最好，不懂的话要和技术沟通，看看你希望这个地方出现的内容需要体现什么样的特征，然后根据技术的设计，你需要去思考，这样的逻辑是否符合用户的预期。
3、操作逻辑：界面上可以进行操作的有哪些元素，哪个可以点击，可以选择，可以滑动，操作后出现怎样的反馈，比如显示浮层？打开新页面？
操作反馈在游戏设计里面尤其重要。 想起以前刚做游戏策划的时候，那个时候设计系统总是自嗨于规则的设计，忽略反馈的设计。仔细想想，就算规则设计得再好，如果一刀砍到BOSS身上没有声音、没有血迹，对于用户来有多**。
4、异常处理：这个非常重要！（我曾经因为这个被我们的产品经理教育过，这可是用户体验的关键呐！），最简单的比如用户注册信息填写完成，点击提交之后，网络突然波动，这个时候怎么办？让用户看着界面转菊花吗？是不是应该弹出一个提示框，告诉用户网络异常，请稍后重试的提示？
5、风控：这里的风险实际上可以分为三类，系统风险、人为风险、策略风险。
系统风险：打个不恰当的比方，安卓开放系统下，你的游戏就是有可能被劫持，本地客户端就是有可能被破解，无法避免。
人为风险：风控主要是针对的这个部分，比如运营活动规则设计漏洞、负载均衡不合理、未考虑兼容性问题等等。
策略风险：同样无法避免，这里不多解释了。
沟通方式：
1、注意表达时候的措辞和语气，大家都是合作关系，解决问题才是首要目标，对事不对人；
2、多站在对方立场考虑问题，多想一想为什么他们会这么想；
3、不懂的东西不要嘴硬，承认自己不懂没有那么难堪；
4、明确合作部门的责、权、利；
5、需求讨论结束之后写一封会议邮件，周知参会人员，描述清楚需求背景和会议结论，遵循“who do what by when”的原则即可；
6、给开发留有时间评估工作量，不要今天提需求，明天就要实现。