时间: 2021-07-30 10:12:54 人气: 15 评论: 0
本文主要说明交互设计师进行交互验收的常规流程、交互验收的内容，以及验收注意事项。
做任何事情都应该有始有终，设计工作也是如此。
设计师前期参与需求讨论、需求评审、输出设计方案、组织设计评审、完成评审后的修改，以及交付给下游同事之后的协调沟通等，以上每一个步骤都需要投入较多的精力。
同时设计师仍然要做好善后工作，设计方案的交付只是项目推进过程中在设计节点的结束，想要保证项目后期上线的效果，认真对待“设计验收”是非常重要的一个环节。
本文主要说明交互设计师进行交互验收的常规流程、交互验收的内容，以及验收注意事项。
是指某个项目已经完成开发，测试人员已完成功能验收，确保各个流程无异常和无阻断之后，参与项目的交互设计师从交互层面对项目的实现效果进行验收，发现交互问题并提交给开发跟进解决，之后再次复验的过程。
交互设计师开始验收的时间点，一般情况下是在测试人员完成1~2轮测试之后，这样设计师验收时主要的精力集中在设计相关的问题上。
这里有两个需要注意的地方：
交互验收时可以按照不同的维度记录bug，比如按照需求的主流程与子流程经过的页面验收、按照交互稿中原型输出的顺序验收。
对于一些复杂的需求，包含相对复杂的流程，需要在验收过程中结合以上两种方式。
无论如何验收，最终需要将发现的交互设计问题汇总，建议以文档的形式集中记录（或者有些公司是提交bug清单任务），之后一起交付给开发。
这样便于开发抽时间集中解决，最好不要在工作群内单个抛问题，这样既不利于交互设计师后续复验，也不利于开发查阅问题。
告知对应的开发查看和解决汇总的验收问题，最好能提前了解开发解决所需的大概时间，便于自己提前预留复验时间。
开发在解决提交问题的过程中，对于已经解决的问题**通知你再次复验，对于未能解决的问题**告知你原因，此时需要针对具体情况分析判断：比如现有条件下是否有其他合理的替代方案？
如果是因为开发技术实现难度、开发实现周期等因素，可以与产品经理沟通，对此类问题进行归类记录、并且标明未能实现的原因，站在交互设计师的角度给出合理建议。
即使是待上线的测试版，复验没有问题之后，也无法保证发布正式版一定准确无误，当然这是小概率事件。所以交互设计师仍然需要在需求发布正式版之后，再次对线上进行验收确保无误。
页面逻辑判断中涉及到的关键任务路径，是否符合交互稿中设定的流程？
交互设计师在输出交互稿时，一般**对需求中涉及到的关键任务，尤其是判定条件相对较多的任务流，绘制任务流程图。
这样做的目的既有利于查看交互文档的人员明确判定的流程，也有利于交互设计师验收时快速调用、提升验收的效率。
在各种预定的操作情境下，用户每一次操作所触发的页面状态、操作结果是否达到预期效果？尤其是特殊状态下的页面样式、提示等。
这里也需要关注“逆向操作”，即顺着正常路径执行返回操作，页面跳转逻辑是否正常。
同时避免页面跳转逻辑陷入死循环。比如在移动端帐号登录页面有注册入口，点击注册按钮进入新用户注册页面，此时有的应用**在注册页面继续放置“登录入口”，若在注册页面点击登录按钮，则默认返回上一级登录页面，并非是继续进入下一级页面，不然极端情况下这种场景**陷入死循环，用户反复点击多次，就需要回退多次。
页面元素的交互细节与交互稿中元素的交互说明是有对应关系的，主要包括：
如果交互设计师在输出交互稿时，有相应的动效设计或文字说明（一般简单的微动效可以通过文字表述，复杂一些的动效需要通过专业软件输出动效demo），验收时同样需要查看动效的还原度。
PC端网页设计中，通常**依据网页重要性对页面进行不同屏幕宽度的自适应，比较常见的是大部分网站首页**依据不同宽度节点进行自适应。因此在交互设计阶段就需要考虑到自适应布局，验收时自然也不能忘了。
移动端界面设计，由于近年来大屏手机的出现，其中最典型的是iPhone的刘海屏，尽管我们输出交互稿目前仍然是以iPhone 6的一半尺寸为标准，但是由于各种类型大屏手机的出现，导致我们不得不在设计初期、以及验收阶段考虑大屏手机的适配问题。
举例：比如iPhone X去掉实体Home键之后，将返回主页/调起多任务窗口的操作按钮至于屏幕底部，并且为了避免交互手势冲突，苹果官方标明了针对此类机型进行界面设计的安全区。
所以在设计底部导航栏时，就需要将底部导航栏放置于安全区的底部，而不是屏幕的底部，不然**引发手势冲突。
实际工作过程中，经常**遇到一种情况：原本按照交互稿的方案，可以确保页面操作的易用性，但实际开发过程中基于开发技术实现的复杂度、开发时间有限等因素，可能无法实现交互稿的方案。
此时综合各种影响因素，给出合理的替代方案，那么验收时也需要特别注意替代方案的易用性与使用体验。
此时需要评估问题的复杂程度，必要时与部门同事沟通商量。
一般根据问题的复杂程度决定：能解决的有关用户体验的小问题可随即提出解决；若问题牵扯较多、调整相对复杂耗时，可以先记录后续改进。
iOS系统与Android系统有不同的交互设计规范，界面相关元素的排版布局与交互方式存在差异，也对应着不同终端的开发。
特别注意：输出交互稿时最好考虑到两端的差异，给出明确的差异说明或图例示意，这样便于开发明确，同时降低了交互设计师后期的沟通成本。因此验收时需要针对两端分别走查。
验收过程中有没有遇到什么问题，如果有，是否有更好的解决办法？沟通过程中是否有不顺畅的地方，是不是自己对基础技术不够了解？哪些问题是自己应该坚持不妥协的，哪些问题没有必要耗费过多精力争执等等。
每一次复**都是为了之后项目的验收更加顺畅高效。
目的是避免记录的问题过于零散，不利于上下游查看的同事分析。分类记录便于明确定位属于哪里的问题、问题的多少、问题的性质，也有利于团队后续的复**。
目前有大量的专业书籍和文章详细介绍如何输出高质量的交互稿，对于交互设计师而言，这只是承接需求的一部分，不仅要重视前期定义需求、产出交互文档，更要做好收尾工作，认真对待需求的交互设计验收。
作者：Viksea，微信公众号：Viksea的设计思考（ID：viksea-ux）
本文由 @Viksea 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
