工作中才发现，交互设计师的职责，不仅是在前期的产出物交付完成即可，更多的任务是在后期的交互验收和优化推动截断。
笔者在学校期间主修交互设计和用户体验方向，做过调研，发过论文，也做过设计，基本上把交互设计师在整个设计流程中的各种职责和任务都体验了一遍，实际看来，学校所得和工作实践的内容基本上是衔接的，这在初期的实习过程中也得到了验证。但是随着项目流程的不断深入，笔者发现，在学校中少学习了一项重要的工作。
为什么学校学习中缺失了这样一环呢？原因很简单，因为学校的项目基本停留在立项——调研——提需求——设计——原型——Demo阶段，也就是说到达Demo阶段后就截止了，这也是各大用户体验大赛的参赛作品递交的终稿。可是实际工作并非如此。能够对着设计稿逐个校对进行验收，是一个普通交互设计师的职责，但是交互验收的过程不只是针对交互流程和逻辑，也包括用户体验的方方面面，以及各种可能意想不到的问题。回复验收邮件，表明在交互层面这个产品是通过的，对应的交互设计师也要承担对应的上线问题的责任。因此，交互设验收也是一个设计师成长的必经进阶之路。
个人理解，交互验收是指在产品初步提测到正式上线前的一段时间内交互设计师对产品效果、流程、体验进行走查验收，提出bug并推动解决的过程。简单理解，交互验收就是走查产品在交互和体验方面的bug。
（1）交互逻辑
交互逻辑是否正确是交互验收主要的一项任务。在笔者的验收经验中，交互逻辑验收主要包含正向逻辑和反向逻辑两部分。
正向逻辑是指在各种预定的操作情境下，用户的每一次操作所触发的对应的页面状态、用户操作是否都实现且满足用户预期，尤其是特殊状态下的页面样式、提示等。这个过程，主要是需要每个状态与原交互文档的页面流程保持一致；
反向逻辑，主要是指返回逻辑。在用户实现某一个功能或完成一个任务返回原页面后，原页面是否需要刷新还是保持原缓存状态。反向逻辑一般都较小，比较隐匿不易发掘，而且在交互文档中很容易遗漏，因此在验收过程需要重点关注，这与实际的用户体验息息相关。
（2）动效时间
只要包括动效的显示时间、持续时间和消失时间的验收。一般的动效主要是指toast提示、小气泡或者其他特殊的手势动效。
Toast提示从出现到消失的提示时间一般控制在3s，500ms出现和消失，剩下2s用户持续显示，达到既能让用户接受到反馈信息，又不会干扰操作和浏览的体验。这时如果持续时间短，用户无法有效捕捉到信息，持续时间长，对于一些高频操作就会出现toast提示叠加现显示的情况，都不是好的体验。
气泡提示一般都是即时出现的，用户更关注持续的时间。气泡除了要样式显著，让用户实时感知到以外，出现的时间也十分重要，因为有些气泡上也会承载部分信息，这点与toast提示相似。3s对于轻量化的气泡提示是比较合适的，2s则会给人感觉跳动，但是对于更重要的气泡提示，可以选择常驻不隐藏消失的策略。
其他的特殊手势操作需要根据实际情况处理。一些细致的交互设计师在交互文档中会标出预期的动效时间，但是依旧需要在测试验收阶段重点关注，判断显示时长在当前用户场景下是否合理，实时、恰当调整动效时间。
（3）点击区域设置或切换
按钮或者表单中内容的点击区域，是交互验收中需要关注的一个比较重要的影响用户体验的“隐性”要点。按照“所见即所得”的原则，一个显著的按钮、图标、头像或者一条表单内容，用户都会习惯性默认为可点击的状态，但是在实际的设计当中，点击区域往往设计得更大一些，这样可增强操作的容错性，让用户较容易通过无论是拇指还是食指都能实现的点击效果，这是涉及操作流畅性一个关键环节。
另一方面，同一固定区域中有多个可操作按钮或区域时，对于实际点击区域的设定尤为关键，例如下图所示。该表单中每条内容均可点击变为选中态，再次点击可取消选中状态。这本是一个比较常见的交互操作，但是在选中态中新增了一个可操作按钮，按钮的实际点击区域一般都是按钮icon的尺寸大小，但是在这个案例中，由于表单内容本身有点击从操作，用户很容易误触而改变表单内容的选中状态，对用户造成困扰和疑惑。因此，实际的点击区域是这个表单内容中按钮所在的整个区域，这样使得用户的误操作几率大大降低。
（4）触发位移
主要包括手势操作的滑动距离以及页面切换时的位移效果，一般需要考虑到手机尺寸、用户的操作舒适区、以及满足操作场景的问题。
（5）小屏手机的兼容
一般不考虑iphone5以下的尺寸，因为那样安卓系统的各种尺寸就无穷无尽了，更别提为每一种尺寸去做适配。但是也不能只以1080作为标准尺寸设计。尤其是对于操作、信息内容较多的页面需要重点关注，在验收时可切换不同机型的手机来验收实际的显示和操作效果确定文案是否折行、按钮排布是否适合点击。
3.如何协调推动解决
公司对于交互设计师一个重要的考量标准就是对项目的推动解决的能力，发现验收的bug如何去解决便是其中之一。在一个较为完善的验收流程中，由测试人员发起验收流程，随后交互设计师验收并提交验收结果，对应的bug转给各自开发人员解决，解决后的程序需要重新提交打包后，由交互设计师验证通过。这一过程一般会往复多次迭代，直至App封版前夕。交互设计师推动解决验收问题，一般可以通过以下方式进行。
提交验收报告：
一般仅需以邮件形式回复验收结果，内容较多时可附上对应的附件文档。提交后测试人员会重新审核后提出对应的bug给开发人员。在这个流程中，交互设计师与开发、测试人员的沟通相对较为滞涩，三者之间的沟通存在壁垒。导致效率较低，同时不利于后期的改动追踪和改动效果的验收。
在管理系统中提交bug：
直接针对平台、版本、功能模块提出对应的bug，便于交互设计师管理、跟踪自己bug的解决情况，同时也便于开发人员认领属于各自的bug。在这个流程中，测试人员提供对应的辅助工作，交互设计师与开发可直接沟通，对于验收进度的提升和产品功能的优化都有很好的推动作用。
直接线下找对应开发GG沟通解决：
是最快、最直接的一种问题解决方案，但是不适宜在提测初期使用，原因有几点：首先是寻找到对饮的开发有时比较难，尤其是面对一个较大的开发团队时，一个功能可能涉及多方开发人员的共同实现；其次是针对较复杂问题，沟通时容易遗漏；还有就是人力问题，当面沟通效果好，但是对人力成本的小号相对较大，无论是精力还是体力。面对面沟通解决适合在产品验收后期功能微调和页面的小改动，可与开发人员当面快去沟通后协调解决。
4.验收报告（邮件）怎么写
首先要明确验收报告上的几点问题：
1）.实事求是，不夸张事实。验收是提出问题、解决问题的过程，不需要对现象的夸张描述，对于问题的描述力求简洁、明了，同时为了保持PM、交互设计师、开发人员认知的一致性，尽量使用公司内容一致的描述方式，以及附上对应问题页面截图作为补充。
2）.给出问题解决方案或预期效果；bug也分很多种，有些是yes or no的问题，只需指出问题点即可，如：
“在用户未登录状态下，用户头像上不显示登录角标。”
但是有一些涉及体验问题的bug，不是yes or no的问题，而是good or better的问题，因此需要给出相应的解决方案或预期效果，如：
“问题描述：在未登录状态下点击播放列表时，页面仅提示都需要登录状态；预期效果：在未登录状态下点击播放列表时，页面出现登录状态文案提示，同时露出登录按钮，点击可直接跳转至登录页面。”
3）.标注优先级：优先级描述能够告知相关人员问题的严重程度，便于开发人员合理安排自己的工作进度，这是一项利人利己的事情。
关于验收报告的格式，可以参考一下样式：
下面仅提供一下word版本验收报告样式以供参考。
工作中才发现，交互设计师的职责，不仅是在前期的产出物交付完成即可，更多的任务是在后期的交互验收和优化推动截断。以前觉着给出交互文档比较重要，工作量大，但是后来才发现，每一个版本的验收工作才是更加费心费力的，毕竟需要交互设计师主动去推动一个bug的优化，而不是收到需求后仅仅是输出文档就ok了。
