场景1
UI：为什么改需求！
UI：为什么又改需求！
UI: 为什么还要改需求！
我....我...
这个场景在我们工作当中变不少见，因为我们产品要收集各个部门的需求进行开发，使得我们在正常的流水工作中总是出现各种突发需求，从而引发我们和UI之间的矛盾。
一方面来说是需求把控不严格，对于需求列表中的需求没有一个很好地规划，其实很多突发需求没有那么紧急，所以需要我们产品这边来把好这一关；
另外一方面来说是需求的绝对性，在一份成熟的需求文档或者原型中，需求基本是不好变化的，因为它涉及了UI、开发的改动，所以在文档面前需求是绝对的，所以一定要把需求的前前后后想好了，尽量不要在文档给出去后再对原有需求进行改动；
第三个点就是个人交际能力管理，当改动无法避免必须做的时候，这个时候你是需求方，处于弱势地位，所以要尽量控制好自己的情绪，在变动时尽量用温和的语气跟她交流，并详细解释变化的原因让她试着也去理解你，这样相处起来就比较融洽了。当然如果说UI这边态度实在很强硬这时候我们也得学会妥协，毕竟工作不是一锤子买卖，后面的路还很长。
场景2：
UI: 为什么改动的地方这么不明显，还要我跟原图比较么？
UI：为什么你的界面展示这么大，我找东西还得拖半屏？
UI：为什么这个地方没有改动，你依旧给我放上去，这不是给我增加负担么？
我...
在原型与设计稿中间，穿插了产品经理和视觉设计师的交流，交流的顺畅程度有很大一部分取决于你原型图的质量。对于产品本身，我们是为用户考虑设计；对于开发过程，我们在原型图上也要尽量为UI和开发着想，因为他们是我们文档的阅读用户，所以文档上要尽量精简，降低开发设计人员的阅读难度。
另外在文档的要求上，个人主张界面图要小，尽量能一屏展示；逻辑要清晰，界面跳转要做好；迭代地方要标注，哪里需要更改，要在原型图上清楚注明！
