UI设计稿评审的重要性

前提：项目周期很紧，原型到设计的时间很少，急忙赶出设计粗稿
问题：是否花时间召开测试，前端移动端，产品，客户等其他人员（人事，前台，财务等）进行内部审核？？？
现实：实际生产中存在这些问题，产品设计不合理，有很多问题，有想法的程序员对其进行了优化，没想法的程序员按照设计图来，结果导致了两种不同风格的页面，有些测试根据实际用户体验高的一方进行统一，有些测试只是按照实际的设计图是什么样子的，他就是什么样子的，这是一个让我很头疼的问题，我是一个测试，是一个不安分的测试，我呢以我的用户体验为准，最终选择了用户体验高的一方，现在的问题是这是在产品做出来之后才做的修改，修改时间和成本都提高了，也造成了程序员，测试和产品之间的不团结，不统一，都有想法。有想法其实是好事，集众人的智慧做出来的产品我想肯定是更优于由某个人单独完成更好，一个好的产品需要一个团队一起协作，一起思考，一起改善去完成它。针对这样的问题，我们能怎么做呢？
建议：相信大家也经常开会，各种评审会，但是很多时候都只是匆匆了事，达不到我们开会的目的，为了开会而开会。首先我们开会主要是为了明确目标，确认方向，减少不必要的争吵。但是很多时候，开会的时候大家都很安静，有想法也不想讲，不敢讲，针对这个问题，我觉得这是一个适应的过程，可以先从强迫性的要求开始，让大家都发动自己的脑袋去为这个项目提建议，提想法，即使乱说胡说也没关系，先让我们有这种开会勇于提意见想法的氛围。经过一段时间的磨合，我相信这个会议会越来越有趣，在一个充满议论声的评审会中，这是我期望看到的，当然还需要一个决策者。在这些都有的情况下，我觉得应该适当多给评审会一些时间，让每个人都能发表一些自己的意见，评审结束之后，把我们改动的地方进行记录，改动的效果做成设计图，并发送给决策者进行审核，通过之后正式提交开发，进行生产，到这一步开始，整个项目组就要以设计图需求文档为主了，任何与设计图和需求文档不符的地方都是bug，需要进行修正，即使你的想法很好，但也需要需求确定才能进行修改。
方案：评审之后进行领导审核，评审时间建议延长，真正达到评审的实际作用。