一 用户体验概述

1.1 用户体验的定义、要素和价值

1.1.1 定义

用户体验的最新定义（ISO -9241-210:2019）为“用户体验是指用户对系统、产品或服务的使用和（或）预期使用所产生的感知和反应”。

1.1.2 要素

 通过用户体验的定义和要素，可以看出用户体验测试应从产品使用前、使用中和使用后产品的全生命周期来观察和提升的视觉、信息传达、交互行为、功能、系统性能以及系统、产品或服务辅助功能的结果中着手发现不好的用户体验。

1.1.2 价值

总结来说，用户体验测试的价值体现在：

1. 用户体验越来越受重视，测试阶段发现用户体验缺陷能省去后期不必要的调整成本。

2. 测试作为产品质量的守护人，用户的“代理人”，强调用户体验能让产品在同类产品中突出，具有竞争力。

3. 测试活动覆盖了大量的用户使用场景和路径，投入人力多，更方便的发现系统用户体验的问题，能提升测试话语权。

1.2 UED原则和体验度量模型

1.2.1 用户体验设计的原则

Whitney Quesenbery 的 5E 原则

 尼尔森十大交互原则

 用户体验测试应从UED方案评审时就开始，测试人员参与会议并可依据用户体验设计的原则进行评审，每项设计都应遵循尼尔森十大交互原则。在测试用例编写时，也可以依照该原则对每项功能列出测试用例。

1.2.2 传统的体验度量方法

业内有很多产生量化体验结果的方法论，包括调查问卷、可用性测试、A/B测试、访客分析，和通过大数据度量并管理用户体验。

• 调查

比如NPS净推荐值、CSAT满意度都属于调查的形式。通常还包括是/否的选择、等级量表数据（满意、不满意、特别不满意等）、评论和开放性数据（比如平台用户评论、工单的反馈等）。然而这些评分仅能够反应用户对产品体验的整体感受，却不能确定用户是否完成任务目标，也不能通过一些客观数据获取到一些典型的度量指标，比如任务完成率、任务时间、出错率、界面可用性问题等。

• 可用性测试

用于研究用户体验数据最终如何在产品开发生命周期中进行使用，本质上区分为两种测试方式：

• A/B 测试

就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符合设计。测试范围也不仅仅局限于网页优化，移动端的A/B测试需要同时支持前端（Web/H5、iOS、Android）及后端（Node.js、PHP、Java）

1.2.3 常用的度量工具和模型

• 常见的用户体验评估测量工具：CSAT，NPS，SUS，SUM等
• 常用用户体验度的模型：阿里的UES模型、适合网站的PULSE、谷歌的HEART、蚂蚁的PTECH、K-MUX模型和GSM模型

• 模型名称	简述	总结
  UES模型	UES（User Experience System）是阿里云设计中心通过多年设计实践中沉淀下来的云产品使用体验度量系统，它不仅是一套方法论，更是一套可运行的体系，由三大部分有机构成： 第一：一个包含五大维度的 UES 体验度量模型。 第二：一个体验问题从发现到闭环的体验管理机制。 第三：一个易用性测试和数字化管理的体验工具集。
  PULSE模型	PULSE模型（Page view、Uptime、Latency、Seven days active user、Earning）：是传统的网站衡量指标。主要是用来衡量网站基于商业和技术的产品评估，被很多公司和组织广泛应用于跟踪产品的整体表现。
  HEART模型	Kerry Rodden 作为谷歌资深用户体验研究员和数据分析师，2010年在大量度量用户体验的探索与实践中总结出了HEART用户体验度量模型，帮助团队高效选择正确的数据指标。 该模型在谷歌内部广泛使用，并通过论文、博客等渠道传播，使其他公司、团队也能够在使用的过程中受益。 以使用者为中心的HEART
  PTECH 模型	PTECH是AntD基于HEART 模型，根据企业级产品实际情况修正得到的 PTECH 度量模型，用于度量企业级产品体验。	Performance——性能体验； Task success——任务体验 ； Engagement——参与度 ； Clarity——清晰度 ； Happiness——满意度。
  K-MUX模型	为了达到产品⾼效，统⼀，灵活和有活⼒的体验，结合国际⽤户体验平均指标，制定了4个衡量维度来帮助产品达到预期的影响⼒，即：设计规范性、使⽤流畅性、性能稳定性、⽤户满意度。
  GSM模型	GSM模型（Goals，Signals，Metrics）：是Google提出的一种自上而下度量用户行为的方法，通常用于衡量产品/项目目标的实现程度。

用户体验模型通常是由专门的用户体验设计团队依据部门产品特性研发出的一套包含度量维度、指标、方法、工具的方法论。实际应用中应根据不同产品建立或者选择合适的模型进行使用。

二 用户体验测试的痛点和挑战

2.1 测试中面临的问题

2.1.1 测试中的关键问题

1. 用户体验不一定存在客观的产品需求中或者有可精准度量指标参考，无法简单判断是否需要更改。

2. 影响主流程测试进度以及某些效率考核指标，通常会优先解决功能测试中发现的缺陷，在排期紧张的项目中，对于难以把握的用户体验，需要花费宝贵的时间进行确认再改造以及测试。

3. 用户体验涉及的知识非常广泛，测试团队对于交互设计，体验度量指标体系等认识不同，无标准规范，判断偏主观。

那么如何提升用户体验测试效率呢，可以从以下角度切入：

一，从用户体验模型出发，学习NPS体系和用户体验变革的系统打法，深入思考测试在其中应该承担的角色，科学的找出可度量指标。

二，从测试设计出发，以用户共情为纽带，面向用户价值做设计（ACC模型），积极参与可用性测试，组织竞品核心能力对比评测，引入创新的自动化对比方案。

三，大力实践挖掘用户体验问题的探索式测试方法，从用户角色视角、利益、触点出发寻找问题，利用交互规范寻找不和谐的体验细节。

2.1.2 用户体验测试方法

1. 角色扮演测试法/肥皂剧模型 （见系列文章）
2. 不良利润分析法（见系列文章上、下）
3. 竞品卖点对比评测法（见系列文章）
4. 用户旅程触点测试法
5. 差评分析法/博客测试法
6. 交互规范测评法
7. 放大缩小测试法

用户旅程举例：

借助用户旅程触点的梳理方案，我们可以盘点整个产品服务周期中，用户有哪些接触渠道和主要感受的品质表现，主要的操作步骤，从中确认是否有用例完善覆盖。
举例：
以“众包APP”为例，看看如何设计用户旅程触点的探索测试方法。步骤如下：

1）分析众包APP用户有如下这些关键接触动作：
用户通过各个渠道（海报二维码，公众号，APP PUSH，官网）接触众包宣传。
下载APP并安装。
初次使用，登陆/注册，认知主要功能。
初次认领众包任务，尝试如何报名接受任务，如何使用反馈工具。
初次提交反馈成果，看到反馈处理状态，和任务管理人员互动。
提交任务成果后，收到积分，随着积分越来越多，开始兑换奖励。
定期收到平台奖励新活动，查看自己排名，解锁新玩法。
过程当中，遇到平台使用问题，或者审核问题，对任务管理人员进行投诉和咨询。
因为个人原因或者体验不佳，退出登陆，或者注销账号，并卸载产品。

2）提炼出该触点场景中，重点测试保障点是什么，确保重点探索覆盖。例如：
用户在各个渠道可触发下载的入口：二维码/网址/软件商店下载页，随时可以打开，活动H5页面可以正常访问跳转。
打开后首次使用，新手指南清楚正常，各个板块初始化正常。
正确进入注册/登陆界面，未登录不能看到个人专属信息，几种登录方式都顺利，可以找回忘记密码，等等。
整个任务的清单查看，详情，报名成功，指引信息完善，提交众测问题过程顺利。
成功提交众测反馈，查看状态正常，处理流程状态更新正常，积分刷新正常。
任务结束后，不能再反馈问题。积分数据正确，可进入积分兑换页面，顺利进行奖品兑换。

3）以上只是列出了参与众包者的触点旅程，还可以从众包发起方的视角进行用户触点旅程场景梳理，重新盘点测试点。
比如：发起方从众包后台发起测试任务-> 众包平台审核通过-> 任务生效，招募成员完成 -> 任务进行中，
问题反馈涌入进入后台-> 发起方在后台查看反馈并及时处理-> 和平台方沟通任务进展和用户投诉事件-> 任务完成，
收到众包测试汇总报告和费用结算清单-> 随时后台发起新任务或者提交新需求。


差评分析举例：

根据论坛抱怨（如百度贴吧，产品论坛），博客的各方观点，客服反馈渠道（客服电话，公众号，邮件等），产品内置反馈入口，NPS差评原声等渠道，能够帮助核实用户抱怨的质量问题，并采取预防行动。推荐流程：

1）先由客服进行第一轮梳理
2）定期同步结果（按周或者其他频率）
3）记录TOP客户集中投诉/高危投诉的排名，及时输出TOPN客户关注报告。
4）进行基本的分类，便于相关团队具体跟进。如果是疑似缺陷测试记录，是产品建议交给产品经理/设计师，运营投诉则交给运营团队。
5）测试团队再根据客服初筛报告做可测试价值的提取，锁定明确的用户场景进行针对性探索。
探索的优先级可以参考：客服/团队优先级、用户反馈的真实性、发生频率和损失严重程度等，综合确定。
举例：看到用户在官网论坛投诉的“软件流畅度太低”频繁出现。
进一步沟通和确认探索场景范围：用户在哪些场景会投诉流畅度？用户评价高/低的基准是什么，是否有可对标的产品使用经验？具体操作场景和测试值如何定义？该场景流畅度数值达到多少，用户就不会抱怨了？这些测试场景能否作为挖掘流畅度问题的固定打法，让其他人员和其他产品直接借鉴？


交互规范测评举例：

借鉴/学习公司的交互规范，也包括产品交互文档，看是否符合常理，符合用户的使用习惯，用较低的学习成本发现交互问题：

1）明显违反交互规范/产品规格的问题，提报缺陷；2）没有明确违反规范，但是我们有更好（简洁，清晰）的交互思路，提报建议，最终由团队给出答复。

探索的重点在于：交互逻辑一致性，交互完整性，UI风格一致性，以下为一些典型的容易发现问题的场景：

产品的各个核心页面的控件风格一致，图标风格一致，语言风格一致，不要出现不像一个团队作品的明显差异。
页面元素，内容标签分类一致，不要出现不同种类的元素混在一起，颜色也要有清晰的区分。
导航效果符合连贯性，前进和后退符合预期，不要出现深入几层界面后，点击后退直接推到了主界面。
特别留意很多页面看到的内容，对于已登录态，和未登录态，看到的信息是不一样的（应当明确约定展示内容），根据查看需要来吊起登录框。这块也容易发生安全漏洞。
跨应用操作。用户在操作旅程中，可能要离开本应用，去查看其他手机应用信息（比如查看短信验证码，相册图片等等），然后回到本应用界面重新输入，这时要看是否能切换回原界面（有的银行APP在查看短信验证码后，切回来直接重启到主页面，让用户无法输入验证码，很抓狂）。
海外业务APP，要根据特定文化/语言习惯来探索交互界面问题和文字/图片问题。如UI布局，菜单语言，当地专属名词（日期，单位，宗教，节日等），图片内容合规，左右语序编排，切换各种语言后的翻译表现等。


放大缩小举例：

从上述方法提炼出来的快速发现显示问题的变种：把系统字体调到最大，分辨率调成最低，看界面显示情况，如按钮被遮盖等；或者把页面放大到极致，再缩小到极限，看看图片是否出现显示异常。

2.3 用户体验反面教材

• TOP1:加载不同步、慢、按钮无反应，持续几秒钟、会有卡顿现象、搜索很慢、等待10多秒页面才加载出来、可能会出现黑屏或卡顿情况、数据量太大导出没反应
• TOP2:容易误操作、不小心碰到、容易误点到其他操作、经常会误删其他内容、键盘回车换行依然触发搜索、用户会误以为图标为其他含义标识
• TOP3:复制的@需要重新操作才生效、每次进入重新设置、需要打开其他功能页面查看、一个人一个人去、权限一个一个去申请、重复多次的重定向

以下排序不分频次

• 字号编辑、文本格式需要调整、从其他文档复制过来的时候字体大小不一致、图片太小很难扫
• 掉线了，找不到号、按钮隐藏较深、难定位刚创建的副本文件位置、定位不到具体回复
• 没有展示状态、取消依旧是忙碌状态、时间更新后，应答状态没有变
• 没有任何提醒、建议增加邮件提醒、始终没有消息、会议结束后还重复提醒
• 非24小时制的情况下，内容显示不全、用户头像显示一半
• 通过图标、提示无法区分
• 无效消息不可查看、创建人无效导致无法查看文档
• 图标上无法区分出是实体文件还是快捷引用
• 不方便找到系统入口，系统名有歧义
• 弹窗或其他元素遮挡、指引无法关闭
• 不同端、不同版本体验不一致
• 未排序、希望可以倒序排列
• 需要增加操作的业务说明
• 新老版本图标布局不清晰
• 提交申请需要撤回功能
• 只能支持编码搜索
• 文字内容无法复制
• 有错别字

参考资料：

• Thoughtworks中国用户体验度量系列的文章：
• https://zhuanlan.zhihu.com/p/595471979
• https://zhuanlan.zhihu.com/p/595480817
• https://zhuanlan.zhihu.com/p/595484690
• https://zhuanlan.zhihu.com/p/340675631
• 面向用户体验的探索式测试：https://zhuanlan.zhihu.com/p/473125628
• 用户体验评估方法汇：可用性测试：https://www.woshipm.com/user-research/674422.html