编辑导语：产品验收，对于产品经理而言应该都不陌生，它是产品上线前的一个关键的步骤，那么产品验收该如何做呢？作者结合自己的经验，总结了产品验收的全过程，希望对你有所帮助。

产品验收，我会了（产品验收结果）

产品验收，是产品发布上线前不可缺少的一个环节。但是，如何验收呢？

产品验收时会面临各种挑战，比如：

设计稿还原度低，需要反复与前端校对
交互细节不到位，前端实现与设计师预期落差大
小需求容易被忽略
验收问题多，沟通成本高
…

问题多多，困难重重，但是在设计阶段或是验收阶段能否尽量避免或优化的呢？从需求到设计，从设计到研发，从研发到验收，在这几个环节中间，设计师可以做什么呢？

根据以往验收的经验，我会在【设计阶段】【验收阶段】做一些优化，以及后面的复盘中总结相关经验，来减少一些不必要的错误。

一、设计阶段

设计阶段是设计的主战场之一，不仅挑战设计师的设计能力，还有需求理解分析，最终所有的努力成为一纸设计呈现。在设计师披荆斩棘，终于产出设计稿后，设计师最希望的是一稿过，并且最终实现设计稿 100% 还原。但是，我们都知道，这真的只有梦里有。

设计交互说明补充和与前端提前沟通一些交互，可以提前避免一些预知错误并减少后期沟通成本，提高效率。

1. 设计交互说明

设计时，并不仅仅只是交付视觉稿，还需要一些设计交互辅助说明。这样做可以减少后期沟通成本，也防止自己忘记。特别是项目周期长的，可能设计时，清楚是怎么样的交互，等验收时，可能都忘记这个需求了，这也会导致验收时，会遗漏需求。

对交互的书面描述，也是帮助设计师更加深入的思考。有时，只是在脑海里过一遍，往往会有所遗漏。同时，要保持交互说明的简洁，不要长篇大论，可以用更少文字描述的，就不要用长文。可以用图片或图案表达的，就尽量不使用文字。因为，人都是对视觉更加敏感，也更容易记住，文字过多，可能干脆都跳过。

设计交互说明中，要包含但不限于以下说明：

组件交互说明：

基础组件：输入框，下拉框，日期选择器，按钮等等
定制组件：根据产品需求特别定制的，比如下拉框下拉列表要展示【名称】【ID】【创建时间】【创建人】
其他：比如状态，需要枚举，需要写清楚对应可操作的 Action。
…

操作类交互说明：

比如点击某个 Action 触发什么页面，页面形式是什么。是弹窗，还是抽屉，还是新页面打开，当前页还是新开页面等
点击或悬浮，UI 上是否有变化
不可操作的情况枚举

页面布局说明：建议在设计规范中一次性约定：

字号和字色：标题、主文字、辅助文字、不可点击
默认排序
空页面展示
分页器规则
不同显示器的适配
文字溢出的处理
浏览器标签页约定：比如是展示一级菜单名称，还是二级三级名称，还是只展示产品名等等

异常：

异常情况枚举
报错的展示 UI，包含原因和解决方案
404、403 等异常页面的异常

其他：

交互设计说明的假设前提是，前端同学不清楚交互规则。很多时候设计师会假设，前端一定知道这个组件或页面是如何交互。但是现实往往不是这样，这不是谁对谁错的问题，而是大家站的角度不同，处理事情的方式当然也有所差异，再加上人本身的复杂性。

所以，在与前端同学培养好默契前，建议写好交互说明，避免开发或验收中反复确认反复修改。

定义好整体的设计规范，会帮助前端更加清楚一些交互的规则。但是在前期与前端刚合作时，设计师要写清楚交互细节，因为开发也需要时间熟悉规范。当然约定好规范，也是减少双方在一些交互方式上 Argue 的时间。

对于一些定制类比较特殊的组件，建议让前端同学沉淀成组件，保证整体设计的统一性，减少后期维护成本。

2. 提前沟通

复杂的交互，建议提前与前端沟通，确认好交互细节，避免开发时，前端错误理解或无法实现，这时不只是在设计稿上要标记，最好是找前端面对面沟通。基本上复杂的交互，开发的时间也不会太短，提前沟通能帮助前端预估好开发时间，也能避坑，顺便建立好关系。

开发有时只是大概 Review 一下设计稿，等到真正开发时，才会评估难易和时间，所以比较复杂的交互有可能会被忽略或错估。

设计评审时，对于复杂交互或复杂业务逻辑，要充分与开发确认，尽量减少后期设计调整或更改。

二、验收阶段

一般会由 PD/PM 牵头，邀请设计师、测试一同参与产品验收。若是小团队，可能就是产品和设计两个人。验收前后的准备，可以以团队形式进行，提高效率。

验收时，可分验收前、验收中、验收后来看。在不同的时间，做一些准备工作，也能让验收过程变得高效和愉快。

1. 验收前准备

（1）与开发确认可验收范围

开发过程中，可能会因为一些原因，有些需求会被延迟或暂不开发，所以与开发确认验收范围是必要的。

（2）需求清单

罗列需要验收的需求清单，重点需求或交互点可标记。清单可按产品模块来划分或项目，清单上可包含以下：

（3）测试用例

设计师比较少会写测试用例，为了避免重要需求点验收遗漏，可以有些针对性的梳理。测试用例不需要太复杂，符合设计师的需求就好，测试用例梳理过程是比较费时间，所以建议只对复杂的一些业务场景。

示例：

产品验收，我会了（产品验收结果）

（4）时间规划

时间规划也是让验收能够顺利完成的关键点之一，虽然工作最终能完成，但是没有 Deadline 的项目，会无限期推迟，不利于整体项目推进。而且时间要连续进行，专心找 Bug，专心修 Bug。

设计验收时间
开发修复时间
再次验证时间
最后：设置最后截止时间

（5）需要开发配合的一些准备

测试账号：一些需求的验证，可能需要多账号来验证，提前准备好测试账号是有必要的。
权限：如果涉及账号权限，可以提前让开发开通或授权
验收环境的准备，如果是约定预发环境验收，要让开发同学提前部署

（6）其他

约定提 Issue 的存放位置，比如云效和 GitHub 都有提缺陷的功能。同时要约定缺陷的等级，优先级【紧急】【高】【中】【低】设定标准是什么，什么样的缺陷这次验收是一定要修复的。

验收通过的标准是什么，是优先级高以上都修复完成就通过，还是优先级中以上。不管最后约定的规则是什么，都需要同步给开发同学。

2. 验收中

验收时，对问题的描述同样很重要。对问题清楚的描述，能帮助开发更好理解问题所在，减少彼此沟通的时间。对于比较难描述的问题，可以录屏来记录问题，然后当面和开发聊这个问题。

提 issue 时，有几点建议：

标题清晰，写清楚主要原因，例【模块名称】创建XX页面，提交显示成功，但是列表无数据
触发条件或路径描述清晰，写清楚上下文，帮助开发了解问题发生过程
文字加上截图，图文并茂
不想只写问题，要把修改建议一起附上
UI 问题，直接在截图上圈出有问题地方，并写上正确值，减少前端来回看设计稿的时间，或许你一眼就看出间距有问题，但是对于前端来说，这始终是一个盲区。大家关注点不一样，不需要在这僵持
同一个页面的问题，比如同个创建表单的一些界面问题，可以把问题提在一个 issue 里面，可以方便前端同时改了。如果当中有高优化级的，可以单独提一个。

验证问题的时间最好可以隔一天。开发改好了，就会更改状态，但是大部分前端不会在当时就发布，所以如果当下去验证，基本上还是一样的。除非开发自己和你说，他已经发布了。