2023年6月28日发(作者：)

UI设计稿评审的重要性前提：项⽬周期很紧，原型到设计的时间很少，急忙赶出设计粗稿

问题：是否花时间召开测试，前端移动端，产品，客户等其他⼈员（⼈事，前台，财务等）进⾏内部审核

现实：实际⽣产中存在这些问题，产品设计不合理，有很多问题，有想法的程序员对其进⾏了优化，没想法的程序员按照设计图来，结果导致了两种不同风格的页⾯，有些测试根据实际⽤户体验⾼的⼀⽅进⾏统⼀，有些测试只是按照实际的设计图是什么样⼦的，他就是什么样⼦的，这是⼀个让我很头疼的问题，我是⼀个测试，是⼀个不安分的测试，我呢以我的⽤户体验为准，最终选择了⽤户体验⾼的⼀⽅，现在的问题是这是在产品做出来之后才做的修改，修改时间和成本都提⾼了，也造成了程序员，测试和产品之间的不团结，不统⼀，都有想法。有想法其实是好事，集众⼈的智慧做出来的产品我想肯定是更优于由某个⼈单独完成更好，⼀个好的产品需要⼀个团队⼀起协作，⼀起思考，⼀起改善去完成它。针对这样的问题，我们能怎么做呢？

建议：相信⼤家也经常开会，各种评审会，但是很多时候都只是匆匆了事，达不到我们开会的⽬的，为了开会⽽开会。⾸先我们开会主要是为了明确⽬标，确认⽅向，减少不必要的争吵。但是很多时候，开会的时候⼤家都很安静，有想法也不想讲，不敢讲，针对这个问题，我觉得这是⼀个适应的过程，可以先从强迫性的要求开始，让⼤家都发动⾃⼰的脑袋去为这个项⽬提建议，提想法，即使乱说胡说也没关系，先让我们有这种开会勇于提意见想法的氛围。经过⼀段时间的磨合，我相信这个会议会越来越有趣，在⼀个充满议论声的评审会中，这是我期望看到的，当然还需要⼀个决策者。在这些都有的情况下，我觉得应该适当多给评审会⼀些时间，让每个⼈都能发表⼀些⾃⼰的意见，评审结束之后，把我们改动的地⽅进⾏记录，改动的效果做成设计图，并发送给决策者进⾏审核，通过之后正式提交开发，进⾏⽣产，到这⼀步开始，整个项⽬组就要以设计图需求⽂档为主了，任何与设计图和需求⽂档不符的地⽅都是bug，需要进⾏修正，即使你的想法很好，但也需要需求确定才能进⾏修改。

⽅案：评审之后进⾏领导审核，评审时间建议延长，真正达到评审的实际作⽤。