背景介绍：（1）我们做的是对b端的产品，web端和app都有，整个开发流程基本一样，只是有些功能app用原生做不需要做html页面；（2）产品组有一个同事负责项目管理，同时也负责金融的产品；（3）我们有专门的交互设计师。
目前遇到的困扰有：（1）迭代周期长、效率低下；（2）用户体验差；（3）苦乐不均。这里先抛开“人”的问题，只从流程上找导致问题的原因和改进办法。所以，先看一下我们现在的产品开发流程，见下图（省略了一些细节和异常流程）：
（1）产品方案评审后再处理交互。之前每次产品评审的时候，开发针对原型都会提出很多交互的问题，可能是原型上没做相关交互，也可能交互方式不合理，然后再根据提出的问题改。谁来改呢？一般来说是逻辑上没有问题，应该是交互同学来改。但是事实上不完全是，大部分仍然是产品自己改，因为交互和产品用的原型工具不兼容！另外，交互稿出来之后一般是不再评审的，直接发给产品同学看下，没问题就扔给视觉和研发。然后就视觉、研发、测试的同学经常就跑来问我，这块的交互怎么处理啊？如果之前我和交互沟通过的话可以直接回答，没有的话就要找交互补交互稿或者交互说明。这样白白增加了沟通成本。
解决办法：产品确定需求逻辑后，与交互同学一起做出高保真原型后再评审。一方面可以弥补交互评审的缺失；另一方面高保真原型本来就是为了便于大家理解需求和评估工作量，因为交互是不可缺失的一环。
（2）设计稿出来后不经评审。现在基本上都是设计和产品单线联系，出完图让产品看看，不满意再改（或者撕），ok了就发给前端。这样的话就十分依赖设计师和产品的水平和责任心，结果常常是原型什么样，设计稿就什么样，顶多调整下细节。
解决办法：增加设计稿评审环节。主要是给设计同学一些压力，不会随意对待，提高用户体验。
（3）立项之后产品一直在各个角色之间忙沟通，没有足够精力规划后续版本。从前两点也可以看出来，整个过程非常依赖产品，不管是沟通还是把关。虽然作为一只产品汪这些事情责无旁贷，但是这真的是为了这个项目好吗？
