本文为「兰亭妙微」转载并编录的行业实践经验分享。原文围绕产品设计验收的意义、流程与评估方法展开，并结合齐治设计团队在网络安全产品DSG项目中的实际案例，系统阐述了如何通过标准化、体系化的验收机制提升产品体验与业务成效。希望能为关注产品设计质量与团队协作效率的同行提供参考。
设计验收是指设计人员按照设计方案对研发人员的落地内容进行逐项检验，理想状态下，最终达成设计方案的完全还原。
由此可见，设计验收的直接目标是保证设计还原度。那么设计还原度究竟可以为产品带来些什么？我们假定设计方案不存在问题：
设计验收追求每一个设计细节的切实落地，由此带来的正面效益会传递给用户更好的产品体验，也进一步提升业务交付的满意度。
那么如何在日常工作中高效高质地开展设计验收、发挥其价值，以下是齐治设计团队结合网安产品DSG项目的验收实践给出的答案：
规范工作流程有助于提高验收效率，保障验收质量。
在制定设计验收流程前，首先思考以下几个基本问题——
最后，我们将设计验收拆分为四个阶段，明确以下标准流程用于指导设计验证的开展：
确定设计验收的开始时间、验收环境以及账号密码是设计人员开展设计验收的必备条件。
理想状态下，设计验收的开始时间应该是功能验收基本完成，流程无阻断性Bug之后，即发布前的最后2-3轮提测。但是考虑到具体项目执行的变化，本流程建议设计人员主动向研发或测试负责人确认开始前的条件信息。
通过比对设计方案与落地方案，设计人员可以发现落地方案未还原的内容，以及少数设计方案不完善、不合理的地方。然后，为了更好地服务于问题修复阶段的设研协作，设计人员需要将这些问题形成验收表，并以在线文档的形式共享给研发人员。这样可以大大减少信息混乱、沟通低效、追溯困难等问题。
设计人员发现问题并记录于验收表后，验收就进入了最关键的一环。严格按照“沟通问题-修复问题-再次验收直至问题被解决”的循环工作流来消灭问题，有助于切实提升设计落地的还原度。同时，出于验收质量的要求，建议设定一个循环次数的红灯值，这是对设计人员与研发人员双方的更高要求。
通过DSG项目的执行验证，我们发现「沟通」在这个阶段至关重要，这包括所有问题的整体澄清以及具体问题的修复沟通。尤其当问题总数较大时，设计人员与研发人员之间的充分沟通会让问题修复进展得更加顺畅、大家的协作体验也会更好。
以下两点可以看作提高协作效率、推动问题修复的关键任务：
DSG第一个上线版本的设计验收修复质量不佳，遗留问题过多。为了有效改善这个情况，版本上线后，设计人员组织研发人员、测试人员一起进行了该期设计验收的复盘会议。会议主要围绕着「明确遗留问题的处置方案」和「反思修复问题的限制因素」展开。通过复盘，我们主动发现本次验收过程中的不足之处，并讨论未来工作中的优化措施。反映到DSG项目来说，二期验收修复率较一期提升了26.24%。
由于在项目实践中显而易见的显著效果，复盘阶段也被引入到标准流程当来。我们扩宽了复盘的行动范围，首先由设计人员进行遗留问题的整理以及修复率等验收数据的统计，然后据此判断本次验收质量。质量较低时组织全体性的复盘会议，明确后续改进方案；质量较高时则以更轻量的方式与项目团队成员进行信息对齐，如我们目前采用的方式是：具体问题由相关责任人及时沟通；整体验收情况与遗留处置计划放到下一期的设计澄清会议上进行全体对齐。
建立起标准化的设计验收流程后，如何进一步形成体系化的设计验收机制来指导工作？我认为可以是对工具/手段的探索，如验收结果的输出内容就是一个不错的方向。
设计人员向研发人员告知验收结果的方式可以灵活多样，但无数的经验告诉我们，当问题数量一多，简单的口头沟通或面对面演示等方式在问题管理、修复追踪等方面的缺陷就显露无疑了。故在本验收机制下，我们还提供了一个设计验收表的内容模版。
这个验收表采用「设计-研发共同编辑」的协作模式，毕竟设计验收不是一个人或一个团队的事儿，需要设计与研发乃至产品、测试多方的沟通与努力。
此外，我们目前还未针对该验收表内部分需要细化的项给出范围定义与填写说明，如「问题类型」的囊括范围、「严重程度」的判断方式，这都有待后续完善。
找到一个可用的工具是第一步，怎么把工具用好则是接下来真正的挑战。
那么如何度量设计验收的效果呢？下图是我们在DSG项目中对验收效果量化所做的探索：
从实践中沉淀，我们引入了“修复率”这个数值，他的获取门槛较低，又直观反映了问题的存在——
修复率=修复问题数/（验收问题总数-无法修复问题数），其中问题总数=当期发现问题(新)+遗留问题(旧)；无法修复问题是指极少数现阶段难以改变的问题，一般多是技术限制导致的。
随后，我们可以通过同产品不同期、不同产品同期等对比方式来分析修复率，量化设计验收；或者结合更多维度的产品体验数据，对修复率的数值范围进行划界，进一步给出设计验收执行效果的通用衡量标准。
当然，量化设计验收效果，答案或许不止这一个，我们也将继续探索并沉淀。如上文提到的修复循环次数的红灯值，亦是一个不错的切入点。
当然，本文构想的设计验收机制仍处于初级阶段，后续还有很长的路要走。比如以下几个初步设想：
1、通过更多项目机会验证该机制（包括阶段设计、表设计等）的完整性、合理性
2、总结归纳四个阶段在执行过程中的注意事项，形成指导原则
3、定义说明验收表内部分使用起来存疑的信息字段
4、探索沉淀更多有价值的量化数据
5、深入考虑当前机制如何充分适应不同需求体量下的设计验收
为团队提效，为业务赋能，愿我们秉承初心，继续探索行之有效的设计验收机制。
转载：人人都是产品经理
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
