视觉稿没有评审，经常出现在后期策划交互走查时发现问题。但是视觉稿的评审又不适合做的太重，本身视觉设计是一种无法明确定义好坏的问题，不是越多人参与就越好，所以只定义策划和交互参与，开发只需看实现上是否有困难即可（一般比较少）。

形式必须定义清楚，否则就会容易执行不到位。

　　当然调整之后的模型也有一些限制条件：

交互评审的时候，能够找得到所谓的“核心开发”，他要对产品整体的业务逻辑都非常清晰，能够评估新提出的需求大致的工作量。如果团队中的开发都是独立负责一块，项目之间都不了解情况的，那就比较难采用这种方式。

这样的视觉评审形式其实也是比较依赖大家的主动性。否则就需要一个人，如视觉负责人来监督，是否所有视觉稿都经过评审。

　　本文讲的更多还是术的层面，关于评审道层面的讲解在《网易一千零一夜》一书有详细解读，大家可以按需进行阅读。

　　网易杭研项目管理部（ID：NeteasePM），为网易杭州研究院项目、产品提供项目管理服务，提升整体项目管理氛围和水平，从而提高项目成功率和增强团队成熟度，也对公司内外部输出培训，并出版了《网易一千零一夜》分享项目管理实战经验。