最近我们做了一次全新改版的项目。作为此次项目的设计师，从项目的前期分析、设计、交付开发、验收上线，整个流程，在项目走查验收阶段我们设计师投入了30人/天！占了设计师整体投入的50%！在我们觉得应该设计投入最少的阶段，却占了我们大量的工作 且最后还原度也远不达预期。
技术设计没有达成共识，技术对交互体验层面和视觉层面的问题敏感度很低
还原问题反馈不及时，有些问题项目后期验收的时候才暴露
前期对还原度工作评估不准确，导致后期发现问题 来不及修改
还原问题不单单是设计师把设计稿做的多精准，标注的多仔细，这么简单就能解决的。是设计和开发，团队之间的合作共识问题。我把整个和开发对接工作分为前中后三个阶段，在这里从头来梳理一下，聊一聊设计师和开发如何高效对接，也是对自己的一次复盘总结。
在评审环节，设计师本人一定要将自己的设计稿进行宣讲、帮助开发理解。注意给技术讲述一些适配要求、设计规范、交互状态及动效等，同时解答技术同学的一些疑问，这样就能将一些可预见的问题解决掉，解决后期的沟通成本。
有一些地方有多种实现方式，如果前期没有跟开发沟通清楚，就会导致最终实现的效果存在误差，比如：下方这个tab项，单给一张图，开发根本不知道设计师想要的实现方式是什么，固定间距还是固定菜单宽度，还是每项平分宽度，最后很大可能就会按照自己的理解去做了，导致出现重复返工的现象
再比如一些点击热区，如果不手动标明，有可能就做的很小
每个开发负责的具体页面模块不一样，别人对具体了解程度也不会不一致，所以在评审会议上，一定要具体开发者在场，如果对应开发没有发表意见，设计师可询问，确保他已经理解需求。
设计师在讲解自己的要求后，开发也要及时反馈是否有还原困难，如：是否有技术限制？是否有组件改动困难（牵一发而动全身）？实现成本过高（投入产出的性价比不够）？等意见和原因，设计师也可抛出之前是否遇到过类似的阻碍，帮助开发去了解。
评审过程的问题和重要讲解点，一定要记录下来，会议中开发提出的一些问题及解决方案、或者没有达成共识的地方，记录下来等领导决策，在会议结束后以邮件形式、或wiki文档发送前端们，抄送产品，确保会议内容的传达到位。后面也好跟踪。
还有一点就是，我们之前遇到的情况，在宣讲会上 讲解的一些要求，开发在做的时候可能就忘记了，让开发改他认为设计没有明确要求、会有点难推动，就会搞得双方都有抱怨。有会议记录也可避免此类情况发生
在前面我们做了详尽的沟通和评审，但有时也避免不了在开发过程有些问题才发现暴露。这个就需要开发同学能重视还原问题，积极沟通反馈，和设计确认商议 是否有其它可替代方案，切勿自己发挥，等到后期验收的时候才说出问题可能会影响进度。
开发者在完成自己负责的模块界面时，可自己对齐设计稿自查一遍，参考【3.1验收标准】的表格，可帮助判断问题，在此阶段也可发给设计者确认效果。
3.1、测试同学确保交互和视觉还原度至少在70%左右
这里可以提前在项目排期阶段，设计师将所需的验收工时同步给技术和测试，将验收时间考虑进去
因为如果不要求测试走查还原度，设计验收的时候就会有大量的问题，最后变成设计在测试界面而不是验收。设计师不像测试对整个流程的测试配置那么熟悉方便，反复验收需要测试和设计不断配合，双方的工作量都会加大。
理想的状态应该是测试整个流程走通，视觉和交互还原问题也要着重测试，设计和产品在测试没什么大问题后再进行验收。
最好是提前知道模块的开发者，这样验收的时候一对一进行模块的打版验收效率更高
技术对功能上的BUG，可以自己很好的判断哪些是严重的紧急的，但对于视觉和交互层面的感知就比较低。在提问题单的时候，我们可以帮他标注出优先级，告知开发哪些是比较严重的需要优先修改的，不然 开发自己很难判断，可能就会挑一些比较好改的先改了，重要的问题反而被搁置了。尤其在项目时间比较紧张的时候，有优先级标注 开发能够看出哪些是可以为项目进度做出妥协的，哪些是必须要修改的。
设计提BUG单的不能简单的说这里出错了，请参考设计标注重新调整。要直接给出正确的尺寸、增多少、减多少、这样可帮助技术提高更高效率，也能避免开发自己去看又出现误差、又要返工修改。
设计师在验收过程中容易遇到的一个比较头疼的问题就是，技术和产品小伙伴可能因为项目上线时间紧，觉得视觉还原和页面交互体验上的问题不重要不给予修改，优先保障功能上线。
除了这些原因，设计侧也在检讨总结，自己有哪些做的不足的地方，所以 以上文档也是对接下来工作的优化方案。设计还原度也是日常考核之一，需要大家重视，好的产品要严格把控精心打磨，希望这次的总结、相关流程和经验，在接下来工作中能够提升设计验收效率和还原度。
