探索B端体验走查

导读：对于我们设计师来说，现阶段的工作不仅仅是我们的效果图完成后，就结束了工作，而是还要有比较可行的方法，去验证设计成果，那么就要用到体验走查。体验走查有助于我们去在设计过程中包括设计后去发现可用性问题，然后去推动整个产品的迭代优化。本文主要以公司的项目为例子，进行走查工作。就走查工作而言，不仅仅是走差，作为设计师我们更应该去针对问题提出优化方案。

第一步：确认走查方法

说到产品的体验走查，大多数人的第一反应是可用性测试，但是基于我们公司内部的使用情况，物业CRM的用户群体主要是整个集团的开发人员，再加上可用性测试需要我们 设计师去观察用户的使用场景，而我们设计部门从未做过这样的测试，使用这个方法可能很有难度，所以我前期就否定了可用性测试。在网上找到了“启发式评估”。

启发式评估是以我们设计师为视角，利用尼尔森启发原则进行走查的方法，而且不限定于产品的任何一个阶段使用，也是一种比较快捷并且节约成本的方法，这里不做过多的方法的特征和解释。

第二步：制定评测计划

进行走查，我们不能一上来就搞太多界面模块，如果拿不准，可以自己去找相关负责人去商量，拿个别比较有代表性操作和流程的页面。我这里最初有一个自己的想法，之前去找的产品组长商讨这个模块范围的问题，能多听听他们的想法，对走查也有帮助。最终我们确认出了走查物业CRM的3个模块。注意这里评估的范围和需求不要太多。（做到这一步的时候我以为3个模块刚好，其实做到后面我傻眼了）

第三步：制作走查物料

1.1走查工具-《交互原则》

要让我们目前的6个设计师都参与到体验走查工作中，我必须为全员提供一个简单可信赖的走查参考标准，方便我们设计部门以后日常项目走查时候，能够以此为参照，去正确的，专业的进行走查。很多走查的工具都是基于尼尔森十大可用性原则来进行的，这里我进行了一点扩展，因为这是部门第一次做走查，我希望尽量做得细致一点，于是下来又去找资料，形成了下面的《交互原则V1.0》

1.2走查问题等级-《问题缺陷等级表格》

根据我们对系统进行的可用性所造成的影响，我们可以把问题按照严重性分为4个等级，这是基于发现问题严重性的定义描述，需要设计师在评估前去学习掌握，因为我们设计师在这之前对于问题的严重程度理解不一样，所以要统一标准。

1.3走查问题原则-《体验评估的核心原则》

在走查的时候，可能每个设计师心里的标准不一样，所以需要制定一个原则

1.4走查模块流程

走查的时候有了工具和方法，仅仅是不够的，我们还要培养全员的体验走查意识和习惯，建立常态的体验走查制度，让我们部门的成员都能参与其中，

然后我又输出了《体验问题汇总表》模板，方便各个设计师走查的体验问题，能够按照同一套标准惊醒输出，方便大家理解，同时还增加了跟进责任人，当前进度的字段，保证我后期能把体验问题完整的跟进，维护，落地。

最终这个应该是一份完整的体验问题清单，内容包括每个问题的场景，模块，截图，问题描述，问题级别，交互原则，优化方案，解决优先级，责任人，当前进度。这是对项目的全面总结，也能给产品后续的工作落地形成具体的指引。

1.5体验走查场景表

由于其他设计师没有做过我的产品，不了解系统的用户和流程，我作为领路人，需要一个场景图，我看网上说是去借鉴测试的测试用例表，整理每个模块完整的体验走查。这里我没有去找测试用例，因为这个模块开发已经很久了，至少有4年之久，要去找测试用例可能不现实了，所以我只能自己趁热打铁，利用前面制作好的的工具模板，进行一个预走查，边走查，边形成一个完整的场景表格，也就是做了这个场景走查，我才意识到刚开始以为3个模块不多，是我太不了解产品的逻辑和需求了，然后在走查场景表制作到一半的时候，砍掉了一部分内容（建议设计师一定要去看各个子页面的数量和逻辑）

第四步：走查问题汇总

在整体功能流程走查完后，我们就需要做问题的汇总，填写记录表，方便后期查看。然后在设计部门内部，开会讨论，把想通/相近的问题统一，可优化的问题保留下来。

例如：把项目信息/项目跟进/项目审批作为图表形式展示问题数量分布，然后利用可视化对比各个模块问题数量及严重程度的分布情况，这样一目了然。

看到问题数量，还是有点吃惊，因为大家自身经验不通，在统一评价标准下，还是会有一些主观因素。

第五步：后续优化跟进

体验走查完成并不代表结束，如何推进后续的优化方案才是重头戏

首先，我们需要得到产品经理团队的认可走查结果，这涉及信度问题，（前面就提到，在做工作安排之前，我已经提前通知了产品组长，并商讨了模块的范围）这个信度是相对的，我们以上面的这些准则统一评测标准。

后续需要我作为设计师，去把问题汇总，和产品经理一起评估问题，对其进行分级，并按照问题严重级别，分步推进。那些问题需要转化为需求，提到项目测优先解决，都是后续的工作。