本文为「兰亭妙微」转载并编录的行业实践经验分享。原文围绕产品设计验收的意义、流程与评估方法展开，并结合齐治设计团队在网络安全产品DSG项目中的实际案例，系统阐述了如何通过标准化、体系化的验收机制提升产品体验与业务成效。希望能为关注产品设计质量与团队协作效率的同行提供参考。
设计验收是指设计人员按照设计方案对研发人员的落地内容进行逐项检验，理想状态下，最终达成设计方案的完全还原。
由此可见，设计验收的直接目标是保证设计还原度。那么设计还原度究竟可以为产品带来些什么？我们假定设计方案不存在问题：
设计验收追求每一个设计细节的切实落地，由此带来的正面效益会传递给用户更好的产品体验，也进一步提升业务交付的满意度。
那么如何在日常工作中高效高质地开展设计验收、发挥其价值，以下是齐治设计团队结合网安产品DSG项目的验收实践给出的答案：
规范工作流程有助于提高验收效率，保障验收质量。
在制定设计验收流程前，首先思考以下几个基本问题——
最后，我们将设计验收拆分为四个阶段，明确以下标准流程用于指导设计验证的开展：
确定设计验收的开始时间、验收环境以及账号密码是设计人员开展设计验收的必备条件。
理想状态下，设计验收的开始时间应该是功能验收基本完成，流程无阻断性Bug之后，即发布前的最后2-3轮提测。但是考虑到具体项目执行的变化，本流程建议设计人员主动向研发或测试负责人确认开始前的条件信息。
通过比对设计方案与落地方案，设计人员可以发现落地方案未还原的内容，以及少数设计方案不完善、不合理的地方。然后，为了更好地服务于问题修复阶段的设研协作，设计人员需要将这些问题形成验收表，并以在线文档的形式共享给研发人员。这样可以大大减少信息混乱、沟通低效、追溯困难等问题。
设计人员发现问题并记录于验收表后，验收就进入了最关键的一环。严格按照“沟通问题-修复问题-再次验收直至问题被解决”的循环工作流来消灭问题，有助于切实提升设计落地的还原度。同时，出于验收质量的要求，建议设定一个循环次数的红灯值，这是对设计人员与研发人员双方的更高要求。
通过DSG项目的执行验证，我们发现「沟通」在这个阶段至关重要，这包括所有问题的整体澄清以及具体问题的修复沟通。尤其当问题总数较大时，设计人员与研发人员之间的充分沟通会让问题修复进展得更加顺畅、大家的协作体验也会更好。
以下两点可以看作提高协作效率、推动问题修复的关键任务：
DSG第一个上线版本的设计验收修复质量不佳，遗留问题过多。为了有效改善这个情况，版本上线后，设计人员组织研发人员、测试人员一起进行了该期设计验收的复盘会议。会议主要围绕着「明确遗留问题的处置方案」和「反思修复问题的限制因素」展开。通过复盘，我们主动发现本次验收过程中的不足之处，并讨论未来工作中的优化措施。反映到DSG项目来说，二期验收修复率较一期提升了26.24%。
由于在项目实践中显而易见的显著效果，复盘阶段也被引入到标准流程当来。我们扩宽了复盘的行动范围，首先由设计人员进行遗留问题的整理以及修复率等验收数据的统计，然后据此判断本次验收质量。质量较低时组织全体性的复盘会议，明确后续改进方案；质量较高时则以更轻量的方式与项目团队成员进行信息对齐，如我们目前采用的方式是：具体问题由相关责任人及时沟通；整体验收情况与遗留处置计划放到下一期的设计澄清会议上进行全体对齐。
建立起标准化的设计验收流程后，如何进一步形成体系化的设计验收机制来指导工作？我认为可以是对工具/手段的探索，如验收结果的输出内容就是一个不错的方向。
设计人员向研发人员告知验收结果的方式可以灵活多样，但无数的经验告诉我们，当问题数量一多，简单的口头沟通或面对面演示等方式在问题管理、修复追踪等方面的缺陷就显露无疑了。故在本验收机制下，我们还提供了一个设计验收表的内容模版。
这个验收表采用「设计-研发共同编辑」的协作模式，毕竟设计验收不是一个人或一个团队的事儿，需要设计与研发乃至产品、测试多方的沟通与努力。
此外，我们目前还未针对该验收表内部分需要细化的项给出范围定义与填写说明，如「问题类型」的囊括范围、「严重程度」的判断方式，这都有待后续完善。
找到一个可用的工具是第一步，怎么把工具用好则是接下来真正的挑战。
那么如何度量设计验收的效果呢？下图是我们在DSG项目中对验收效果量化所做的探索：
从实践中沉淀，我们引入了“修复率”这个数值，他的获取门槛较低，又直观反映了问题的存在——
修复率=修复问题数/（验收问题总数-无法修复问题数），其中问题总数=当期发现问题(新)+遗留问题(旧)；无法修复问题是指极少数现阶段难以改变的问题，一般多是技术限制导致的。
随后，我们可以通过同产品不同期、不同产品同期等对比方式来分析修复率，量化设计验收；或者结合更多维度的产品体验数据，对修复率的数值范围进行划界，进一步给出设计验收执行效果的通用衡量标准。
当然，量化设计验收效果，答案或许不止这一个，我们也将继续探索并沉淀。如上文提到的修复循环次数的红灯值，亦是一个不错的切入点。
当然，本文构想的设计验收机制仍处于初级阶段，后续还有很长的路要走。比如以下几个初步设想：
1、通过更多项目机会验证该机制（包括阶段设计、表设计等）的完整性、合理性
2、总结归纳四个阶段在执行过程中的注意事项，形成指导原则
3、定义说明验收表内部分使用起来存疑的信息字段
4、探索沉淀更多有价值的量化数据
5、深入考虑当前机制如何充分适应不同需求体量下的设计验收
为团队提效，为业务赋能，愿我们秉承初心，继续探索行之有效的设计验收机制。
转载：人人都是产品经理
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
在电商平台，中后台系统工作庞大且复杂，而中后台系统是否有规范的逻辑、是否有高效的体验，则会体现在用户的身上。本篇文章作者总结自身经验，为我们总结中后台体验优化的思路和方法，一起来看看。
自 18 年 6 月底介入电商中后台交互设计工作以来，笔者有幸做了很多和以往的交互设计不太一样的工作，除了日常需求的交互设计支持以外，更多的精力放在了系统整体体验提升和设计规范上。
本文整理了之前在中后台体验优化实践中的思路和方法，如何从设计角度高效地优化整个系统的体验，如何而非仅仅停留在表现层，希望能与大家交流碰撞。
在产品初期的时候，后台系统只是为了支持前台，实现功能即可，但随着产品越来越庞大，每一个前台的小小的功能优化，都可能是由后台一整套支持体系，和一整个运营产品组来维护的。因此，后台系统的体验也时刻影响着团队成员的工作效率，影响着一个产品在用户面前的形象。后台系统的体验提升，并不仅仅是使用体验提升，更多的是效能提升，和产品逻辑的规范。
系统体验提升的任务，相较于其他工作，不同的地方在于交互设计师并非被动地接受某个单点需求，也没有一个既定的模式去执行，而是要主动地去思考如何衡量体验，如何全局地管理体验，以及如何更好地规划方案。在这样的前提下，交互设计师更应该为全局的体验负责，所以发挥设计师的主动性非常重要。
基本思路是：衡量 → 收集 → 规划 → 设计。
前三步都是与画稿子无关的部分，但却是非常重要的部分，在整个过程中，沟通非常重要，正因为后台系统的业务专业性强，逻辑复杂，需求方多，所以需要更多地与各方进行沟通，调动大家的力量，一起来参与体验优化。
正如现代管理学之夫彼得·德鲁克所说，如果我们不知道平台的现状，“提升”也就无从谈起。
在 C 端产品中乃至部分B端产品中，我们有很多聪明的办法去衡量一个产品的现状，比如净推荐值，跳出率，任务完成率，可以直接从数据观察到用户流失的环节，方便又客观。但是对于公司内部使用的中后台系统来说，一个是数据样本量少，不一定能准确代表问题；更重要的是，不管体验如何，用户出于完成工作的目的，也必须完成系统的任务，所谓完成率和体验没有必然联系。
当数据少的时候，不妨倒过来想，数据分析本来就是为大体量的产品客观分析所有用户的行为，而把每一个用户抽象成了一组数据，再来综合评估。那么如果你的每一个用户都至关重要，且不需要花费太多的精力就可以与他们来一场面对面的对谈，岂不是更有助于你去了解你的用户？用户访谈、可用性测试、用户体验地图都是非常适合用在这种场景下的。
最终，我们在本次优化中选择了 3 种方式来衡量系统的体验：
一般来说，满意度问卷在结构上会包含：产品整体满意度，通用指标满意度，业务功能满意度三部分；为了精细化分析，我又添加了一部分用户属性的内容，和最后的开放性意见，主要是为了更好地帮助后续分析重点优化方向和搜集用户意见。
在设计问卷的问题和答案时，不要用太过专业的术语，答案也不一定要用标准的五级量表（非常满意、满意、一般、不满意、非常不满意），可以更具象地去描述1-5级的答案，方便用户选择。
如上述问题，将比较抽象的 “系统稳定性” 转化为“页面打开速度和出错频率”来描述，答案也做了更具象的描述，方便用户确定他们的满意程度。
下图是某个系统的功能满意度，很明显可以看到 D、E 模块的满意度是低于其他模块的，后续可重点关注这2个模块；同时，海外用户的满意度普遍低于所有用户，确实在这之前海外用户的需求，比较难触达到产品组内部。
满意度问卷已经帮助我们客观地了解到用户对于系统的满意程度，也有了一定的优化重点，但对于落地方案来说，还是比较笼统而零散。作为一次完整的体验提升优化，还需要站在更全局的角度去仔细审视系统的每一个环节。
前面提到，中后台系统往往有很高的业务壁垒，体量大，流程长，涉及角色多，对于某个单一角色来说，想要快速深入到系统底层，找出所有问题，是不现实也不客观的。
对此，我的想法是，借助用户和项目成员的力量，共创用户体验地图。
用户体验地图
用户体验地图是产品设计中常用到的一种设计方法，它让我们平时零散获得的抱怨、吐槽，变成有序的阶段体验，直观地呈现出用户在每一个目标任务下的行为、思考、痛点和机会点。
在此不再详述用户体验地图的定义和使用方法，具体可参考蚂蚁金服的实战案例：https://www.uisdc.com/user-maps-design-ali-case#
中后台系统共创用户体验地图，要在拥有用户意见的基础上，邀请产品、技术、设计、业务方共同参与，当涉及多个业务方时，也需要同时邀请，一起来思考站在用户角度的痛点，和站在自己角度可以提出的机会点。
往往此时，不同的业务方之间，以及和产品方、用户方之间，视角不同，都会存在或大或小的利益冲突，大家共创的过程也是不断碰撞、同步的过程。在大方向（提升系统体验，促进业务成长）一致的前提下，所有人的意见是可以在讨论中互相磨合，最终达成细节共识的。
在此过程中，有非常重要的一点，在于设计师要提前和各方确认好系统的主流程，并在会议上引导成员按照主流程框架来进行思考和讨论，控制好节奏和话题走向，切记千万不要让体验地图共创，变成了七嘴八舌的「吐槽大会」。最终只是收获到了一堆抱怨，却没有结论和共识。
提前确定好的主流程
最终的用户体验地图
在有了较为全面的用户体验地图后，我们就可以全局地去考虑系统体验提升如何落地了。事实上，在共创的过程中，包括后续的整理中，我们可以看到除了业务相关的机会点外，许多体验上的问题是相通的，例如：复杂表单填写缺少规范、系统通知混乱、流程进度不透明、小屏幕展示不友好等等，虽然这些问题会出现在不同的业务模块中，但是从交互设计的角度来说，它们的解决方案是一致的，可复制的。
可以和产品一起把这些需求仔细评估一遍，分为三个部分：
在此重点分享一下首页、通知分级、流程节点透明化等参考价值比较高的框架性设计，也就是第二部分。
对于首页改版，最重要的是明确设计定位，之后就是填充支撑定位的内容模块，设计展现形式。
1）明确设计定位
作为一个以协同办公为主的平台，我们对于系统首页的定位为：
2）填充内容模块
由此，我们会需要官方公告、帮助引导、待办事项、业务附能等内容模块，可以根据用户角色的不同分别显示。
3）设计展现形式
当用户抱怨通知消息太多，细细追究又发现每个通知都有必须存在的理由时，我想，可能是系统没有做好通知分级。
正如我们设计每个页面时会对页面上的信息进行分级，给到不同的展示效果一样，当系统庞大到某种程度，我们就需要对系统的通知进行一次「通知分级」。把重要紧急的消息直接传递到用户面前，弱化一些反馈型通知。
所以就需要我们整理整个系统流程里需要提醒的事，以及确定它的重要程度分类，包括：
部分通知分级示例
在中后台系统中，经常会涉及异常复杂的表单填写，不仅仅是内容多，而且每个填写项涉及业务规范，缺少填写指引，容易出错，流程反复驳回，对接低效。
于是，在必要流程前添加了准备资料阶段，列出了所有需要准备的资料，注意：
明确的填写指引，再配合针对审核人及时的通知提醒，目标将原来 41 天的流程时效降低到 21 天。
中后台系统会有非常多的流程协作功能，但是之前系统的做法仅仅是完成了流程的「功能」，却没有照顾到用户的「心理」，没有告知用户每个流程应有的节点、规范、当前进度。用户在等待流程推进的时候仿佛进入了一个黑箱，不知道现在的进度如何也不知道什么时候会完成，不仅是体验不好，而且会浪费大量的人力、资源在沟通流程进度上。
所以在整体优化时，引入了流程进度模块，清晰地展示了整体流程的节点，对应的操作人，截止时间，以及完成节点的操作记录。这节省了非常多内外沟通的时间。
流程节点透明化
以上，就是本次中后台系统体验提升的大致过程：
中后台大多数业务复杂，体量庞大，设计刚刚接触时会觉得无从下手，利用这样的一套流程不仅能帮助我们与团队成员一起优化系统体验，还能让我们深入到用户场景，和各业务方、用户方深入交流，对后续的工作也很有帮助。
笔者一直认为，虽然中后台是前台用户看不见的地方，但后台系统逻辑的规范，体验的高效，最终会透过层层映射展现在用户面前。对于电商来说，可能更多体现在发货、物流、质检等屏幕外的体验上，但这也是产品体验不可忽视的一部分，需要我们为此添砖加瓦，不断加分。
转载：人人都是产品经理
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
蓝蓝设计的小编 http://www.lanlanwork.com