前言 这篇文章针对车载行业的可用性测试，我们做一下深入探讨，前面几篇跟下来的读者也都知道我写作的节奏，前面会深入讲解该主题的基础内容，并结合一些我工作中实际案例给予大家去了解，后半部分以实践案例为主，将前面基础知识融入进来，结合案例进行剖析可用性测试，这次文章大纲分为三大内容：可用性基础知识、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车载领域的可用性测试，但其他领域的设计师们也可以有学习的内容。
