2.2 视觉稿

简化流程

当产品团队走完第一阶段和第二阶段的流程后（这里简化了第二阶段的流程），就进入视觉稿设计阶段，此阶段产品会受到来自设计师的阻力，当然产品无时无刻都在承受来自各方的阻力。在这里记录下视觉稿设计与评审的几个坑，与大家分享：

1.设计师对产品或者功能的看法无法达成一致该如何解决？

答：与设计师的矛盾主要是因为两个原因：设计师不懂你设计背后的需求来源；在颜色、交互上等布局上PM插手过多。

案例图片

举个栗子：在地区组件的设计上，设计师认为没有必要加“选择高考地区”的文案，设计师认为“当用户使用该组件时他难道不知道这是让其在选择地区吗，所以加上文案是一种累赘”，然后死活不改。

事实上，这个文案其实是出于业务上的考量，因为用户的高考地与生源地可能不是同一个地区，所以需要注明这是选择“高考地区”而不是“生源地”。

但是另一个方面，如果PM觉得这个设计字体大小需要定在XXpx,颜色需要选择XXXXXX格式这或许就有越权的嫌疑了，毕竟在某些程度上，设计师在整体视觉上的把控可能会更专业。

所以解决方法是：第一步，判断设觉稿是因为什么原因才导致与原型不同；第二步，判断自己的理由是否足够有说服力，谁有道理听谁的，都有理由看数据。

2.视觉稿评审

答：在团队集体评审视觉稿前，PM需要提前对视觉稿进行把关。需要把关内容有：视觉设计、交互说明、功能布局、实现成本。当然即使你审核通过，在评审过程中被大家喷依据是常态。

最后评审结束后，需要开发定排期。千万不要把排期定死！千万不要把排期定死！

千万不要把排期定死！因为某些细节（例如在评审阶段没有展示动画效果，结果导致成品与视觉稿不一致）所以在定排期过程中一定要流出足够的BUG修复和交互完善的时间。这开始设计项目管理的范畴，此处不累述。

案例图片

补充一点，虽然在评审阶段是设计师在解说整体设计思路，但如果通不过评审，PM才是真正需要负责的那个人。