保障设计效果的实现

项目跟进是设计师的重要工作之一。有句话说得好:“一流的点子加上三流的执行还不如三流的点子加一流的执行”。 设计能力再强，设计方案再好，如没有后续良好的执行，也终究不过是废纸一张。

有的设计师不屑于做跟进的工作，觉得浪费时间；有的设计师会直接说自己没时间；有的设计师认为方案做好了，执行得不好是产品经理和开发人员的问题，和自己无关；还有的设计师认为只要自己专业能力强，项目结果好不好无所谓。

殊不知，这样的想法会给自己的职业发展造成极大的隐患；有谁在体验产品时遇到问题，会认为是开发的问题？他们一定会认为是设计师水平欠佳，你的口碑可能由此变得非常糟糕；团队也会失去对设计师的信任，因为他们会发现有没有设计师，结果可能都很差；由于没有人来跟进设计方案，团队中的人甚至可能不知道这个方案是谁设计的，设计师的存在感和价值感大大降低。

因此设计优秀的方案很重要，能把它顺利执行下去更加地重要。上线后的实际效果才是设计的最终结果。如果上线效果和设计方案截然不同，那么设计师的存在也就没有了意义。

从需求分析到设计规划，再到设计实施，开始时抽象的目标和概念，经一步步具象化， 成为了可视化的设计方案。这时，最了解设计方案的设计需要与项目组各个角色进行沟通，阐述设计方案，师进项目进入到下一个开发测试的环节。

但在许多设计师的眼中，设计评审似乎变成了一场噩梦，评审时，每个人不同的偏好和不同的出发点。开发人员关注设计方案在技术上是否易于实现、运营人员希望有足够的推广空间，视觉设计师注重产品是否美观，产品文希望在时间节点前一定可以上线，而所有这些意见， 都会集中在设计方案上,争论似乎无法避免，主持评审的设计师很容易成为抨击的焦点。

如果设计师无法主导评审会，原本完整的设计方案很可能会被各种竟见影响，改得面目全非。如果设计师给出的方案没有足够的说服力，各种意见难以达成一致，也会影响会议效率。所以，设计师需要从幕后走到台前，学会如何主导设计评审。不同偏好和不同出发点的项目成员，比如，技术人员”这个功能影响加载速度还是不要做了“运营人员“这里可以放广告那里还要放一个”产品经理“最重要的是要准时上线，你们要快点做啊”

设计评审会议

在真正开始会议前，要尽量保证设计方案已经通过产品经理及最主要的项目成员的认可，至少要保证大方向是对的。尽量私下一对一地沟通，与有话语权的人达成一致， 而不是把所有问题都抛到会议上解决。这样可以大大提高会议的效率。

经验告诉我参与讨论的人越多，意见发表得越多，就越难以得出结论。所以，越是重要的事情，越要尽可能少的人参与讨论，这样才能快速下决定。如果我们能提前和团队中的“意见领袖”达成致， 那么在会议中就可以减少很多不必要的口舌之争。在评审会上，我们还会会收到其他项目成员的意见和建议，可以把它们作为参考意见，进行细节上的调整和修改。

可以简单陈述一下自己的设计理念、参考了哪些数据了和资料，等等，然后提醒大家务必要提前熟悉设计方案，想好自己的问题。

会议时可能存在的压力会影响思考，可以在会后再来考虑这些问题，  再通过邮并或当面过论的方式，最终确定结果。所谓的在设计评审中达成共识，并不是说每一个细节都要百分之百确认。在设计方向和大的功能点上达成一致，对于细节问题可以求同存异，收集有价值的反馈后再来考虑。

要区分和收集有价值的反馈意见。

在会议中，大家会表达出各种各样的意见。设计师需要区分哪些反馈是有价值的，可以指导后续的设计和修改，哪些反馈是需要过滤掉的。

每个人都有自己的喜好，对于设计这样可以可视化表现的“浅科学”，人们更喜欢指指点点。有些反馈意见明显过于主观，比如“这个颜色太暗了，我不喜欢”，“我觉得用户不会需要这个功能，我就不会用”，“ 为什么要使用两栏布局，我觉得通栏的更大气”，等等。这些带有个人喜好的反馈意见，不需要去深入探讨，设计师只需阐明这样设计的原因即可，因为没有哪种设计方案是可以迎合所有人的口味的。

还有一些评审人员表达的意见过于模糊，如“这里很奇怪啊，为什么要这样”，“我也说不好，有没有更好的方案”，“这个操作很诡异”，等等。这种模糊的表达，不会对设计改进有任何指导意义，应该收集一些客观的明确的意见来改进

当然设计师也不能只为了维护自己的设计而反驳，不能客观的采纳别人的意见，这样不仅会显得不专业，本身的设计水平也难以提高。

Powered by Froala Editor