用户 网页 可用性 编者按：这篇文章出自用户体验设计行业内的资深机构 NNGroup，他们一直谨慎而专业地对行业进行审视、分析和总结，这篇文章更新于 2023 年第一天，他们通过真实的用户调研和持续的观察，梳理了最近几年移动端 UX 设计的变化，下面是正文。从 iPhone 诞生到现在已经15年了，移动端的用户体验设计的综合素质已经相当稳定了。移动端的标准已经制定完全，移动端 Web 应用和本地应用之间的界限也越来越模糊了。最初的 iPhone 是在 2007 年 6 月发布的。2008 年底，我们开始发布了第一版「移动端设计报告」，当时绝大多数的用户所使用的移动端设备，用户体验是相当糟糕的。当时，与绝大多数的移动端网页和硬件设备相比，程度能到「勉强能用」的APP或者网页，都已经算是极佳的用户体验了。而在5年前，我们发布第四版「移动端设计报告」的时候，我们对移动端产品的可用性状况进行了全面的评估。但是我们很高兴地发现，绝大多数的移动端 APP 和网页都提供了良好的用户体验。随后的第五版报告中，我们看到了持续的进步。此刻，移动端用户体验终于抵达了成熟期。移动端设计变得更加稳定，而多实验性设计和功能的接受度有所降低。此外，移动端成为主流，用户几乎会在移动端设备上尝试完成几乎所有人物（尽管用户仍然喜欢在大屏幕上完成更重要的任务）。很少有公司现在不碰移动端的业务。在今天的这篇文章中，我们将会突出探讨移动端设计的现状以及一些突出的主题。0、调研用户基于第五版的移动端可用性报告，我们进行了远程测试和面对面的可用性测试，涉及 19 名美国的参与者，它们测试了总计 60 个不同的网站和 APP。1、设计风格的融合过去几年中，最大的变化是设计风格的融合。在更早一些时候，许多网站和 APP 的设计者会尝试新的交互方式和布局结构，而如今我们可以肯定的说移动端交互已经稳定下来了。很多设计模式已经成为标准，并且大家对于什么时候用什么设计元素有了清晰的认知，比如导航栏和汉堡菜单，如今已经达成某种平衡，绝大多数的网站和 APP 会选择其中一个作为主要的导航模式。尽管按照「信息气味理论」，汉堡菜单的数值偏低，但是它依然成为了主流的方案之一。这种融合出现在方方面面。比如 iOS 和 Android 如今就变得和彼此更加相似，这也使得设计师可以可以毫无挂碍地为两个平台设计近乎完全相同的 UI，而不会影响最终 APP 的可用性。其中最典型的变化，就是 苹果官方出的 iPhone 和谷歌官方出品的 Pixel 系列都将屏幕的 Home 实体按键去除，而界面交互几乎完全仰赖手势操作。苹果将 3D Touch 去掉之后，Android 和 iOS 如今使用着完全一样的长按呼出菜单。2、「完整网站」的消亡最近一次移动端可用性设计会当中，我们很惊讶地碰到一位参与者，他不知道我们所说的「完整网站」是什么意思。在很长一段时间当中，移动端访问网页的时候，打开的是专门针对移动端设备开发的精简后的「移动版」网页，而原本针对桌面端设计的网页会「更加完整」。虽然有一小部分用户可能会青睐于在手机上访问桌面版的页面，但是绝大多数人不需要这样做甚至不知道有「桌面版」存在。由于响应式设计的存在，如今绝大多数的网站从功能到内容都可以兼顾桌面和移动端两种环境，内容不适配移动端的情况越来越少，几乎不存在了。3、原生应用和 web 应用之间界限更加模糊对于开发者而言，本地原生应用和 web 应用在技术层面上几乎完全不相同。而对于用户而言，两者仅仅是渠道有所不同两种应用工具。在过去5年当中，两者甚至在渠道之间的界限也都变得越来越模糊，至少在用户层面的感知是这样的。首先，web 应用和原生应用之间的差异正在变小。随着渐进式web应用（PWA）的出现，我们现在拥有和本地应用高度相似的移动端网站，它们可以拥有一个独立的图标，单独在后台运行，甚至可以接入推送通知等手机功能，而这些在之前是不可能拥有的。BMW.com 的网站以 PWA 应用的方式存在同时，原生应用需要和网络更加靠近才行。原本必须要安装到本地的应用正在变得更加轻量、易于「安装」，iOS 平台上推出了 App Clips，而 Android 平台上一会儿有对应的即时应用程序，它们让用户无需安装即可提前体验 APP 在本地于运行时的功能。这种机制又更加靠近 PWA 应用的体验，两者之间的界限变得更加模糊难明。4、更简单的登录和注册登录和注册的用户体验升级是移动端用户体验进化的标志之一。设计师汲取了来自方方面面的经验教训，非常确定在移动端小屏幕上输入密码是一件乏味的事情。如今有很多不同的方式让登录和注册变简单，有的是基于身份验证机制（面部识别、指纹验证等），有的是基于已有的支付接口（Apple Pay、Google Pay、支付宝等）的方式，有的则是内置于浏览器和系统的密码管理器，设计师已经在尽力缩短登录的流程。而注册的新趋势是「无密码帐号」，无需定义密码即可创建帐号，着是基于一次性密码（OTP）和魔术连接（magic link）的机制，其中，一次性密码我们应该都很熟悉了，密码或者验证码通常是系统发送到绑定的帐号或者手机号上，借此实现注册和登录。苹果的密钥机制则更进一步，系统自动创建，然后加密存储于云端，用户甚至不用知道他们的密码具体是什么。5、围绕小屏幕设计我们在几年前已经注意到，设计师已经开始有意识地针对小屏幕的限制来设计网页和 APP，如今，这种趋势更加明显，设计师将不必要的 UI 元素熟练地隐藏起来，让用户在滚动浏览中自然获取信息，首屏也不再是堆满功能按钮的垃圾堆。然而另一方面，我们依然注意到很多网页还是会因为一些不必要的元素被刻意拉长，其中很多确实是基于「用户是通过移动端访问网页」的这种场景来进行设计的。但是，需要强调的是，用户仅仅只有在认为你的内容有价值的时候才会继续滚动，如果重要信息之前是一屏无关紧要的低价值信息或者装饰的时候，他们可能会在滚动之前就直接放弃了，而这种情况在注意力被高度稀释的今天，只会越来越频繁地发生。BankofAmerica.com 的页面中无效的装饰信息拉长了整个页面。6、叠加过多功能在几年前观察的时候，我们就注意到移动端页面上叠加了过多内容的情况，而如今这个问题也同样被放大，变得更加流行。很多网页一打开就出弹出框已经是基本操作，更有甚者直接拉满，右下角是聊天气泡，顶上是弹出框请求 Cookie 权限，中间是广告和促销，就这种局面下还有网页本身的汉堡菜单和导航栏藏在首屏上。不幸的是，即时用户不被这些东西烦死，互相叠加覆盖的功能同样很容易出现各种可用性问题。有的是功能本身在不同设备上加载时因为兼容性差异自然出现的，还有的则是因为用户以为它们是无关的新页面，直接关掉。7、应用内浏览器另外一个重要的趋势是应用内内置浏览器的流行，这种技术的好处在于，用户在应用内点击某个链接的时候，无需跳转出去直接就能在应用内加载页面内容。它的优点在于留存用户，但是它的缺点也在于它容易让用户感觉迷惑和混乱，突然打开网页可能会让用户忘了他们在哪，并且可能因此很难再次打开对的链接。此外，应用本身的 UI 元素也会干扰内置浏览器的使用，比如屏幕内出现2个汉堡菜单这种情况。另外，由于内置浏览器的可用性，可能会有的页面 UI 元素无法完全加载，页面出现多个汉堡菜单，导航功能和 APP 自带的导航栏同时存在。页面中按钮被覆盖，无法完全加载。结语必须承认的是，移动端的用户体验比以往任何时候都要好，网页、本地原生应用之间的一致性正在变好，用户已经适应了绝大多数常见的交互模式，在移动端上请求桌面端页面的情况发生的频率在降低，但是移动端体验距离完美还有很长的一段距离。本篇来源：优设网原文地址：https://www.uisdc.com/state-mobile-ux-2023
产品 用户 可用性 设计师心中的用户和实际情况中的用户之间存在着很大的鸿沟，我们需要利用用户研究来解决这个问题。有时候设计师自认为比较好的方案，到了评审会上，会被各种似懂非懂的人提出各种问题。为什么说似懂非懂，因为评审人里面有产品、研发、业务方等，这些人在自己专业领域都很优秀，但大多数并不太了解交互（设计心理学、交互原则、设计系统等）是什么，都是凭自己的感觉去说，这个时候很多设计师就没招了，只能听着各种“我感觉”来给你提意见，为什么会这样？因为他们知道你也是“我感觉”，你能感觉，为什么他们不能感觉。设计师觉得自己像个改图的机器，应该就是这么来的。感觉这个东西是不确定的，也许下次评审他们感觉又变了...解决这个问题的方法之一就是去做用户研究，要知道是谁在使用你的产品。确定用户，了解他们的期望，调查他们的需求，这些都是设计任何一个产品的起点。因为你的用户不是你，他们的思考方式和你不一样，做事情的方式不像你，也没有你有的期望和假设。如果他们和你一样，他们就不是你的用户，而是你的竞争对手。这个时候做 B 端的小伙伴就要问了，我们都接触不到真实用户。确实，B 端相对 C 端比较难，但也不是不行，要看你所属行业。比如像钉钉（面向制造业），顺丰（仓储物流）这种 B 端产品还是相对比较容易的，只要公司支持，可以去企业工厂或者仓库看终端用户是怎么工作的。B 端重业务和提效，去实地考察就可以触达这两块。不过也要看领导层对设计（用户体验）这个部门的认可度，如果领导层觉得设计就是美工，基本就真的只能这样了，这也是很多大佬说的环境和领导很重要的原因。进入正题...更多可用性测试干货：如何做好可用性测试？高手总结了这6个阶段！本文带大家梳理一下可用性测试的概念和研究方法，帮助大家做好可用性测试。阅读文章 > 一、用户研究的好处基础的用户研究简单、快速而且高效，对任何产品都能进行实施，关键是你是否愿意动手去做。通过观看、聆听、记录，你就能更好地了解你的用户（客户），更清楚产品哪些地方不好用。二、小型可用性测试可用性测试能说明受众是否能使用产品。它有助于确定人们在使用产品时存在的问题，暴露出不好用的界面和容易混淆的语言。可用性测试通常作为大型研究系列的一部分，涉及准备和分析工作。但从快速展示产品和经济的角度而言，邀请朋友、同事、家人进行小型可用性测试（以下简称：可用性测试）最合适。这样做，可以用最小预算获得产品的直接反馈。如果你是第一次进行用户研究，还是先给自己一点时间准备一下。可用性测试过程可以分为四个主要步骤：定义受众及其目标；创建达成目标的任务；寻找合适的人选；观察用户执行任务的过程。1. 定义受众及其目标评估总是始于“为什么要有这个东西?”---华盛顿大学 出于某种原因，你正在设计某个产品。你觉得你的想法能让世界上部分人过得更好。也许能帮他们买到更便宜的东西。也许能帮他们获得其他途径得不到的信息，也许能帮他们联系到其他人，也许能让他们感到开心。 不管什么原因，你都在设计自己觉得会给特定人群带来价值的东西。要能获得这些价值，他们必须做点事情。因此，对于可用性测试，首先要搞清楚产品的使用对象。对于你预期的、使用产品最多的用户，如何描述他们？他们和其他人有什么区别？区别在于他们的年龄、兴趣和问题吗？实际可能包含前面所有情况，可能还有更多情况。但这不够具体，年纪大的老人也会购买餐具，但不会从网上购买。所以受众定义范围要稍微广泛一点。目标用户受众如下:接下来，要找出关键产品功能特性，把产品内容写下来。为什么人们要使用它？为什么它对用户有价值？2. 创建达成目标的任务现在把网站五个最重要功能写下来。在购物网站上，人们显然要能买东西。但不管是否准确清楚自己要买什么，他们都应该能买到东西。此外，也许他们还要能发现促销商品和超值商品。列份清单，用一两句话描述一下每个功能。从使用者角度出发，用两三句话描述一下用户使用某项功能的情况，即所谓任务。如果“通过风格找到特定刀叉”属于功能之一，其任务描述如下:最后，根据难易程度，按照从最简单到最困难的顺序排列任务。从执行简单任务入手，人们会对产品和任务过程有好感。3. 寻找合适的人选现在，找一些符合步骤 1 所创建的特征的人。找五六个人，这些人要与你预期对产品有兴趣的人相似，像这样快速运用可用性测试，就可以更充分地认识真实用户使用产品时发生的问题和误解。从身边的人中物色合适人选是最快的方法。如果身处大公司，可以从与产品没有任何关系的部门找些同事。如果是在小公司，可以找朋友、家人以及同事的朋友和家人；可以找在办公室的人；可以找街头的行人。还可以找一些不熟悉产品的人、无论喜欢者或不喜欢，对产品都没有偏见的人，只要这些人和你期望访问网站的人有点相似就行。除非产品专为开发人员而设计，否则就不要找靠开发网站谋生的人，因为他们懂的东西太多。4. 观察人们执行任务的过程首先，写一个剧本（测试任务），受邀的用户会根据剧本进行。例如：用户现在需要通过主数据产品，新建一条主数据编码规则，需要带上审批流程。 你也可以在测试任务上介绍一下产品是做什么的，让所有参与测试的人都知道这是一个什么产品。接下来找一台电脑，一个安静的房间。一般情况下，找个小会议室即可。确保房间里没有任何与产品有关的东西，以免分散用户的注意力。测试前需要告知用户，他们受邀到此，是为了帮助你了解产品哪些地方有用，哪些地方让他们感到困惑。虽然称为测试，但不是要对他们进行测试，而是邀请他们来评估产品，谈谈他们对产品的看法，所以他们怎样做都没有对错。要强调一点：如果不能完成任务，也不是他们的错；如果他们说出对产品的负面看法，也不会伤害到任何人。他们要大声说出所有想法，这一点很重要。建议他们详细叙述在做什么，以及为什么这么做。你会留在同一房间里，一边倾听他们发言，一边做笔记。这个过程不要打扰到用户，要让用户专心执行任务和详细叙述。如果测试过程中他们被问题卡住了，不要告诉他们应该单击哪里或者看什么。不管什么情况，都不要告诉他们应该怎么做。如果他们看上去特别沮丧，就告诉他们有些事情无法完成不是他们的错，请他们执行下一任务即可。如果所有任务都完成了，或者半小时时间已到，就可以请他们停止。请用户向自己谈谈他们的总体印象，他们是否会“在现实生活中”使用该网站。 然后送份礼物谢谢他们为测试所花的时间（吉祥物、小礼品、餐饮券…只要适合受众就行）向他们表示谢意，并送他们离开。最后，重启电脑（恢复初始状态），清除缓存和浏览历史，为下一位用户测试做好准备。三、你学到了什么可用性测试一结束，马上问自己下面几个问题。哪些功能起作用了?有没有用户总是误解的东西? 如果有，是什么?有没有错误总是发生?如果有，是什么错误?他们有没有按照你期望的方式执行任务？如果没有,他们又是怎么做的?他们执行的顺序是否与你期望的一样？如果不一样，又是什么顺序？你期望他们会发现有趣（创意点）的东西，但事与愿违，他们并不觉得有趣。他们完成了多少任务？哪些任务困难最大？他们在什么时候感到受挫？当时他们在做什么？产品符合用户的期望吗？如果没有，哪些地方让他们感到失望？到这里，你应该知道产品哪些地方存在问题。你可能看到有几件事情一而再，再而三地发生。也许用户并不理解你为某项功能指定的名称。也许他们没看到关键功能。也许他们对所提供的功能不感兴趣。也许，他们喜欢这个产品，它能满足他们想要的一切。知道所有这些情况是好事，因为能揭示问题出在哪里，而且同样重要的是能说明哪些地方没有问题。四、实操案例这里的案例是一个面向制造业的产品，解决制造业多系统中数据的统一、维护、共享。1. 定义受众产品面向的受众人群主要是业务与技术人员，对数据库等知识有一定的了解。2. 设定典型任务任务：现在需要通过主数据产品，新建一条主数据编码规则，需要带上审批流程。3. 寻找合适人选Nielsen 提出的一个法则：有 5 人参加的用户可用性测试，即可发现 85% 的产品可用性问题，而且通常最严重的问题都是前几名用户发现的，随着用户数量的增多， 发现的问题逐渐减少，被发现问题的数量与测试用户数量的关系如下图所示。这次测试参与人员共 6 人，普通用户 3 名，技术人员 1 名，产品经理 1 名，项目经理 1 名，都是公司内部人员。4. 观察执行任务过程从执行任务可以发现，普通用户问题是最多的，但这个产品定位是技术人员，所以我们可以先不关注普通用户诉求，后面三类用户虽然都懂技术，还是存在很多使用上的问题。原型如下：5. 根据反馈进行优化例如：第一条不知道新建规则流程，设计的人会认为大家和他一样会使用，其它并不是，上面的产品经理不负责这个产品，所以他也不知道怎么使用，这也是 b 端产品的特点，c 端玩玩就会了，但 b 端你不懂业务就真的无从下手。 基于这一点我们可以给一个功能引导页面，如下：剩下问题的这里就不举例了，只想说明用户分析很重要。谢谢大家观看！本篇来源：优设网原文地址：https://www.uisdc.com/usability-testing-2
测试 用户 可用性 前言这篇文章针对车载行业的可用性测试，我们做一下深入探讨，前面几篇跟下来的读者也都知道我写作的节奏，前面会深入讲解该主题的基础内容，并结合一些我工作中实际案例给予大家去了解，后半部分以实践案例为主，将前面基础知识融入进来，结合案例进行剖析可用性测试，这次文章大纲分为三大内容：可用性基础知识、HMI可用性测试实际工作内容、HMI可用性测试评估维度体系，最后一点是重头戏。往期回顾：万字长文！车载 HMI 语音设计基础知识科普前沿：开头必须来一句，我相信语音一定是未来，我非常确认这篇 HMI 的语言探索以介绍语音交互内容为基础，结合我的实际工作项目经验，输出总结关于语音设计的内容，最后结合案例，在对话设计中会进行深度的探索，并提出个人的想法和思路，因为有的时候深度去思考觉得我们项目还可以有阅读文章 > 万字干货！超全面的HMI 竞品分析手册他来了～ 他来了～ 一个月时间的打磨，不知道熬了多少次通宵了前沿：为了输出这篇竞品分析文章，我也是够拼了，利用周末的休假时间，预约这四家 4S 店进行试驾，并进行对车辆的拍照，和销售对话的录音等获取到一手资料，再去做分析、总结这一次的探索。阅读文章 > 我们在文章前夕先谈谈可用性测试与用户访谈，可能后期也会针对 #HMI 用户访谈# 这块内容会再输出一篇文章。可用性测试和用户访谈的区别 可用性测试更偏向于观察用户的操作行为，而用户访谈是更好的挖掘用户的需求。可用性测试是为了找出产品的问题而测试，通过这种测试找出产品中存在的问题，加以解决，最后目的也是为了让产品用起来体验更加。大家也发现了，关于 HMI 设计类文章很多平台上很少有，还有设计师工作中用到的设计方法论，如何运用到 HMI 车载领域当中，确实都很难找到，并且专业领域的内容车厂也不愿意拿出来分享，我一开始写文章的初衷就是想打破这个格局，虽然一个人力量很小，但我还是坚持做下去了，希望通过我的分享能够让更多的人能进入这个赛道，并且也能输出自己的经验传递下去，成为光，并散发光。进入我们今天的正题吧。可用性基础知识ISO9241 中对“可用性”的定义是：特定用户在特定的使用场景中，为了达到特定目标而使用某产品时，所感受到的有效性、效率和满意度。1. 可用性原则有效性（Effectiveness）：用户完成特定任务的情况。比如：设定一个调节空调风量的任务，让用户操作，记录员在旁边记录用户的一个完成度的情况，成功完成、求助后完成、未完成的状态。效率性（Efficiency）：用户完成特定目标的效率，任务完成时间和完成的一个路径。在记录过程中如果在一个正常时间范围内无需关注，主要还是要记录在某些功能上面花费较多时间完成的任务。在操作路径上也要观察，是否符合我们设定的操作路线，是否存在偏差或者是犹豫不决的地方。满意度（Satisfaction）：用户使用该车机系统主观满意度，当然我们也要提前做好一些标准，比如任务完成的难易度进行评价，任务完成的满意度测评等，总结一下一个好的可用性必须能够满足这三个维度，这三个维度也会有一个重要程度之分，有效性 > 效率 > 满意度。需要最后补充一下：在评估一个任务可用性以外，还要需要注意该功能的价值，尤其是 OTA 升级发布新的功能，功能价值分为两类：用户价值和商业价值，作为设计师的我，觉得用户的体验应该是放在第一位的，有了好的体验才能够更好的去谈商业价值，不然就是在扯蛋。例如 我们在优化负一屏中的体验，将调节音量新增了可以调节四种音量大小，多媒体、电话、导航、语音，旧版本的音量调节，用户经常会吐槽，因为当时功能设定负一屏音量调节是整个的一个系统调节，你在音乐调节很大音量的时候，如果有一个电话接入进来，对方说话声音就很大，会吓到用户，这个在驾驶过程中会很危险的，因此在OTA升级后，我们做了优化。2. 可用性测试类型其实可用性测试方法和类型很多，会在不同情况下使用，选取的方式也是需要看团队设定的目标、在什么阶段、最终的预算能有多少钱，真的，没钱很难办事情。探索性测试：产品在不同阶段，可根据不同的测试类型做可用性测试，在产品初期可使用探索性测试方法，利用产品的原型图展示给用户，探索性的测试目的是，用户是否对这款产品有所了解，如果在某些方面有所疑惑需要记录，根据多组测试，重叠性较高的功能就需要 UX 去优化，在产品初期需要不断的试错。比较性测试我们先说一下比较性测试，我们在做设计时会出几个不同的方案，需要在这个几个方案中做出选择，如果公司非常重视测试数据的话，会将设计方案同时上机进行路测，最终结合数据，让体验专家评判方案之间的优缺点，最终决策出符合用户体验的方案；另外一种比较是选择两种或者更多的产品，去研究他们优缺点，确定哪个设计方案能够提供给用户带来良好的操作体验；这两种方案取决于项目的时间长短，如果像服务形的乙方需要快速的出方案，则更多的采用的是第二种，甲方有着自己设计研究部门可以给到部门有试错的时间成本，那么他们更会倾向于两者相结合的方案，我们只能提供可行性的方案，最终还是需要领导层进行拍板实施。评估性测试当产品进入后半段，在发布版本前后，上机进行测试，HMI 上机测试分为在室内台架上测试，另外一种是装机在道路上测试，不同场景的路测，在这个阶段的可用的测试方法是评估性测试。评估性的可用性测试目的是确保这个产品在发布之前将潜在的问题进行修复；在版本发布之后本公司或者一些测评机构会根据自己的评测标准进行对这款产品进行评估测试，对照自己的评判标准进行打分，方便后续 OTA 升级，版本优化迭代功能。3. 可用性测试方法相信大家对于定性和定量这两个词并不陌生，在可用性测试中承担着重要的组成部分。定性 / 定量研究定性研究是指参与本次车载系统的体验者对于可用性的一个直接评估，从而产生结果，并且发现哪些功能在操纵的时候会出问题，有哪些体验是觉得不错的，哪些功能的体验需要进行优化，听完这些内容是不是觉得和车载系统的专业测评人差不多了吧，当然，在做这个定性测试的时候需要找不同的人群进行测试，需要做到完整性。定量研究也是我们常用到的一个测试方法，定量研究出的数据对于可用性启到了间接评估，通过参与本次车载系统体验的用户，观察他们在操作事先列举好任务上的表现状况，这些状况包含了本次任务完成消耗的时间、完成的成功率、错误点击等；定量研究的结果是一些简单的数据，这些数据需要有一个参考的依据，一个已知的标准，要么就是竞品体验的一个对比数据，还有一个是自己车载系统前后版本的一个对比看看改进多少（专业术语：ROI），一个词需要找到 “参照物” 。例如：在多少秒内操作是一个安全的范围值？单次交互操作动作不能超过 2 秒（1 秒内为最佳）如果一个在行驶过程中需要交互操作的动作 用时 2-3 秒就已经是一个危险状况，所以我们参考这个依据，可以进行对我们车载系统做一个判定。定量的数据是有了，参考标准也有了，有的功能方案是不 OK 的需要去优化，但是这些数据没有告诉我们如何去优化它，需要在设计方案中何如去优化？定量分析研究只是记录了一个过程中得到的数据，也没办法得到用户在什么项目中遇到什么困难，比如车辆设置中的调节 ADAS 的某一个设置选项，用户不知道在哪里寻找，我们只能记录这项任务失败。所以在为了更好的做可用性测试，我们通常会使用定性研究来增加进行补充缺失的部分。如何运用定性和定量研究前面有提到他们之间的区别，那我们在日常的工作中该如何的运用呢？在什么阶段用什么研究？在发布车载系统 1.0 版本和后续迭代版本优化 1.x 版本，可以使用定量、定性、两者组合性来评估，如果这次评估的目的是数据方面，在这个功能点上我们优化多少，提升了多少用户使用了这个功能，那么就需要采用定量分析，因为只有定量研究才能得出每一个版本对比上一个版本到底优化了、提高了多少。需要针对车载系统重新设计内容时候，要通过定性的研究方法去完成，在这个过程中用户的角色是承担为设计提供可行性方案的人，他会觉得在哪方面可以进行优化，到得这些用户数据和意见之后，也便于设计师们做出选择性的优化，创建出一个新的体验感，所以这个阶段使用定性研究方式更为适合。举个例子：用户在体验过程觉得在操作调节音量的交互感觉不好，抓住关键词“调节音量体验不好”，那么就要询问清楚，问到用户：“是在下拉出现的负一屏中 调节体验感觉不好，还是在进入设置项中的去调节音量体验感觉不好呢？因为在做定性的研究的时候不会设定怎么进入，因此会出现通过多种方式去操作系统某一个功能，所以需要针对这个问题询问清楚，才可以正确的优化这个体验流程。后面还需要跟进这个问题，是操作步骤过多，需要优化路径？还是在滑动的体验感需要加强？等这类问题，当然也可以让体验者去叙述他自己的点。如果同样的去发现这类的问题，你去使用定量那么会增加很多工作成本不说，预算成本也会增加。可用性测试实际工作内容由于我们项目的保密性，不能透露过多内容，我将这次案例换成了其余车载系统，这次可用性测试的目的是系统评分数据1. 设计任务前面提到定量研究测试，是请多名用户来参与对我们车载系统的一个体验，我们将原先设定好的任务对用户进行说明，然后我们在车内观察用户使用我们产品的一个状况。可用性的评估是基于任务的，所以接下来我们讲一下任务的五个原则：锁定主要任务、明确任务起点与目标、给任务设置约束条件、任务不应过于简单、避免提供线索和描述操作步骤主要任务用户在使用车载系统目的有很多种类，需要听音乐、电台、看视频、导航到目的地、接/打电话、调节空调/温度等等，可能会有上百个功能点需要去操作，但一场测试不可能全功能进行测试，我们只有挑选出最重要的任务来进行测试，或者是刚上线的车载系统，需要测试一下基础功能评测，如果遇到产品 OTA 升级或者是改动很大的版本点，会改变用户的操作步骤，更或者是新增加的功能，都可以优先测试。再举个例子：任务：调节空调的温度我们需要观察的是，他是如何调节空调温度的（我们设计师自己肯定知道全部的调节方案）第一种方案：可以点击导航栏下方的温度，点击可以进行前后拖动来改变温度第二种方案：按下方按键，呼出语音 “温度调节到 21 度”明确任务起点与目标在可用性测试中最重要的就是用户能否可以完成任务项，所以需要明确目标，如果没有的话，就无法判断用户是否完成任务，我们最初设定一个目标。例如 “在音乐界面中将播放模式调成单曲循环模式”这是我们这个任务的最终目标，只要最终用户在音乐界面中将播放模式改为“单曲循环”即为此项任务成功完成。给任务设置约束条件在设定任务的时候，会出现可以多种方式去完成，上诉案例空调调节温度，就可以使用两种方法去完成，因此如果本次全程操作不允许用语音操作（这是作为一个约束的条件）本次的全部测试项目是关于在中控测试评估的，语音会有他自己的一套测试任务，这些都需要在任务开始前设定好的。任务不应过于简单如果你想测试用户是否找到这个功能，请不要用“找到一个 xxx 暂停按钮”，我们需要给用户提供一个处理现实场景中的任务，而不只是去找这个按钮的位置，例如：“找到音乐暂停按钮” 改为“在酷我音乐界面暂停一首歌曲”这样会有一个明确的场景，这个场景是可以运用到现实驾驶中出现的任务，如果变成“找到音乐暂停按钮”就属于一个不 OK 的任务。避免提供线索和描述操作步骤设计任务的时候应该给出具体的目标，而不是列举好的整个操作步骤去教用户去完成，这个跟说明书没两样。例如：“购买酷我音乐的季度会员”。进入酷我音乐界面、点击酷我音乐中我的、然后点击会员中心、再点击续费、出现弹框选择季度充值、最后扫码付款。用户在接受到这些信息后，就知道先进入音乐应用、找我的、寻找充值入口、最后再进行支付。引导性过强的话会失去任务测试的意义，这样做会错失用户在操作过程中发现的一些问题，观察员也将错失记录的机会，如果没有这提前事先布置好的步骤，可能会出现一些操作让他感觉有异议，不知道自己是否操作成功或者是是不是点错了等等状况。在用户使用产品的时候，我们应该考虑使用的目标，不是考虑具体的操作步骤。我们在设计任务的时候一定要避免提供线索和描述操作步骤给到体验者。总结一下针对用户来看的话，车载系统对他们只是一个工具，达到他们想要的操作目的“比如听音乐、导航”这些功能目的，所以在可用性测试中，我们需要把测试车载系统某个功能目的作为重点。2. 招募人选在招募人选问题之前，需要根据这次测试的目的和需求，确认是定性研究还是定量研究或者是组合性的研究测试方式，这次的目的是对于新系统的一个评分，这次研究方向确定好是做定量研究测试。定量研究可用性测试是基于（30+以上人 体验者），但也有时候定量研究也会少于 30 人，因为预算的问题，或者其他的原因无法请到这么多人，因为招募车载系统的一个体验用户，相对于招募去体验 APP、网页端产品、还是 B 端的产品，都会难很多，因为条件的限制，所处的环境也变化了，因为是有驾驶的一个状态，还需要去操作提前布置的任务，所以在招聘人员的时候确实相对其他平台要难。数据就会存在一些偏差。定量研究通过任务的完成率、完成时间、满意度进行评分。这些总结性的评估数据，通常都是用于车载系统的迭代过程的跟踪，在下一个版本中数据是否得到提高，从而达到优化的目的。另外给大家补充一下定性研究人员选择定性研究用户可以 5 人参加这场测试，就可以发现大多数（85%）的产品可用性问题，随着用户的增加，会发现的问题会逐渐减少，因此最终定性研究分析选定的人数需要我们去考量。在后面的实际案例中，我们采用的是定量研究，会针对整个定量研究全案做一个详细的解说，也会增加一些定性的来作为补充说明。总结一下：我们要根据实际情况来确定我们招募的用户数量，对比每一次的测试结果于后续 OTA 升级后的效果，是否需要增加投入的预算来做可用性测试。3. 准备工作在做可用性测试之前需要规划好准备的工作事宜，先是测试地点和工具的准备，后续是相关资料的准备，后面需要签署保密协议，最后就是整个的可用性测试剧本准备。测试地点和环境HMI 车载系统测试场景相对于其他端的测试场景要多，这些不同测试地点和环境主要目的就是针对影响用户操作的因素来做多方考量。车载系统测试的地点：路测（大马路上，封闭路段、正常道路）、地下车库、路面停车场、隧道等车载系统测试的环境：晴天、雨天、阴天、下雪天、雾霾、沙尘暴等对于硬件的测试还会增加在不同温度/湿度下的测试：极寒地区、干旱地区、常年潮湿雨水多地区等等（这类测试跟设计关系不大，想普及一下）准备的工具 需要在测试车内装机好需要测试的系统；安装眼动仪来记录用户的观看轨迹，便于后续优化界面设计和交互设计；还需要后排记录人员跟拍操作录像资料，便于后期的分析操作细节。相关资料首先就是准备整套测试中的任务卡片，便于用户查看；还有要为自己准备一张表格，记录用户操作中出现状态的数据，如任务是否完成、完成时间等状态；还有一些记录关键事件和测试中观察用户体验的表格，比如设计中可能会出现的问题，方便结束后进行总结，加入到后面迭代版本点中。签署协议在测试期间需要签署保密协议等，因为用户测试的是未上线的产品，为了确保项目安全起见，需要让参与测试的用户签署保密协议。剧本准备HMI 可用性的剧本准备和其他基本类似没有过多的出入，这个过程是：接触用户 开场白 开始测试 事后访谈 给予奖励并送走用户的整个过程，这些相同的剧本准备、还紧跟后面的观察、访谈这些内容，大家都可以自行搜索，因为下面还有更重要的内容需要细讲。最后一步就是分析前面所得的数据，但需要一个标准去评估衡量，下面进入我们本篇文章最核心的部分吧。HMI 可用性测试评估维度体系对于 HMI 车机系统可用性测评有很多的标准，我们对 Thoughtworks 的度量标准进行了分析学习，根据前面的可用性测试原则，最终得出评估的三个维度：视觉行为表现（Visual Behaviors）、HMI 软件任务表现（HMI Task Performance）、主观感受（Subjective Feelings），这测试的体系主要针对的是动态测试下的 HMI 车机系统可用性测试的标准，静态测试（注：静止状态下、车辆未启动状态下的操作）任务还会有另外一套测量体系的标准。1. 视觉行为表现（Visual Behaviors）视觉行为表现的二级维度是视线离开路面的时间，因为这个维度是针对完成任务是否是在安全时间内的一个评估标准，这一项是至关重要的，HMI系统在设计方面一定要遵循安全的设计原则。评估它的指标是用户在车机单次扫视时长，车机总扫视时长，为什么会增加这一个评估指标呢，因为有些任务不是单次扫视就能完成操作的，比如在中控上面调节音量大小，我们项目中有一个定义是在绝大数页面当中，在空白区域左右滑动就可以改变音量的大小，所以这项任务测试数据中交互手势是表现相对较好的。当然还有其他方式第一步：下拉交互手势，将负一屏滑动下来；第二步：找到调节音量大小的滑块进行调整音量大小。这个交互方式和其余的车载系统是基本相似的，所以在整体考量方面，在中控调节音量大小是一个比较危险的操作，因为总时长较长，甚至单次扫视的时间也有过长的一个情况。2. HMI 软件任务表现（HMI Task Performance）HMI 软件任务表现的二级维度是有效性和效率，这方面测试用户的一个任务完成度情况。有效性的评估指标是任务的完成率和人均错误次数 ，这两个数据是指测试的任务是否成功完成了，在操作这个任务的时候用户犯了几次错误最终才完成的任务。设定一个任务：完成“搜索找周围加油站”，操作状态：静止状态下（非驾驶状态），操作限制：中控屏幕内操作。通过这些条件得到不同的数据。类似这种任务，我们可以做多种不做任何限制状况。得出的结论是：语音操控下最优，完成率和人均错误次数较低，错误的就是有些地方的方言无法识别，其余都可以正常完成；在中控屏幕中操作，只有在非驾驶中可以完成任务，在中控屏幕操作中需要很多步骤，1.首先进入导航页面，2.进入导航页面后，有不同的操作路径可以进行搜索加油站，第一个直接在输入框中搜索加油站，第二个就是在下方有加油站的 icon，可以直接查找，在第一次使用我们产品的用户，绝大多数都是进行第一种方案。最后数据比较非驾驶中完成任务率和人均错误次数远低于驾驶状态，因为驾驶状态下完成这类任务时间会增多，并且驾驶中不可能长时间定于屏幕。其实现实场景中，在驾驶中搜索加油站的场景会偏少，所以更推荐用户多运用语言进行搜索完成任务，如果不习惯语言交互，那么请在非驾驶状态下进行操作中控屏幕。效率的评估指标是完成时长 ，通过上面的案例我们也可以直观的看出语音交互搜索加油站完成的时长是最短的，因此他在效率上也是最高的，语音交互也分为驾驶状态和非驾驶状态，效率也是不一样的，非驾驶状态效率要高于驾驶状态，因为驾驶状态下去扫描屏幕信息难度要高于非驾驶状态下的。其次就是静止状态下的操作中控屏幕效率也要高于驾驶状态下操作。排个序不同场景在不同的交互方式，非驾驶状态语音交互 > 驾驶状态语音交互> 非驾驶状态中控操作 > 驾驶状态中控操作。3. 主观感受（Subjective Feelings）主观感受的二级维度是综合感知负荷 ，事物通过感官在人脑中的直接反应，感官这一个词大家也许会感觉还是有些陌生，HMI 车载系统交互中从视觉、听觉、嗅觉、触觉以及味觉等方面的感官交互，也就是通过眼睛、耳朵、鼻子、嘴巴以及皮肤触摸实现，围绕这些感官进行设计的，这些对用户直观的感受都需要记录下来，作为对于后续优化系统作为研究内容。综合感知负荷的评估指标是感知脑力负荷，这个词想必大家也没咋听说过，我简单介绍一下，从任务和个体两方面出发，脑力负荷中的任务和执行任务的个体均相关。在同一任务中，不同的用户所感受到的脑力负荷仍可能不同，用户自身的情绪、动机、策略及个人能力都可能影响到脑力负荷。从信息处理能力的角度出发，将脑力负荷定义为: 用户在执行某项任务时对所应用的“信息处理能力”的大小，可以通过测量其“信息处理能力”来直接度量其脑力负荷的大小。一共有两个因素来决定，一个方面是“时间占有率”，时间占有率是指完成某项车载任务过程中用户的最低处理时间。“时间占有率”越低，则脑力负荷越低，“时间占有率”越高，则脑力负荷越高；另一个方面是“信息处理强度”，信息处理强度是指在单位时间内需要处理的信息量或者处理信息的复杂程度，“信息处理强度”越高，则脑力负荷越高，反之则相反，有点难理解的话还是多看几遍吧。脑力负荷的测评方法主要包括: 主观测评方法、作业绩效测评方法、生理测评方法以及综合测评方法，关于这些维度的后续我们在详细探讨。4. 给大家开一个小灶本想这个留着后面慢慢讲的，但是已经谈到这个专业领域的知识，我又没收住，就简单的给大家提一嘴，后期还会单独针对这一块做深入的探讨。上面谈到脑力负荷，那我们设计 HMI 车载系统的时候，该如何降低脑力负荷呢？从视觉、认知、操作三个角度出发减少脑力负荷视觉：是指 HMI 车载系统的界面信息视觉复杂程度，减少视觉负荷，需要做到信息功能更加精炼、主次分明等要求。根据调查：人对产品的第一印象是在 0.5s 秒形成的，有一点要知道：为了降低视觉负担，不是设计的很简单就完事了，驾车环境和其他产品不一样，对于视觉要求较高，因为用户每盯屏幕多 1s 钟，就会多一分危险，所以在设计的时候不能将其他端的设计照搬硬套，减少用户阅读的信息，简化信息内容等。认知：是指用户对于 HMI 系统界面的理解、思考的脑力消耗，交互设计中有一条原则：不要让用户做过多的思考，不要增加用户的认知负荷。在设计 HMI 车载系统的时候，视觉设计和交互设计要保持全局的一致性，HMI 车载系统的设计和其他端也不一样，APP 端要将这个行业的框架结构要一样，所以大家看到淘宝、京东、网易严选、苏宁易购等购物平台 APP 首页的框架都是一样的，从而降低用户认知成本，这个是行业的一致性。但是大家可以看到车载系统，每家的定义都有差异化、也有相同点。比如小鹏、蔚来、特斯拉都是以导航为首页，理想 ONE、五菱星辰首页的设计方式是以卡片为主，所以在于车载系统中的一致性是在自己本产品中体现，视觉、交互的一致性，不能做过多、过于复杂的交互方式。视觉的一致性就体现在的通用颜色，比如导航模块中的交通拥堵的颜色，深红色为极度拥堵路段、红色代表堵车、黄色代表缓行路段、绿色代表畅通路段，这个只能在一个颜色系列下微调，不能做大幅度改动，但这个还需要按照每一个国家的定义来，有一些国家对于颜色定义有着自己的要求，所以在做海外导航的小伙伴们要时刻注意下。操作：是指用户移动头部、手臂、手指来点击触碰 HMI 车载系统，如何做到减少操作负荷。下面从软件层面和硬件层面来讲讲：针对软件方面的优化：交互内容面积越大越容易操作；交互的内容应该偏向于主驾驶便于操作的区域，距离主驾驶越近越好；与其他交互手势、方向避免冲突；点击的交互方式易用性强于长按和双击，但车载系统有的地方还是需要用到这些其他交互方式，全局做到尽量少用，放大地图之类也需要延续双指交互手势等；单指交互优于多指交互。针对硬件方面的优化：对于硬件操作的优化，沃尔沃汽车将主驾驶屏幕做了倾斜，对于主驾驶是方便操作，唯一的缺点就是不可以挪动，他是完全镶嵌进去的，如果副驾驶需要链接手机蓝牙到车上面，对于副驾驶的观感就不太友好了。这一点新款的特斯拉 S/X 系列做的很到位，他可以将屏幕左右的倾斜，在设置项中可以选择屏幕的调整，针对操作这一点优化相当不错的，我在其他平台看到有的车主在特斯拉 model 3 改装了屏幕，将固定的屏幕改装成左右上下都可以移动的屏幕，动手能力超强，给车主点个赞。总结本篇文章是HMI车载领域的可用性测试，但其他领域的设计师们也可以有学习的内容。本篇来源：优设网原文地址：https://www.uisdc.com/hmi-usability-testing-buff
测试 可用性 用户 设计师面试被提问可用性测试？挺意外的，就着机会结合个人的一点小心得，聊点不一样的“可用性测试”技巧。可用性测试的应用场景与作用可用性测试(Usability Test)的应用场景是没有行业的明确界定的，它一般发生在产品研发上线的前中期，在功能或交互流程有待商榷之时，通过可用性测试可以获得更加真实的反馈来帮助决策或改进。当然已上线的产品，同样可以使用可用性测试为下个版本优化迭代做投资。其中探索式跟验证式是常见的两个可用性测试类型，探索式适合企业对产品进行创新设计以迎合新时代发展的步伐与商业竞争力，验证式适合企业追求精益运营或增长设计。对于可用性测试的概念，这里我用一段类比的情景来揭示出其中奥妙。做好一个饭馆，而菜品必定是馆子的核心竞争力之一，菜不好吃，那就很难形成竞争力或留住客人，所以开发新的菜品或改进就很重要。当厨师开发了新的菜品后，首先肯定是厨师们互相品尝，并不会直接上菜谱开售，这就像是内测过程，当厨师们觉得还可以时，就会找食客们进行免费试吃，通常这个时候厨师们需要食客们给出反馈或一定意见，如果食客们大多表示这个菜不错，下次还愿意吃，那么就是表示这个新菜品的可行性很高，用户满意度不错，就可以考虑对菜品优化上菜谱了。而这个过程就像可用性测试一样，它为新菜品上菜谱降低了风险，为菜品对菜馆整体体验提升了保障，其中“菜馆的食客”就像是测试的目标用户，请求他们尝试新的菜品并给出意见，这便是招募用户和测试阶段，询问食客是否还会再点这个菜品，觉得这个菜品在什么价位区间，就算是对用户满意度或可行性衡量了。相比专业可用性测试，只是少了更多的测试流程、测试技巧与科学严谨的分析汇报，但是基本概念是一致的。但值得注意的是针对单个菜品的研究并不是面向整个菜馆的，可用性测试很少用于研究用户对产品或服务的整体体验。所以可用性测试的本质就很好理解了，以互联网产品为例，其实就是服务数字化后的功能与流程含有不确定性，而决定找到目标用户还原使用场景进行测试验证，以评测设计是否行得通、哪里需要改进，为功能上线减少风险加强容错，减少试错的成本。高保真原型与测试场景还原要测试就得有测试内容，所以测试对象是必不可少的内容，这个过程是我们还原真实用户在特定场景下进行产品体验的一系列问题反馈，那么为了尽可能的还原“真实”，肯定不能只是在用户的真实性上下功夫，接近真实的高保真原型就显得尤为重要，以互联网产品来讲，还原一个可交互的高保真原型并不难，成本也不会很高，可能就是信息内容设计与素材准备会相对麻烦点，对于交互动效，基本可用就行，不必过分追求，并且实现的工具也很丰富，对于大型框架原型可以使用“墨刀、MasterGo、AxureRP”等制作，小型精致的原型可以使用“Principle、Hype3、Flinto、Sketch、Keynote”等制作。反而是工业产品设计的原型会比较麻烦，有的可能要出 3D 打印甚至开发测试样品，尽管这些工作会花费一定的时间与成本，但是从产品稳健发展的战略来看，这些投资是值得的，也是老板们可以接受的。在大多数的可用性测试文章或教程中，用户都是在一个相对降噪的会议室或实验室进行的，其目的是为了更好的布置设备用于过程的观察与记录，同时为用户测试减少干扰与评估难度（其实也省钱），但事实上还原产品服务的真实场景是很有必要的，并且一些产品服务自身就会含有一定的场景属性，所以你的测试环境就应该考虑接近真实场景的布置，甚至考虑跳出会议室、实验室。这样的目的也是为了更加真实的还原使用场景，以取得更严谨科学的有效信息来赋能设计，这也是为什么大多数产品需要上前线测试的原因，就像药品诞生于实验室，上架于临床一样，例如出行、运动相关产品，如果依旧停留在写字楼里测试实验，那就是闭门造车。任务与指标定制化设计产品的本质是为用户提供服务，用户会为了达成自己的某个目标或需求而花费时间使用产品，而我们需要用户测试一系列功能来评测是否能够协助完成目标任务，所以我们在设定不同任务的时候应该以某个用户需求或目标为导向来驱动用户使用产品功能，而不是系统的指出完成那些操作任务，那样没办法深入挖掘真实有效的信息，所以在向用户颁布测试任务的时候，我们应该为用户建立一些任务背景，并且尽可能看起来真实可靠，容易接受和共情，甚至你可以在测试前的暖场环节，根据此次的功能作用推导一些使用场景和需求，并与用户进行简单交涉，看看哪些需求很有可能发生在用户身上，并以此需求目标来调整任务的话术来驱动用户完成测试，值得注意的是如果测试的部分比较明确，那么你的任务目标也应该尽可能的聚焦或明确下来。好了，为了方便理解我要说人话了重点补充：因为在整个测试的过程中，参与测试的用户不止一个，所以在了解用户情况后，可以综合一下共同的特征再去提炼优化任务目标，以保证在多个参与者中维持评估的一致性。并且任务目标应该尽可能的准确有效，我们是要测试新的拍摄识别功能，那我们就应该要求出来，而不是说看完书后使用 APP 的笔记并尝试各种功能支持，产品或功能所没有的就不要提。不保证有效性，最后也只能让用户感到困惑而已。通常完成测试任务的过程中，会涉及到多个功能之间的交互，所以任务目标涉及的多个阶段应该贴合实际的操作顺序或流程规范，另外尽可能的避免专业术语的出现，务必考虑“适老化”一下。关于指标定制化通常在可用性测试中，是否可用的指标被划分成了三大面：1.有效性、2.任务效率、3.满意度，对于这三方面我们可以继续细化成若干个二级指标用于界定产品可用性，至于你家的产品是什么行业、什么阶段、什么用途、有何特性，应该满足哪些指标为可用，我就不深入了，相信大家心里都有数。简言之核心就是考虑产品的特性与阶段，灵活的配置可用性的指标，这里整理了些常见的指标与说明用于参考；用户测试中常见的问题尽管我们有测试脚本甚至测试排练，已经尽可能的保障了可用性测试的稳定可靠，但实际上在用户测试的阶段还是会出现各种问题，用户像一个熟睡的婴儿，何时醒来何时哭泣不可预见，所以这就要求测试的主持人能够灵活变通，同时在技巧上符合可用性测试的科学严谨。在可用性测试过程中的科学严谨一方面体现在方案的合理性、测试主持的技巧上、及评估分析量化的方法上，这些大多可用性测试的文章或教程中都会提到，这里就不展开啰嗦了常见问题举例：1. 他似乎在想些什么但是没有说出来？你在想什么可以分享一下吗？2. 用户好像卡住了或遇到 bug 了这没事儿，是我们产品设计的问题，你可以考虑跳过这一步好了3. 就是这个，它怎么就那啥了？表述不清你刚刚打算做些什么，如果是你，你准备怎么去设计？有没有一些参考4. 然后我要怎么做呢？对于用户提问说明遇到了障碍，尝试反问你平时会怎么做？5. 用户反馈了一些趋势或点子，看起来很有价值尝试深挖，顺着点子或趋势向用户多问一点，但是不要直接问“为什么”，可以尝试问好在哪里或者哪里不好，让问题更有头绪一点以上不难看出，即使有了脚本，但是用户依旧是一个变量因素，所以脚本依旧需要不断调整，也只有去调整才能更好的保障测试结果的有效性，同时主持者也需要随时准备灵活的应对各种幺蛾子。创新与颠覆性设计如何测试可用性测试被很多人视为评估体验的制胜法宝，但实际上很多产品在行业中已经逐步成熟，并有大企业花费大量资源进行研究摸索，让生态系统更进一步，所以说要是你的产品没有特殊的创新或瓶颈，而是传统的功能研发，其实并不一定要花费成本去做可用性测试，直接按照行业标杆也是没问题的。那么你的产品就是有创新或颠覆性设计怎么办？通常这个时候就会面临一个问题，打破传统或者颠覆用户的常识。类似这种颠覆式或创新技术其实非常多，例如按键手机一下到了触屏时代、智能驾驶、语言助手的诞生、刷脸支付等，这对企业是机会也是风险，所以在进行可用性测试的时候也会有些不大一样的地方。我们悉知在可用性测试的三大指标中就有一项是“效率”，对此也会有一些完成任务的时间作为指标，这些指标通常是根据内部人士或专家完成任务的时间乘上 2 倍或者更多倍作为一个评测指标。但是对于颠覆性的变化，我们需要给用户首次测试留出更多的时间去学习去适应，在此之后，可以让用户再进行 1～2 次的测试，并且比较多次任务完成的时间变化，如果时间能够大幅度缩减且完成任务，那就表示可用，而这样做也是为了保障测试的科学严谨性，以避免学习门槛对创新性的评测影响。多版本 Battle 你需要小型可用性测试可用性测试需要招募用户进行测试，预算时间精力可谓一项都不能少，但是大多公司的窘境却是公司小资源又有限，又不给预算招募，可用性测试做不起来？内部产出版本过多，不知何去何从？别担心，小型可用性测试了解一下！1. 什么是小型可用性测试(Small Usability Test)？小型可用性测试就是在标准的可用性测试的基础上减少了一些流程与要求，这就像是大公司与小公司之间会有各自的研发流程一样，两者各有千秋，对应公司规模与背景对症下药。在小型可用性测试中，也有脚本、简易的暖场、用户定义、测试目标、测试任务、测试原型、测试参与者、测试观察、思考总结，更多的也是发生在功能上线之前的推敲阶段，它比较适合设计师在自测阶段后的验证以及多版本 Battle，帮助你 Pick 一套更加合适的方案。但是整个过程相对正式可用性测试会更加简单易行，其中价值观念与目的都是一致的，都是以用户价值与用户目标来驱动（使用动机）使用产品，并且观察用户的使用过程以获取有效的反馈来改进或决策。不过呢，脚本会更加简易一些，原型材料也不用那样精细，主要能表达功能作用与信息流程为主，其中测试者更多的是寻求那些关心我们产品或有需求的用户，另外也不会准备那些知情书、协议、录制设备、测试指标啥的，更多的是寻求熟人或哪些有意向的用户快速进行测试并观察，这样不仅时间成本都节省了，难度降低了，也能拿到一定的有效测评结果。基本上主要的实践步骤就这五点，还有一些布置会穿插在其中，后面代入案例讲解一下。2. 案例代入讲解便于直观的了解和感受小型可用性测试，这里代入一个老案例讲解一下，关于案例背景这里简单交代一下。背景：平台服务于游戏相关的订单交易、互动娱乐，本次测试的内容是新的游戏订单定制服务，通过推出一批专供用户定制游戏服务的客服来完成沟通与定制下单，其价值在于帮助用户快速了解平台游戏服务以及快速定制服务并完成下单转化，以沟通的方式减少用户下单的操作流程与门槛。任务流程：设计服务入口与流量分发->用户选择心仪的小鱼（专供客服的代称）->进入小鱼的会话界面->沟通需求目标->小鱼制定用户专属服务订单->用户支付确认->转到订单流程为了加快讲解和体现测试的价值与方法，这里就不跑全套流程了，就以小鱼入口的设计与流量分发来代入讲解，测试前提是聊天会话界面中已经集成了“小鱼”所受理的主要游戏业务介绍，以及快速下单的入口。当然一般都是在用户向“小鱼”倾述目标需求后，由“小鱼”进行服务定制，并向用户发起订单等待用户确认支付，之后便是等待订单完成到验收评价，平台转交佣金。首先定义用户与目标在这个测试任务开展前一定要知道开展目的是什么，然后就是这个过程中你的功能或产品是为什么样的人服务，能为他们带来什么样的价值，也就是前面一直提到的价值与目标驱动用户的概念。为此你可以建立一个简易的用户原型来定义用户的特征属性，使得目标群体再具体一些。然后将小鱼的服务价值写出来，让参与者能够快速知道小鱼功能有什么用：创建适用于目标的测试任务对于测试任务的创建，应该是围绕目标的。根据流程的多少或复杂程度，可以划分为多个阶段，这样具有阶段性会更好控制测试节奏或分段进行，然后就是将多个任务按照流程顺序或是操作难度排序，目的是使得任务流程正确或是用户接受起来更容易。当你把任务清单罗列出来后还不算完，这套清单你可以放在脚本里，但是当你描述给用户时，你应该代入对方视角去描述并且带有目标性，所以还需要进行一次调整后应用：找到合适的测试参与者关于参与者我们会参考第一步中所设定的用户原型，不需要全部中标，但至少这些人要看起来会用得上你的产品才行，通常这些人建议通过熟人关系去寻找，甚至可以是你的同事，只要他们对产品没有额外的偏见，且不是相关设计者、营销运营者或技术研发人员，因为这些人对该领域的知识掌握甚多，有失真实性。当你找到这五六个接近真实用户的参与者后，你只需要将起初写下的“功能价值阐述”告诉他们，让他们知道要做一个怎样的服务测试，然后预约他们在不同的时间节点上花费半个小时来做一个简单的功能测试即可。观察参与者如何执行任务在这个阶段，你需要保证已经准备好了测试原型，以及一份脚本，脚本中会规范以上的功能价值、测试任务、一些简易的指标、关注要点、暖场介绍、流程顺序等。然后你要找一个相对安静低调的测试场地，不一定是会议室，不用很大空间，一个桌子两个椅子和一些必备的材料即可，但不要有一些产品相关或商业的痕迹，会形成干扰。在测试开始前你需要将测试原型初始化，以确保每个参与者测试的一致性。在暖场和任务布置完成后，就是测试者的 Show Time 了，主持者可以拿好自己的小本本或者录音笔，认真的观察测试者的操作或口述反馈，当测试者遇到一些问题不知所措时，也不用着急指导，告诉测试者先按照自己的认知或想法去做就好，如果测试者在一个地方卡了好几分钟，没有一点头绪甚至感到受挫那就让测试者先跳过障碍，避免整个测试节奏失控。另外记得提醒测试者口述反馈，这很重要。当在计划的时间段完成测试后，就为测试者送上准备的奖品，寒暄几句后送测试者去休息或离开，然后对材料或记录进行简单整理后，准备下一场测试。思考与总结在完成一轮简单的小型可用性测试后，通常一定会拿到一些有用的反馈，可能有些零散还需要进一步的整理，但这不影响最后的分析结果，为了方便验证和整理，我们会提前把一些重要的问题点罗列出来，然后根据测试者的反馈进行记录归档；最终当你完成了这些测试及反馈信息收集以后，产品方案中究竟哪里出了问题应该就了解的差不多了，一些比较明显的问题甚至会被测试者多次提及，或许是页面信息不被理解、交互难懂、提供的内容不受测试者喜爱，亦或是测试者都认可、设计亮点被用户亲睐。尽管会发现一些跟我们预期不大一样的结果，但都是正常的，值得注意的是，我们应该结合这些数据进一步的反思，究竟这些反馈有何含义有何价值，哪里还能优化，基于不用的产品服务或受众，反思点可能会有些不同，这里我泛举一些：最终呢，我们也是通过测试取得一些有效的反馈，并根据反馈深思了更好的设计方案，我们对小鱼卡片的信息进行了丰富以保证可比较性，将每批三个小鱼卡片扩展到了 8 个，用户可以通过横向滑动查看更多，同时为了方便用户更好的换到下一批，在最末尾给予了滑动换批次的交互，使得用户可以一指滑动到底完成查看与换批次的交互衔接，在之后的验证测试中也是获得了测试者的认可与看好。相信说到这里，怎么做好一轮小型可用性测试已经了解了，当你完成了这些测试任务，一定记得不要忘了后续的反思与优化迭代，甚至制定后续的研究计划。多版本方案如何进行可用性测试有时候设计产生多个版本也是在所难免的，那么对于多方案是应该将内部推荐的拿出来测试，还是应该直接两个版本一起拿出来，两个一起会不会因为采集量过少不准确呢？这里我们再说说有多个版本怎么做好测试计划与分配，当有多个版本准备可用性测试时，如何制定测试计划还要看版本数量、版本差异化这两大维度，力争做好有效且不费力。如果说在设计过程中产生的多个版本差异不大，那么都进行测试的必要性我认为不大，通过在商业价值与用户体验间做衡量，选择一个更加符合产品阶段的方案进行可用性测试即可，但是如果多个版本差异较大，难以决策且不确定性较大，那么第一件事就是经过一轮决策将版本减少到两个左右，然后再进行可用性测试，对于此类情况基本上有两种方法进行分配测试；1. 将版本分为两组进行测试；如果说直接分成两组进行可用性测试，那么需要数据样本会更大，数据采集量过少确实会有不准确的可能，因此直接分成俩组进行测试的话，会需要招募更多测试者和测试准备，但同时可能会有意外的惊喜，往往我们以为的，可能会在测试者那里收获意料之外的反馈，这将允许我们以真实用户的视角去挖掘价值或决策，避免内部短视而埋没了好的设计。2. 一组人员测试两个版本；相比分多组测试，一组人员测试两个版本在成本上会更有优势，但同时会面临两个版本测试的前后顺序影响，要知道第一个版本会对用户形成更多印象，甚至产生一些偏好，所以为减小测试结果的偏差，我们会将测试者分为数量相同的两组，并安排两组不同的先后顺序进行测试来打破僵局。测试结果的量化或汇报技巧测试结果量化的目的在于更好的衡量可用性在怎样的一个水准线上，同时便于整理复盘整个测试过程，并将结果更加直观的展现出来，便于同事们了解。对于测试结果量化有两个方面；一方面是将整个测试过程中收集到的各种问题反馈进行分类整理，并用数据图表现出来，这样能够很直观的展现问题缺陷与突破口，同时能够快速体现测试价值，或者说你进行可用性测试为业务带来的价值。另一方面则是通过面向用户的问卷调查获取可用性测试量表，最常见的标配问卷即 ASQ(任务后评估问卷)与 SUS(系统可用性问卷)，除此之外还有专门面向网站产品的 WAMMI(网站分析和测量表)、SUPR-Q(标准通用的百分等级量表，但是获取有效的百分比数据需要购买服务，所以不额外介绍了，有兴趣的自己百度下)，以及面向 APP 使用体验的 SUPR-Qm(APP 用户体验量表)，在说明这些量化表怎么使用和定义前，我需要额外说明一些量化表的概念，这很重要！1. 可用性测试量表标准作为一个合格的标准化量表至少需要保障以下几点：可信度：对同一对象测量得到的结果是否一致，这将直接决定问卷获取的结果是否能可靠，可以通过重复测量信度和[分半信度]测量， 测量出的信度会在 0～1 之间，越是接近 1 的可信度越高，因为量化结果会被直接引用，所以信度至少高于 0.7 才比较有意义，不然一个半信半疑的结果真的充满风险，同时以上我提到 ASQ、SUS、WAMMI、SUPR-Qm 这四个量化问卷也都是经过业内长期试验与验证后信度较高的靠谱问卷模式。「对信度计算有兴趣点这里」：https://baike.baidu.com/item/%E4%BF%A1%E5%BA%A6%E5%88%86%E6%9E%90/9170373?fr=aladdin有效度：主要理念在于是否密切关注到了你所在意的问题点，以及问卷问题是否与验证系统有关联性，对于效度也有效标效度(皮尔逊相关系数) 和内容效度(因子分析) 两种评估方法，不过并不一定要有很高的系数来证明很有效。灵敏度：指达到统计显著性所需的最小样本量，例如一个水果偏好二选一问卷，你问两个人可能是答案 A，但是你问完 10 个人后却是 B，当采量过小没能达到统计显著性所需最小样本量时，可能会获得不够准确的答案。客观性：一份问卷应该保持客观性，不能携带编辑者的个人偏好或主观意愿影响，这会让问卷有失统一性。重复性：尽可能的使问卷框架结构能够复用，一方面便于更多人可以研究验证，另一方面可以使得问卷本身价值最大化。可量化：对于问题的答复最好进行量化处理，而不是单纯的是或否，目的在于可使用高效的统计学方法来理解结果，或进行对比，亦或是数据可视化体现更加精密的差异。所以说开发或调整一套标准可用的度量问卷也是一门富有学问的技术活，并非简单问几个问题这么简单。2. 任务后评估问卷(ASQ)也叫场景后问卷，一般在可用性测试完毕后进行，它可以直观的在任务难度、完成效率和帮助信息上获取到测试者的直接反馈，主要就固定三道题目，答案采用 5 分制或 7 分制，所得分除以总分即可得到一个均分，该分值至少要大于 0.6 才能合格，要获得大部分人满意或认可，则要高于 0.7。3. 系统可用性问卷(SUS)SUS 总共 10 题，奇数项是正面描述题，偶数项是反面描述题，答题采用奇数的 5 分制。SUS 益于它正反向问题结合，以及具有广泛应用的可用性与易用性题型，在业内具有大量应用数据为基础，不论是客观性、灵敏度、可量化还是信度都具有较高的水准，这也是 SUS 能够成为可用性测试后问卷最主流的原因。SUS 量化分数计算：在 SUS 的相关创建者经过对大批数据的研究，其中可用性部分量表信度为 0.91，易学性部分可行度为 0.7，为使得整体量表得分兼容在 0～100 的范围，最终需要对可用性量表总分乘以 3.125，易学性量表总分乘以 12.5。而经过长期的应用迭代，最终分数的计算方式进行了定格：步骤一：所有奇数编号题目得分减一后相加；步骤二：所有偶数编号题目得分由五减去后相加；步骤三：将奇数项最终得分+偶数项最终得分后乘以 2.5 即最终 SUS 得分。分数值概念：在经过创建者的研究与沉淀，最终构成了 5 层不同级别的评级，A 即最优评价，并且对应 0～100 分，有趣的是 5 个评级并非是将 100 分平分，为了解释评级与得分的强关联性，创建者新增了第 11 题进行整体而言的数据收集与分析，最终得到了以下图中所对应的关系，如果说结果是“Good(C)”，那么对应的平均分值则是“71.4”，如果说你的得分高于 85.5 分，那你的评级则处于“Excellent(B)”，这可能已经意味着你的产品优于绝大部分产品了。4. 网站分析和测量表(WAMMI)WAMMI 的建立是为了专门量化网站产品的，该问卷一共 20 道问题，采用 5 分制回答，整体信度高于 0.9，但是吸引力、可控性、效率、帮助性、易学性多个因子测试信度只在 0.63～0.74，因此该问卷对测试样本要求不少于 30 个，若该产品属于学术或专业性较强类型，则样本量不少于 100 个，平均分值为 50 分，总分 100 分，但是也受样本量影响，WAMMI 很难在可用性测试场景后使用，不过它的问题可以在小型可用性测试中进行应用或自检。WAMMI 官网： http://www.wammi.com/index.html5. APP 用户体验量表(SUPR-Qm)作为一个 APP 用户体验量表，涵盖了更多的体验度量面，而不仅仅是衡量了可用性（比如 SUS），并且可以在可用性测试期间或可用性测试之外进行，也可以与其他问题混合使用以便于测量某些特殊产品(如游戏)的用户体验，同时它的信度也高达 0.94，SUPR-Qm 一共 16 道问题，采用传统的 5 分制李克特反应选项。SUPR-Qm 的 16 道题原本来自 23 个其他相关文献中的题目和 4 个开放性的问题，经过不断测试验证和减少冗余后，留下的 16 个具有单维的、可靠的、有效的、兼容强的问题。SUPR-Qm 原博客说明： https://uxpajournal.org/supr-qm-measure-mobile-ux/6. 关于测试结果汇报有些同学一直不清楚可用性测试报告要写些什么，有无固定格式，其实报告没有什么特别的地方，简言之就是将测试的目的、测试过程、测试结果进行整理汇报并反馈优化意见而已，其中大部分内容没有硬性的格式要求，看起来清晰易懂是重点，你可以是文档汇报也可以是 PPT 汇报，另外记得测试汇报讲究真实性，可以把测试过程中的照片或截图等放进去用于佐证。另外就是测试结果的归档，我们通常会借助表格的形式来呈现，这样能够更好的将信息整合，但是考虑报告输出，不是一味的反馈负面问题或解决方案，同样也可以反馈被用户认可的设计，这也是测试的一种价值作用，能够为后续的优化设计提供一定的方向指引与团队信心，所以我们将常见的测试结论归档表进行了一些轻微的调整，补充了反馈的正负趋向，最终呈现如下；关于用户反馈的思考用户反馈本身就是用户在使用产品的过程中遇到了问题，然后通过找客服或反馈入口所给予的反馈，如果一个应用的用户忠诚度不高，即使你在应用内发布问卷收集反馈，用户的参与也会很有限，反而是因为一些问题让用户受阻了才会产生一些宝贵的反馈，而让用户准备和提交截图凭证更是困难，所以这个时候让用户反馈的入口更好找，对问题类型提供细分选项，甚至对截图等动作做出一些预判都是不错的选择。以支付宝的使用场景为例，我们有时候截完图是不是就马上会收到弹窗提示是否遇到什么问题了？这便是对用户反馈的一种重视，如果你确实要准备进行反馈，那么你后续的操作步骤会少很多，使你更容易达成而不会因为繁琐的步骤而产生放弃的念头，并且截图时询问的窗口也是极力克制不会产生过分的干扰。这么说来你是否对用户反馈这个功能有了新的看法，并有了给自家产品优化一下的想法呢？写着写着就又没刹住车，又成了所谓的万字干货了，不管你是从事什么职位，都希望你能够有所收获，即使你脑子里一灵光有了新的想法或不同意见都欢迎来找我交流，最后也感谢那些不厌其烦与我交流的用研大佬们，下次有想法了还来烦你们，哈哈。都看了这么久了，点个赞吧～如何做好可用性测试？来看高手的经验总结！什么是用户研究?用户研究听起来是个非常大的学科和话题，没有具象的描述和切实的研究方法就显得虚无缥缈，让人有种雾里看花的感觉。阅读文章 > 本篇来源：优设网原文地址：https://www.uisdc.com/usability-testing-buff
可用性 测试 用户 什么是用户研究?用户研究听起来是个非常大的学科和话题，没有具象的描述和切实的研究方法就显得虚无缥缈，让人有种雾里看花的感觉。用户研究和用户体验一样，在国外市场得到验证、认可并被不同行业的企业所接受，而国内市场处于萌芽阶段，只有部分行业的头部企业对其有较为清晰的认知和应用。那么怎么定义用户研究？首先，用户研究的目的是了解用户，对用户有更清晰、具象的画像，是一系列研究方法的概括型的名称。聚焦互联网行业，什么岗位的同学最需要关注和学习用户研究方法？与用户、数据打交道的岗位需要对相关用研方法和分析方法有不同程度了解和应用能力，例如，用户研究员、市场研究员、数据分析师、产品经理、体验设计师、交互设计师等等。作为体验设计师或交互设计师，可以通过研究方法对用户目标、需求和能力的系统研究，用于指导设计、产品结构或者工具的优化，提升用户工作和生活体验。怎么做用户研究?研究中包含的用研方法有很多，可以根据实际场景和资源选择适合的方法，目前常用的实用性、可操作性比较强的四大方法：可用性测试、网站访客（埋点数据）、用户调查、A/B Test。在设计过程中的每个阶段，用户研究是都需要做的工作，但很多时候由于工期较短，deadline 在前，设计师在产品设计初期没有办法做到较为完善的用户研究，那么这部分工作就会被延后，在验证阶段研究任务就会变得比较重，后期的优化对此依赖性也比较强。可用性测试是设计师在验证阶段相对比较能贴近用户的用研方式，在测试过程中通过观察用户行为，从即时的反馈中更容易获得贴近真实的定性数据，用对话沟通的方式深度挖掘用户遇到的问题，从而锁定优化重点。超强干货！这里有7个腾讯最常用的用户研究方法编者按：问卷法、可用性测试、眼动测试、用户访谈、焦点小组和用户画像等等，都是现在腾讯内部最常见的用户研究方法。阅读文章 > 了解可用性测试1. 可用性测试的优势可用性测试是确定用户是否完成目标的核心方式，它与其他用户研究方法有许多相同的测试指标，并且能够得出较多可用的定性数据，可以收集的数据类型也比较多，例如，完成率、出错数、任务时间、任务水平的满意度、测试水平的满意度、寻求帮助的次数和可用性问题清单，这些数据极大的便利了后续的分析工作，帮助多维度的判断产品的状态、用户的满意度、体验问题等等。2. 可用性测试的类型可用性测试可以分为两种测试类型：形成性测试（Formative Test）和总结性测试（Summative Test）形成性测试：主要作用于查找与修复可用性问题，提供及时反馈便于改进，是设计师重点参与的测试类型通常以小样本量的定性调查数据以问题描述和设计建议形成输出采用频率和严重性为指标量化问题，追踪那些用户用到什么样的问题，衡量完成任务时长，并判定他们是否成功的完成任务等总结性测试：用指标度量可用性，用来评估效果，其中又分为基准测试和比较测试3. 可采集的数据样本量：通常大于 30，当数据量小于 10 可通过统计学方法计算得到有效统计分析结论代表性：样本能够代表预期要描述的用户群，若存在不同用户群组中有重要差异因素的使用分层抽样（Stratified Sampling）的方式随机性：考虑所有重要变量，设计理想样本，合理合并用户群组测试数据：现场/远程测试，观察记录用户行为，与用户互动深入挖掘问题完成率：即成功率，完成=1、失败=0，完成率=完成任务用户数/用户总数可用性问题：根据问题出现的频率和影响程度评估严重性、优先级任务时间：任务完成时间、直到用户失败所用的时间、任务总时间出错数：尝试任务产生的无意识的出错数量，诊断失败原因，预判可能出现的场景满意度评分：使用标准化可用性问卷，回收数据计算得出复合分数：复合型总结可为用户体验提供更好的总体描述可用性测试问卷经过长期的研究和市场验证，目前已沉淀出很多标准化的可用性问卷，不同的问卷的评估针对性不一样，可以满足大部分用研需求。使用标准化的问卷是因为这些问卷是经过大量的使用后验证校准后产生的，是被认可具有通识性的衡量标准，这些问卷都具备客观性、重复性、量化、经济、沟通、科学的普适性的优质属性。1. 标准化的可用性测试问卷问卷类型主要可以分为以下两大类：列表中的问卷大部分是需要缴纳一定的费用后才能使用，但其中系统可用性整体评估问卷、软件可用性问卷、场景后问卷是标准可用性问卷中可以免费使用的。应用广泛且被专家推荐的测试问卷是：软件可用性问卷主要针对系统或功能进行整体评估，问题设计精炼清晰，使用快捷方便；单项难易度问题追求的是心理测试的简单和适用性，有 5 分和 7 分制，7 分制的可靠性更高；主观脑力负荷问题是在线测试，灵敏性更好。综合评估下，软件可用性问卷（Software Usability Scale，SUS）是设计日常中最合适最经济实用的测试问卷。2. 软件可用性问卷（SUS）软件可用性问卷是可用性测试结束时的主观性评估问卷，应用广泛，测试后该问卷使用占比约 43%。整个问卷共 10 题，每题为 5 分制，奇数项为正面描述，偶数项为反面描述，可以通过修改问题文案聚焦测试范围；如有需要可以将偶数项的问题调整为正面描述，但数据验证调整为正面描述的问卷结果与包含负面描述的问卷差异不大，不影响问卷的测试结论。在完成测试任务后，用户需快速完成各个题目，不进行过多思考，若用户因某些原因无法完成其中某个题目，则视为选择中间值。3. 可用性、易用性抽取问卷整体可以抽取部分题目作为子测量表来作为单独的问卷有针对性的进行可用性和易学性测量，可用性由问卷中 1-3、5-9 题构成，易学性由问卷中 4、10 题构成。研究表明使用子测量表对量表的可信度的减低可忽略不计（0.92 0.91），并且使用子测量表可减少答题时间。4. 分值计算得分计算：范围在 0-4，每题进行转化分值；奇数题（正面）：原始分减去 1，（x-1）；偶数题（负面）：5 减去原始分，（5-x）SUS 总分= 所有转化过的分值相加 * 2.5, 多样本算 SUS 总分均值可用性总分=所有转化过的可用性分数相加*3.125易用性总分=所有转化过的易用性分数相加*12.5统计学描述方法可用性测试因为耗费时间较长，能够参与测试的用户资源稀缺，回收样本量小能够收集到的样本量一般会比较小。样本量小的情况下这个样本量所能概括的整体是范围比较大的，会存在较大误差，那么在较为严谨的报告中，可能需要对所得分数和除测试样本外的分值预期进行描述，这时候会涉及到统计学中常用的描述方式，即通过置信度及置信区间来描述，根据置信区间的下边界看软件是否低于行业标准。1. 相关概念置信区间是指在一定概率下包含样本位置总体参数的这部分数值区间，通过计算置信区间来描述测试结果的概率。置信区间宽度和样本量之间是一个逆平方根的关系， 样本量越小，误差越大，未知样本数据可能所在的区间更大。置信度就是说，你测得的均值，和总体真实情况的差距小于这个给定的值的概率，应该是 1-α；换句话描述，即我们有1-α的信心认为，你测得的这个均值和总体的实际期望很接近了（测得的均值就是总体期望是很草率的，但是说，我有95%的把握认为我测得的均值，非常接近总体的期望了）。研究员可以选择0%-100%之间的任意数值的置信度，通常设为90%或95%（最常用）。临界值是在原假设下，检验统计量在分布图上的点，这些点定义一组要求否定原假设的值。2. 置信区间计算置信区间= （样本平均值-误差幅度）～（样本平均值+误差幅度）=（x -（x- μ））～（x +（x- μ））x = 样本平均值误差幅度=临界值*（样本标准差/样本量的平方根），即：（x – μ） = α* （s / sqrt（n））α=临界值（Excel函数=TINV（1-置信度，样本量-1））μ=被检验的基准值（行业标准）s=样本的标准差（Excel 函数=STDEVP（N1，N2，..））n=样本量tips：临界值可以通过所设置信度和样本量在 t 分布表中查找相应的值3. 可用性测试策划应用在做可用性测试前，需要进行很多准备，过程中也需要记录很多相关的信息，初步尝试的设计师可以参照以下步骤完成可用性测试的整个流程：Step1: 确定调研目标（目的、用户、时间、环境）Step2: 确定测试任务（任务内容、测试方案、SUS 问卷地址），任务内容可以通过抽取用户体验地图（User Journey Map）流程中的触点设计，保证流程的完整性和任务的关联性Step3: 引导测试用户完成可用性测试，过程中记录测试时间、用户遇到的问题、发生的频率等等，记录类型可以根据测试测中点进行记录Step4: 用户填写 SUS 问卷，回收问卷分数进行计算，得出 SUS 分数、可用性分数、易用性分数的均值作为本次测试的结论Step5: 作为补充，可以计算 SUS 样本分数的置信区间，预期未被测到的目标用户对产品的评分可能落在的区间，区间下限可横向对比，看是否低于行业标准。可以描述为“样本分数标准误差约=5.34，置信区间为 63.78～69.12；有 95%的把握认为测得的均值接近总体期望，未测样本分值将落在 63.78～69.12 之间，符合行业标准预期”。Step6: 通过测试过程中观察用户行为，探讨用户提出或下意识忽略的问题，并进行问题的记录和分类Step7: 用户访谈记录问题进行解析，对问题的严重程度进行评级，选出问题较多的部分并提供可能的解决办法进行优化Step8: 根据以上结论对测试进行总结性分析Reference数据：文中数据为样例，非真实数据，仅作为演示用途资料：《用户体验度量：量化用户体验的统计学方法》 — Jeff Sauro, Jame R Lewis图片：https://www.jianshu.com/p/d9346e4dd1b0https://www.pianshen.com/article/4953599654/密歇根大学官方课程：10分钟学会进行可用性测试！大家好，这里是 TCC 翻译情报局，我是李泽慧。阅读文章 > 欢迎关注公众号「酷家乐用户体验设计」本篇来源：优设网原文地址：https://www.uisdc.com/use-usability-testing
在路上
张大湿
