聊聊用户体验与常规缺陷的异同
这是鼎叔的第七篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。
越来越多的公司把用户体验作为安身立命的根基，不断发起提升用户满意度的革命。在这个过程当中，测试团队往往被寄予厚望，希望测试人员和测试平台能够在这方面发挥更大的价值。
但实际上，测试团队的传统工作内容和用户体验内容有着很大的差异。11月在MTSC-中国移动互联网测试开发大会，以及深圳敏捷之旅中，鼎叔分享了《提升用户体验的评测方案》这个议题，给出了一个初步体系化的测试方案，让测试团队以较少的训练成本，能够逐步扮演好用户体验提升的关键角色，在公司和业务团队中得到更多的影响力。下图就是方案的内容总览：
本文是该主题的系列文章第三篇，展开分享测试团队应如何理解用户体验模型，到底它和常规测试关注点的区别是什么，以及管理者如何培养测试人员对用户体验的关注习惯。
前两篇文章：聊聊NPS-提升用户体验的终极问题，聊聊不良利润-如何让产品更善良
曾经有公司高管对我们测试部门提出质疑--也可以说是期望： 测试团队能否多发掘一些用户体验问题？
很多问题显而易见对用户体验有伤害，比如同样的功能，在不同流程中交互风格不一致（像是两个团队的作品），但是测试报告里几乎没有提到过。
甚至有人提出这样的灵魂拷问：测试团队除了报告一大堆缺陷，能否给出结论，到底产品品质的竞争力是高是低，和竞品对比如何？
测试团队对用户体验问题的态度，为什么总是欲说还休？
很多测试团队，并没有把用户体验作为测试考虑范围，主要原因：
1. 用户体验不一定是客观的产品实现逻辑或者可精准度量指标，无法简单判断是否缺陷。
2. 影响某些效率考核指标，如缺陷无效率，测试用例（发现缺陷的）有效率，等等。
3. 测试团队对用户体验涉及的广泛知识，缺乏专业培训和掌握，如交互设计，体验度量指标体系等。
但从另一方面，测试团队有时也被寄予厚望，希望能对用户体验提升作出把关：
1. 用户体验效果受公司管理层重视，测试如果能高效挖掘更大的价值，会提升自身地位。
2. 测试作为用户品质的守护人，理应为用户体验发声。
3. 测试活动覆盖了大量的用户使用场景和路径，投入人力多，更有利于系统发现用户体验的问题。
用户体验提升的评测方案，目标就是给出测试团队的指南：通过实践，用尽量少的认知成本，尽量高效的实践方法，敏捷反馈体验问题。明确哪些属于缺陷（应该修改），哪些属于建议（需要产品/设计综合考虑决策）。最终把有效的实践方法汇聚成用户体验的测试诀窍知识库。
同时，我们也要承认，用户体验设计的专业领域博大精深，如果没有深入的学习积累，很多判断上还是要虚心听取专业人士的解释理由，不要刻意捍卫自己反馈意见的优先价值，多从用户真实反馈数据出发思考。
定义用户体验的模型
关于用户体验，行业有多个经典定义模型，简单概述如下：
蜂巢模型（Peter Morville）
把产品设计的价值分为6个模块：Useful（有用），Usable（可用），Desirable（合意），Findable（可寻），Accessible（可及），Credible（信任），Valuable（价值）。
蜂巢模型能够帮助人们迅速理解需求并定义需求的优先级，综合考虑环境，内容和用户的平衡，有利于针对特定目的改善设计，并审视价值。
5E原则（Whitney Quesenbery）
从可用性出发，研究产品的五个属性：Effective 有效性, Efficient 效率, Engaging 吸引的, Error tolerant 容错, Easy to learn易学。这五个属性不一定是同等重要的，对于不同的产品，不同的用户，部分属性应该放在次要的位置上。通过5E进行思考带来的价值要比简单理解用户的利益走的更远，它可以在必要时进行平衡，给出设计方法和辨明方向。
用户体验的循环模型
用户体验不是一次简单行动，它是试图满足希望，梦想，需要以及欲望的关联在一起的循环，它由这些动作组成：触发Trigger，期望 Expectation，接近 Proximity，知晓 Awareness，联系 Connection，行动 Action，响应 Response，评价 Evaluation。
用户通过比较自己的期望和系统的响应，得到满足，或者调整期望，或者放弃使用系统等等。
情感化交互设计模型
“当技术满足了基本需要，用户体验便开始主宰一切。”--唐纳德·诺曼
本模型提出了大多数技术产品和服务的体验都会经历的六个成熟等级，从“嘿，这玩意能管用”到“它让我的生活充满意义”，即：实用（有用，按计划进行），可靠（有效而准确），可用（使用起来没有难度），易用（快捷方便，无需特别记忆），令人心动（值得宣传的难忘体验），意义深远（对个人意义重大，品牌第一选择）。
这个模型比较完整的体现了现行用户体验的关注层次，概念认知度高，
因此我推荐用它来做测试团队理解用户体验的基本模型，并能从每一个层次中找到生动的可度量例子，便于成员理解，例如：
实用：度量有多少用户在使用该功能，活跃度如何。
可靠：度量稳定性指标，服务稳定性，接口可用性等。
可用：度量新手用户关键任务完成率/正确率等。
易用：度量关键任务平均完成时长，步骤数等。
令人愉悦：看用户产品使用满意度调查等。
意义深远：看用户首选品牌占比，品牌NPS排名等。
用户体验问题与常规缺陷的异同
测试人员常规提报的产品缺陷（功能或性能等），和用户体验反馈的问题，有什么异同呢？
相同点：
两者都会涵盖：直接影响用户感受的产品逻辑缺陷，性能缺陷等。
不同点：
常规测试会汇报用户暂时感知不明显的错误和风险问题，如内存泄漏，内部定义错误，极端场景问题等，部分安全技术漏洞等。
而用户体验问题不只是客观逻辑问题，也关联到负面情绪体验：惊吓，愤怒，迷惑，鄙视，烦躁等等，都会反馈在用户投诉中，对于呆在实验室中忙碌的工程师，可能对于用户反馈的负面情感缺乏共鸣。
用户体验和用户的背景强相关，比如：年轻人体验觉得正常的产品，年老的人用起来会觉得差，如字体太小，或操作按钮不知放在哪里了；资深用户习以为常的快捷键，新手觉得抓狂，没有合适的新手引导；产品的简单英语提示，对于多数人来说感觉轻松诙谐，对于英语小白来说可能会感觉不爽。
我们看到，不少测试工程师对待用户反馈的态度，并不是站在用户视角，而是站在工程师视角，自然对改善体验的思路视而不见。
比如：手机垃圾清理功能，用户投诉等待得太久了，测试工程师觉得不是大问题，产品已经说明了该过程会长达几分钟，只要不超过就可以接受。实际上从代表用户的角度，可以提出更多的改进建议：如增加等待进度条，可以后台操作并及时提醒，可以同时玩一个趣味游戏，可以选择不同力度清理垃圾（对应的耗时不同），等等。
作为团队的主管，如何让测试同学培养“以用户为本”的观念？
关键是提升代入感（共情）：在物理上接近用户-多走进用户使用的场景和用户当面交流，在立场上代表用户-不让用户（自己）吃亏，把自己变成真正的用户。
我们通过在需求阶段的测试左移活动，培养测试人员不但眼里要看到用户的行为，心里还能感受用户的情绪和想法。然后在测试过程中提炼容易产生共情的探索式测试方法（未来会详细介绍）。