如何做车载HMI可用性测试，看完你不会可以揍我

如何做车载HMI可用性测试，看完你不会可以揍我

编辑导语：随着科技的发展，车载技术也在不断地更新发展。本篇文章作者分享了车载HMI可用性测试的具体方法过程，从可用性基础知识、可用性测试类型、可用性测试方法、实际工作内容等方面出发，感兴趣的一起来看看吧，希望对你有帮助。

这篇文章针对车载行业的可用性测试，我们做一下深入探讨，前面几篇跟下来的读者也都知道我写作的节奏，前面会深入讲解该主题的基础内容，并结合一些我工作中实际案例给予大家去了解，后半部分以实践案例为主，将前面基础知识融入进来，结合案例进行剖析可用性测试。

这次文章大纲分为三大内容可用性基础知识、HMI可用性测试实际工作内容、HMI可用性测试评估维度体系，最后一点是重头戏。

我们在文章前夕先谈谈可用性测试与用户访谈，可能后期也会针对 #HMI用户访谈# 这块内容会再输出一篇文章。

可用性测试和用户访谈的区别：可用性测试更偏向于观察用户的操作行为，而用户访谈是更好的挖掘用户的需求。

可用性测试是为了找出产品的问题而测试，通过这种测试找出产品中存在的问题，加以解决，最后目的也是为了让产品用起来体验更加。

大家也发现了，关于HMI设计类文章很多平台上很少有，还有设计师工作中用到的设计方法论，如何运用到HMI车载领域当中，确实都很难找到，并且专业领域的内容车厂也不愿意拿出来分享.

我一开始写文章的初衷就是想打破这个格局，虽然一个人力量很小，但我还是坚持做下去了，希望通过我的分享能够让更多的人能进入这个赛道，并且也能输出自己的经验传递下去，成为光，并散发光。

进入我们今天的正题吧。

一、可用性基础知识

ISO9241中对“可用性”的定义是：特定用户在特定的使用场景中，为了达到特定目标而使用某产品时，所感受到的有效性、效率和满意度。

1. 可用性原则

• 有效性（Effectiveness）：用户完成特定任务的情况。比如：设定一个调节空调风量的任务，让用户操作，记录员在旁边记录用户的一个完成度的情况，成功完成、求助后完成、未完成的状态。
• 效率性（Efficiency）：用户完成特定目标的效率，任务完成时间和完成的一个路径。在记录过程中如果在一个正常时间范围内无需关注，主要还是要记录在某些功能上面花费较多时间完成的任务。在操作路径上也要观察，是否符合我们设定的操作路线，是否存在偏差或者是犹豫不决的地方。
• 满意度（Satisfaction）：用户使用该车机系统主观满意度，当然我们也要提前做好一些标准，比如任务完成的难易度进行评价，任务完成的满意度测评等。

总结一下：

一个好的可用性必须能够满足这三个维度，这三个维度也会有一个重要程度之分，有效性 > 效率 > 满意度。

需要最后补充一下：

在评估一个任务可用性以外，还要需要注意该功能的价值，尤其是OTA升级发布新的功能，功能价值分为两类：用户价值和商业价值，作为设计师的我，觉得用户的体验应该是放在第一位的，有了好的体验才能够更好的去谈商业价值，不然就是在扯蛋。

例如：我们在优化负一屏中的体验，将调节音量新增了可以调节四种音量大小，多媒体、电话、导航、语音，旧版本的音量调节，用户经常会吐槽，因为当时功能设定负一屏音量调节是整个的一个系统调节，你在音乐调节很大音量的时候，如果有一个电话接入进来，对方说话声音就很大，会吓到用户，这个在驾驶过程中会很危险的，因此在OTA升级后，我们做了优化。

二、可用性测试类型

其实可用性测试方法和类型很多，会在不同情况下使用，选取的方式也是需要看团队设定的目标、在什么阶段、最终的预算能有多少钱，真的没钱很难办事情。

1. 探索性测试

产品在不同阶段，可根据不同的测试类型做可用性测试，在产品初期可使用探索性测试方法，利用产品的原型图展示给用户，探索性的测试目的是，用户是否对这款产品有所了解，如果在某些方面有所疑惑需要记录，根据多组测试，重叠性较高的功能就需要UX去优化，在产品初期需要不断的试错。

2. 比较性测试

我们先说一下比较性测试，我们在做设计时会出几个不同的方案，需要在这个几个方案中做出选择，如果公司非常重视测试数据的话，会将设计方案同时上机进行路测，最终结合数据，让体验专家评判方案之间的优缺点，最终决策出符合用户体验的方案。

另外一种比较是选择两种或者更多的产品，去研究他们优缺点，确定哪个设计方案能够提供给用户带来良好的操作体验。

这两种方案取决于项目的时间长短，如果像服务形的乙方需要快速的出方案，则更多的采用的是第二种，甲方有着自己设计研究部门可以给到部门有试错的时间成本，那么他们更会倾向于两者相结合的方案，我们只能提供可行性的方案，最终还是需要领导层进行拍板实施。

3. 评估性测试

当产品进入后半段，在发布版本前后，上机进行测试，HMI上机测试分为在室内台架上测试，另外一种是装机在道路上测试，不同场景的路测，在这个阶段的可用的测试方法是评估性测试。

评估性的可用性测试目的是确保这个产品在发布之前将潜在的问题进行修复；在版本发布之后本公司或者一些测评机构会根据自己的评测标准进行对这款产品进行评估测试，对照自己的评判标准进行打分，方便后续OTA升级，版本优化迭代功能。

三、可用性测试方法

相信大家对于定性和定量这两个词并不陌生，在可用性测试中承担着重要的组成部分。

1. 定性 / 定量研究

定性研究是指参与本次车载系统的体验者对于可用性的一个直接评估，从而产生结果，并且发现哪些功能在操纵的时候会出问题，有哪些体验是觉得不错的，哪些功能的体验需要进行优化，听完这些内容是不是觉得和车载系统的专业测评人差不多了吧，当然，在做这个定性测试的时候需要找不同的人群进行测试，需要做到完整性。

定量研究也是我们常用到的一个测试方法，定量研究出的数据对于可用性启到了间接评估，通过参与本次车载系统体验的用户，观察他们在操作事先列举好任务上的表现状况，这些状况包含了本次任务消完成消耗的时间、完成的成功率、错误点击等。

定量研究的结果是一些简单的数据，这些数据需要有一个参考的依据，一个已知的标准，要么就是竞品体验的一个对比数据，还有一个是自己车载系统前后版本的一个对比看看改进多少（专业术语：ROI），一个词需要找到 “参照物”。

例如：在多少秒内操作是一个安全的范围值？

这方面的知识我有在我第二篇交互文章中有提交过，单次交互操作动作不能超过2秒（1秒内为最佳）如果一个在行驶过程中需要交互操作的动作 用时2-3秒就已经是一个危险状况，所以我们参考这个依据，可以进行对我们车载系统做一个判定。

定量的数据是有了，参考标准也有了，有的功能方案是不OK的需要去优化，但是这些数据没有告诉我们如何去优化它，需要在设计方案中何如去优化？定量分析研究只是记录了一个过程中得到的数据，也没办法得到用户在什么项目中遇到什么困难。

比如车辆设置中的调节ADAS的某一个设置选项，用户不知道在哪里寻找，我们只能记录这项任务失败。所以在为了更好的做可用性测试，我们通常会使用定性研究来增加进行补充缺失的部分。

2. 如何运用定性和定量研究

前面有提到他们之间的区别，那我们在日常的工作中该如何的运用呢？在什么阶段用什么研究？

在发布车载系统1.0版本和后续迭代版本优化1.x版本，可以使用定量、定性、两者组合性来评估，如果这次评估的目的是数据方面，在这个功能点上我们优化多少，提升了多少用户使用了这个功能，那么就需要采用定量分析，因为只有定量研究才能得出每一个版本对比上一个版本到底优化了、提高了多少。

需要针对车载系统重新设计内容时候，需要通过定性的研究方法去完成，在这个过程中用户的角色是承担为设计提供可行性方案的人，他会觉得在哪方面可以进行优化，到得这些用户数据和意见之后，也便于设计师们做出选择性的优化，创建出一个新的体验感，所以这个阶段使用定性研究方式更为适合。

举个例子：

用户在体验过程觉得在操作调节音量的交互感觉不好，抓住关键词“调节音量体验不好”，那么就要询问清楚，问到用户：“是在下拉出现的负一屏中 调节体验感觉不好，还是在进入设置项中的去调节音量体验感觉不好呢？

因为在做定性的研究的时候不会设定怎么进入，因此会出现通过多种方式去操作系统某一个功能，所以需要针对这个问题询问清楚，才可以正确的优化这个体验流程。

后面还需要跟进这个问题，是操作步骤过多，需要优化路径？还是在滑动的体验感需要加强？等这类问题，当然也可以让体验者去叙述他自己的点。如果同样的去发现这类的问题，你去使用定量那么会增加很多工作成本不说，预算成本也会增加。

四、可用性测试实际工作内容

由于我们项目的保密性，不能透露过多内容，我将这次案列换成了其余车载系统，这次可用性测试的目的是系统评分数据。

1. 设计任务

前面提到定量研究测试，是请多名用户来参与对我车载系统的一个体验，我们将原先设定好的任务对用户进行说明，然后我们在车内观察用户使用我们产品的一个状况。可用性的评估是基于任务的，所以接下来我们讲一下任务的五个原则：锁定主要任务、明确任务起点与目标、给任务设置约束条件、任务不应过于简单、避免提供线索和描述操作步骤。

2. 主要任务

用户在使用车载系统目的有很多种类，需要听音乐、电台、看视频、导航到目的地、接/打电话、调节空调/温度等等，可能会有上百个功能点需要去操作。

但一场测试不可能全功能进行测试，我们只有挑选出最重要的任务来进行测试，或者是刚上线的车载系统，需要测试一下基础功能评测，如果遇到产品OTA升级或者是改动很大的版本点，会改变用户的操作步骤，更或者是新增加的功能，都可以优先测试。

再举个例子：

任务：调节空调的温度

我们需要观察的是，他是如何调节空调温度的（我们设计师自己肯定知道全部的调节方案）。

第一种方案：可以点击导航栏下方的温度，点击可以进行前后拖动来改变温度。

第二种方案：按下方控按键，呼出语音 “温度调节到21度”。

3. 明确任务起点与目标

在可用性测试中最重要的就是用户能否可以完成任务项，所以需要明确目标，如果没有的话，就无法判断用户是否完成任务，我们最初设定一个目标。

例如 “在音乐界面中将播放模式调成单曲循环模式”这是我们这个任务的最终目标，只要最终用户在音乐界面中将播放模式改为“单曲循环”即为此项任务成功完成。

4. 给任务设置约束条件

在设定任务的时候，会出现可以多种方式去完成，上诉案例空调调节温度，就可以使用两种方法去完成，因此如果本次全程操作不允许用语音操作（这是作为一个约束的条件）本次的全部测试项目是关于在中控测试评估的，语音会有他自己的一套测试任务，这些都需要在任务开始前需要设定好的。

5. 任务不应过于简单

如果你想测试用户是否找到这个功能，请不要用“找到一个xxx暂停按钮”，我们需要给用户提供一个处理现实场景中的任务，而不只是去找这个按钮的位置。

例如：“找到音乐暂停按钮” 改为“在酷我音乐界面暂停一首歌曲”这样会有一个明确的场景，这个场景是可以运用到现实驾驶中出现的任务，如果变成“找到音乐暂停按钮”就属于一个不OK的任务。

6. 避免提供线索和描述操作步骤

设计任务的时候应该给出具体的目标，而不是列举好的整个操作步骤去教用户去完成，这个跟说明书没两样。

例如：“购买酷我音乐的季度会员”。进入酷我音乐界面、点击酷我音乐中我的、然后点击会员中心、再点击续费、出现弹框选择季度充值、最后扫码付款。用户在接受到这些信息后，就知道先进入音乐应用、找我的、寻找充值入口、最后再进行支付。

引导性过强的话会失去任务测试的意义，这样做会错失用户在操作过程中发现了一些问题，观察员也将错失记录的机会，如果没有这提前事先布置好的步骤，可能会出现一些操作让他感觉有异议，不知道自己是否操作成功或者是是不是点错了等等状况。

在用户使用产品的时候，我们应该考虑使用的目标，不是考虑具体的操作步骤。我们在设计任务的时候一定要避免提供线索和描述操作步骤给到体验者。

总结一下：

针对用户来看的话，车载系统对他们只是一个工具，达到他们想要的操作目的“比如听音乐、导航”这些功能目的，所以在可用性测试中，我们需要把测试车载系统某个功能目的为重点。

五、招募人选

在招募人选问题之前，需要根据这次测试的目的和需求，确认是定性研究还是定量研究或者是组合性的研究测试方式，这次的目的是对于新系统的一个评分，这次研究方向确定好是做定量研究测试。

定量研究可用性测试是基于（30+以上人 体验者），但也有时候定量研究也会少于30人，因为预算的问题，或者其他的原因无法请到这么多人。

因为招募车载系统的一个体验用户，相对于招募去体验APP、网页端产品、还是B端的产品，都会难很多，因为条件的限制，处在的环境也变化了，因为是有驾驶的一个状态，还需要去操作提前布置的任务，所以在招聘人员的时候确实相对其他平台要难。

数据就会存在一些偏差。定量研究通过任务的完成率、完成时间、满意度进行评分。这些总结性的评估数据，通常都是用于车载系统的迭代过程的跟踪，在下一个版本中数据是否得到提高，从而达到优化的目的。

另外给大家补充一下定性研究人员选择：

定性研究用户可以5人参加这场测试，就可以发现大多数（85%）的产品可用性问题，随着用户的增加，会发现的问题会逐渐减少，因此最终定性研究分析选定的人数需要我们去考量。

在后面的实际案例中，我们采用的是定量研究，会针对整个定量研究全案做一个详细的解说，也会增加一些定性的来作为补充说明。

总结一下：

我们要根据实际情况来确定我们招募的用户数量，对比每一次的测试结果于后续OTA升级后的效果，是否需要增加投入的预算来做可用性测试。

六、准备工作

在做可用性测试之前需要规划好准备的工作事宜，先是测试地点和工具的准备，后续是相关资料的准备，后面需要签署保密协议，最后就是整个的可用性测试剧本准备。

1. 测试地点和环境

HMI车载系统测试场景相对于其他端的测试场景要多，这些不同测试地点和环境主要目的就是针对影响用户操作的因素来做多方考量。

• 车载系统测试的地点：路测（大马路上，封闭路段、正常道路）、地下车库、路面停车场、隧道等。
• 车载系统测试的环境：晴天、雨天、阴天、下雪天、雾霾、沙尘暴等。
• 对于硬件的测试还会增加在不同温度/湿度下的测试：极寒地区、干旱地区、常年潮湿雨水多地区等等（这类测试跟设计关系不大，想普及一下）。

2. 准备的工具

需要在测试车内装机好需要测试的系统；安装眼动仪来记录用户的观看轨迹，便于后续优化界面设计和交互设计；还需要后排记录人员跟拍操作录像资料，便于后期的分析操作细节。

3. 相关资料

首先就是准备整套测试中的任务卡片，便于用户查看；还有要为自己准备一张表格，记录用户操作中出现状态的数据，如任务是否完成、完成时间等状态；还有一些记录关键事件和测试中观察用户体验的表格，比如设计中可能会出现的问题，方便结束后进行总结，加入到后面迭代版本点中。

4. 签署协议

在测试期间需要签署保密协议等，因为用户测试的是未上线的产品，为了确保项目安全起见，需要让参与测试的用户签署保密协议。

5. 剧本准备

HMI可用性的剧本准备和其他基本类似没有过多的出入，这个过程是：接触用户 ➡️ 开场白 ➡️ 开始测试 ➡️ 事后访谈 ➡️ 给予奖励并送走用户的整个过程，这些相同的剧本准备、还紧跟后面的观察、访谈这些内容，大家都可以自行搜索，因为下面还有更重要的内容需要细讲。

最后一步就是分析前面所得的数据，但需要一个标准去评估衡量，下一篇就会进入我们最核心的部分 # HMI可用性测试评估维度体系。

文章中如有不足之处，欢迎补充交流，我们下期见。

下期文章预告：HMI可用性测试评估维度体系。

本文由@设计界的影帝 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。