编辑导语：产品验收，对于产品经理而言应该都不陌生，它是产品上线前的一个关键的步骤，那么产品验收该如何做呢？作者结合自己的经验，总结了产品验收的全过程，希望对你有所帮助。
产品验收，是产品发布上线前不可缺少的一个环节。但是，如何验收呢？
产品验收时会面临各种挑战，比如：
问题多多，困难重重，但是在设计阶段或是验收阶段能否尽量避免或优化的呢？从需求到设计，从设计到研发，从研发到验收，在这几个环节中间，设计师可以做什么呢？
根据以往验收的经验，我会在【设计阶段】【验收阶段】做一些优化，以及后面的复盘中总结相关经验，来减少一些不必要的错误。
设计阶段是设计的主战场之一，不仅挑战设计师的设计能力，还有需求理解分析，最终所有的努力成为一纸设计呈现。在设计师披荆斩棘，终于产出设计稿后，设计师最希望的是一稿过，并且最终实现设计稿 100% 还原。但是，我们都知道，这真的只有梦里有。
设计交互说明补充和与前端提前沟通一些交互，可以提前避免一些预知错误并减少后期沟通成本，提高效率。
设计时，并不仅仅只是交付视觉稿，还需要一些设计交互辅助说明。这样做可以减少后期沟通成本，也防止自己忘记。特别是项目周期长的，可能设计时，清楚是怎么样的交互，等验收时，可能都忘记这个需求了，这也会导致验收时，会遗漏需求。
对交互的书面描述，也是帮助设计师更加深入的思考。有时，只是在脑海里过一遍，往往会有所遗漏。同时，要保持交互说明的简洁，不要长篇大论，可以用更少文字描述的，就不要用长文。可以用图片或图案表达的，就尽量不使用文字。因为，人都是对视觉更加敏感，也更容易记住，文字过多，可能干脆都跳过。
设计交互说明中，要包含但不限于以下说明：
组件交互说明：
操作类交互说明：
页面布局说明：建议在设计规范中一次性约定：
异常：
其他：
交互设计说明的假设前提是，前端同学不清楚交互规则。很多时候设计师会假设，前端一定知道这个组件或页面是如何交互。但是现实往往不是这样，这不是谁对谁错的问题，而是大家站的角度不同，处理事情的方式当然也有所差异，再加上人本身的复杂性。
所以，在与前端同学培养好默契前，建议写好交互说明，避免开发或验收中反复确认反复修改。
定义好整体的设计规范，会帮助前端更加清楚一些交互的规则。但是在前期与前端刚合作时，设计师要写清楚交互细节，因为开发也需要时间熟悉规范。当然约定好规范，也是减少双方在一些交互方式上 Argue 的时间。
对于一些定制类比较特殊的组件，建议让前端同学沉淀成组件，保证整体设计的统一性，减少后期维护成本。
复杂的交互，建议提前与前端沟通，确认好交互细节，避免开发时，前端错误理解或无法实现，这时不只是在设计稿上要标记，最好是找前端面对面沟通。基本上复杂的交互，开发的时间也不会太短，提前沟通能帮助前端预估好开发时间，也能避坑，顺便建立好关系。
开发有时只是大概 Review 一下设计稿，等到真正开发时，才会评估难易和时间，所以比较复杂的交互有可能会被忽略或错估。
设计评审时，对于复杂交互或复杂业务逻辑，要充分与开发确认，尽量减少后期设计调整或更改。
一般会由 PD/PM 牵头，邀请设计师、测试一同参与产品验收。若是小团队，可能就是产品和设计两个人。验收前后的准备，可以以团队形式进行，提高效率。
验收时，可分验收前、验收中、验收后来看。在不同的时间，做一些准备工作，也能让验收过程变得高效和愉快。
（1）与开发确认可验收范围
开发过程中，可能会因为一些原因，有些需求会被延迟或暂不开发，所以与开发确认验收范围是必要的。
（2）需求清单
罗列需要验收的需求清单，重点需求或交互点可标记。清单可按产品模块来划分或项目，清单上可包含以下：
（3）测试用例
设计师比较少会写测试用例，为了避免重要需求点验收遗漏，可以有些针对性的梳理。测试用例不需要太复杂，符合设计师的需求就好，测试用例梳理过程是比较费时间，所以建议只对复杂的一些业务场景。
示例：
（4）时间规划
时间规划也是让验收能够顺利完成的关键点之一，虽然工作最终能完成，但是没有 Deadline 的项目，会无限期推迟，不利于整体项目推进。而且时间要连续进行，专心找 Bug，专心修 Bug。
（5）需要开发配合的一些准备
（6）其他
约定提 Issue 的存放位置，比如云效和 GitHub 都有提缺陷的功能。同时要约定缺陷的等级，优先级【紧急】【高】【中】【低】设定标准是什么，什么样的缺陷这次验收是一定要修复的。
验收通过的标准是什么，是优先级高以上都修复完成就通过，还是优先级中以上。不管最后约定的规则是什么，都需要同步给开发同学。
验收时，对问题的描述同样很重要。对问题清楚的描述，能帮助开发更好理解问题所在，减少彼此沟通的时间。对于比较难描述的问题，可以录屏来记录问题，然后当面和开发聊这个问题。
提 issue 时，有几点建议：
验证问题的时间最好可以隔一天。开发改好了，就会更改状态，但是大部分前端不会在当时就发布，所以如果当下去验证，基本上还是一样的。除非开发自己和你说，他已经发布了。
验收完成后，需要对验收有个总结，产出验收报告。验收报告，包括验收的基本情况，验收的维度，验收需求范围，各模块或各项目 issue 情况等等
（1）基本情况
（2）验收维度
（3）验收需求清单
按各模块或项目，列清楚当前验收的情况。
（4）验收结果
对现有问题做一个结论，当前共发现 XX 个问题，其中：
截止 2022074 18:00:00, 当前修复情况：
坦白讲，我不是个喜欢做复盘的人，但是我基本上都是强迫自己做，因为脑袋知道这是件有益的事。
对验收发现问题的总结，也能帮助我在下一次设计中，知道哪些地方需要多和开发们确认。哪些类型的交互需要考虑的更加仔细，尽可能提早发现问题，避免到验收才发现交互不合理，要临时调整。
产品验收，始终会是产品的一个挑战。但这就像每个生命都需要成长一样，总是在磕碰中，砥砺前行。
本文由@箴盐设计 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。