用户 测试 问卷 用户研究对于设计具有重要的意义，不仅能够为设计团队提供可信性和权威性的依据，而且能够让团队与用户达成统一认知，帮助我们在设计问题上做出更全面科学的决策。最近浏览了超过 30 篇用户研究案例，总结了 3 种常见的用研类型：问卷、访谈、测试，以及具体的实践流程。分享给大家，希望对大家有帮助！！相关干货：万字干货！大厂最爱的用户研究方法全方位科普导读：这篇长文主要讲述了用户画像与用户体验地图在实际应用中的作用、差异、流程、实用技巧和关联。阅读文章 > 写在前面社会科学领域中将研究方法分为定性研究和定量研究 2 种，在开始介绍这些用研类型之前，我们需要先了解这两种研究范式的基本概念与区别。定量研究（Study on measurement）：定量研究是指确定事物某方面量的规定性的科学研究，将问题与现象用数量来表示，进而去分析、考验、解释，从而获得意义的研究方法和过程定性研究（Qualitative research）：定性研究是指通过发掘问题、理解事件现象、分析人类的行为与观点以及回答提问来获取指导性的结果。简单来说，定量研究和定性研究是相对的两个概念，前者考察和研究事物的“量”，后者考察和研究事物的“质”。因此，两者在研究范式上存在着明显的不同。 具体区别可以从研究目标、研究对象、研究方法、问题形式、结论表述 5 个方面来阐述。研究目标：首先，研究目标上，定量研究重视对目标的预测而定性研究重视对用户的理解。研究对象：研究对象上，定量研究强调事实的客观实在性而定性研究强调对象的主观意向性。研究方法：定量研究主要运用统计分析、建立模型等方法，设计师常见的定量研究工具有桌面调研、问卷调查、A/B 测试等；定性研究则主要运用逻辑推理、历史比较等方法，常见的定性研究工具有用户访谈、焦点小组、角色推演等。问题形式：定量分析只能回答少数简化轴上“多与少”的问题。而定性研究能够以丰富多元的形式回答“是什么、怎么样、为什么”等问题，能够真实反映现实情况的复杂性。结论表述：由于研究目标及方法的不同，两者在结论表述上有着较为明显的区别。定量研究主要以数据、模式、图形等来表述；定性研究结论多以文字描述为主。一、问卷问卷一般指的是“问卷调查”，是最为常见的一种定量研究方式，当然也可以进行某些定性的调研。它是由一系列问题组成，用户自行在纸上或线上完成答题。问卷调研的流程一般可以分为 5 个步骤。问卷准备-问卷设计-问卷投放-数据回收-报告产出。1. 问卷准备① 明确调研目标当你想要比较不同用户的答案、向大量用户进行提问时，可以考虑采用问卷调研的形式。研究一定要具备目标导向性，进行问卷调研之前，必须明确调研目标。目标的设定应尽量客观，很多设计师设定的目标只为了证明自己的观点是正确的，结果围绕这类目标的问题往往具有很强的诱导性。② 明确调研用户一个产品可能涉及到多个用户的使用，甚至会对用户做分层的运营，特别是 C 端产品，不同用户所使用的功能和习惯会截然不同，因此在设计问卷的时候，我们需要明目标用户的特征，新用户还是老用户？活跃用户还是流失用户？围绕用户属性采取不同的问卷设计策略。③ 选择问卷工具现在市面上有着非常成熟的问卷设计工具，都能满足问卷的发放及回收功能。目前比较常见的有问卷星、腾讯问卷、Credamo、金数据等。2. 问卷设计① 梳理框架框架应该满足先客观后主观的特点，问卷的框架可以分为 4 个部分，顺序依次是开场白-基础信息-封闭式问题-开放式问题。举个栗子：开场白：优秀的开场白可以提高问卷的完成率，告诉用户本次调研的目的，有多少道题目，会花费用户多少时间，用户坚持做完会有什么报酬等等。基础信息：一般是和用户特征的相关的题目，目的是为了快速捕捉用户特征，增加分析维度。封闭式问题：封闭式问题一般提供特定的选项，是一种客观的提问方式，是或者不是，会或者不会。开放式问题：这种问题可以得到非常多样的答案，是一种主观的提问方式。当你想要获得尽可能多的反馈时，可以提这种问题。比如对于产品的建议等。但请记住，不要在刚开始就问用户一些开放式的问题。否则用户可能会直接退出。② 设置题型、逻辑题型：几乎所有的问卷工具编辑时都可以预设几十种题型的选择，常见的有单选、多选、填空、评分、表格，高级的有矩阵、排序、量表、比重等等。一般来说，常见的题型就可以满足基本问卷的设计。逻辑：如果你想获取调研更多的信息，可以对选项设置不同的逻辑关联，常见的逻辑类型有 3 种：关联逻辑、跳转逻辑、引用逻辑。示例如下：③ 设计后续回访问卷调研有一个弊端，不能对用户的回答进行补充提问。所以我们需要设计一个后续回访的方式，比如留下你的联系方式，或者给用户一个同意后续联系的操作。总之，确保问卷回收后可以追溯到问题的来源进行补充提问。3. 问卷投放① 圈定目标人群问卷投放不是遍地撒网，投放时根据目标控制答题者的年龄、性别或地域等条件，做到目标人群的精准投放，回收的数据才会更真实有效。② 选择投放渠道渠道可以是单一的，也可以是多元的。常见的投放渠道有微信群、朋友圈、问卷二维码、群发短信与邮件等。C 端产品由于用户体量大，一般会在产品内部预留问卷入口。B 端用户发放路径会有限制，可以找运营团队、客服团队针对性的发放。4. 数据回收① 筛选样本一般来说，参与的人数越多，得到的信息就越可靠，主观信息也是这样。因此，在研究中，尽量多收集一些信息。但并不是所有的信息都是有价值的。在样本回收后，我们需要剔除无效样本，筛选出有价值的样本，保证数据真实性。一般来说筛选样本可以通过 2 种方式：自动筛选、手动筛选。自动筛选：如果计划回收的问卷数量很多，建议在问卷投放时制定无效问卷的规则，比如省份、城市、填写所花时间等。问卷星、腾讯问卷等工具都提供了自动筛选的功能。手动筛选：对于样本量较少的问卷可以采用手动过滤方式，下载初始数据后，对样本进行逐一筛选。最终保留有参考价值的数据。② 单一维度分析单一维度和交叉维度是相对的概念，我们回收的每个问卷数据，都可以看作是单一维度的分析。③ 交叉维度分析设置一个或多个自变量（X）和因变量（Y），通过交叉分析，取得综合结果。一般来说，自变量常常客观信息（性别、年龄、身份）等，因变量常常为要分析的客观问题或者主观问题。通过交叉分析，我们可以得到更加全面、有价值的数据。5. 报告产出① 原始数据原始数据指的是未经分析与转化的回收数据。原始数据的文档不需要在汇报中展示，但原始数据的留存对于团队外的分享和后续的复查具有意义。一般在汇报时，我们会在报告的结尾处附上原始数据的链接，方便感兴趣的同事查看。② 总结规划总结一般包括调研目的、数据回收情况、分析结论、优化建议。如果是定量研究的数据，可以在报告中用模型、图表的方式来表述。用户主观描述的定性问题，也应对问题进行大致的分类，方便在报告中展示。除此之外，有了研究数据之后，需要分析一定要有后续的解决方案和大致的规划，形成完整的闭环，进一步突出调研的价值。二、访谈访谈就是你事先准备好一系列问题，然后当面询问用户。访谈调查是通过向受访者提问来获取信息的总称。是一种定性调研的方法。常见的访谈方法有用户访谈、焦点小组等。访谈的流程一般可以分为 4 个步骤。访谈准备-进行访谈-输出结论-报告产出。1. 访谈准备① 确认访谈目标尽管访谈可以和测试者直接接触，但在收集用户使用产品做什么、如何使用产品等方面表现并不佳。访谈更擅长收集用户的某些行为习惯或使用哪些产品方面的意愿。所以在进行访谈的初期，我们需要深入的探讨用户研究的目标，从而选择合适的方式。② 招募用户访谈不同于问卷，是一种点对点的用研方式，所以访谈用户的筛选比问卷更加严格，除了符合目标人群外，还要划分用户是否具有代表性。如果你需要对多个用户进行访谈，你还需要考虑目标用户的配比，尽量找一些能代表不同人群的用户。常见的用户招募渠道有 3 种：内部推荐、问卷筛选、机构代理。③ 预设访谈大纲访谈的过程是网状的，如果缺乏结构性的串联，很可能在访谈中迷失方向，导致漏掉某些重要的内容。从内容的划分上，访谈类别可分为：非结构式访谈、半结构式访谈、全结构式访谈三种。非结构式访谈：指有主题、却没有操作化为具体访题的访谈，是非正式的、随意的。只需要让用户充分表达自己的观点即可。半结构式访谈：有主题，有大纲。是一种比较灵活的访谈方式，可随时调整问题的顺序、新增问题等，是实际的工作过程中最常用的一种形式。全结构式访谈：把研究问题操作化为具体访题、且访题之前有严谨逻辑结构的访谈。在访谈大纲顺序不变的情况下，用户可以进行自由的表述，并进行补充提问。对于访谈经验不足的人员，建议采用半结构式访谈和全结构式访谈的方式。提前预设好访谈大纲，方便及时发现未访谈的要点，以此增加对整个访谈的把控。④ 确定场地、时间当你想对多个用户同时进行访谈时，你会发现，把他们聚集起来并不是一件容易的事。所以尽量在招募成员的阶段就确认好访谈时间，防止出现招募后时间冲突的情况。访谈可以在很多地方进行，可以直接去受访者的家里，也可以邀请受访者聚集到某一个地方。大部分情况的是请用户到公司来，然后使用公司内部的会议室进行访谈。访谈人数较少的话，建议选择公司附近的咖啡厅等一些温馨舒适的公共区域，这种访谈环境不会有太强的压迫感，从而减缓用户的紧张情绪。⑤ 准备访谈报酬访谈需要花费用户的时间，除非你和访谈对象关系很铁，否则最好准备一下访谈的报酬，让用户知道这次行动是有回报的。有了报酬体系，不仅可以让用户认真对待这次访谈，还能方便后续跟进前期访谈没有注意到的问题。⑥ 准备相关素材除了与受访者交谈，访谈需要全程记录内容。所以在人员配比上建议由 2 位以上的设计师参加，一位负责引导谈话并适当做些笔记，另外一位负责详细记录访谈内容，查找提问的漏洞。道具上除了笔记本、电脑这些基础的设备外，你还需要准备录音工具和记录工具。这里推荐几款不错的提效应用 印象笔记、石墨文档、魔音助手、Verse 等。如果你需要将用户的内容进行公开，还需要准备一份授权协议书，尊重用户的隐私。人员：至少 2 位（一个提问、一个记录）道具：录音工具、记录工具、访谈大纲、授权协议2. 进行访谈访谈流程可按照开场白-探索式访谈-开放式访谈-封闭式访谈-结束语的步骤展开。① 开场白人们对于陌生的人和环境有着本能的排斥情绪，好的开场白可以减少用户的紧张情绪，消除用户的担心，快速建立信任关系。我们首先可以进行简单的寒暄和自我介绍。通过轻松的沟通先活跃气氛，让用户更加放松。紧接着就可以告诉用户此次访谈关键信息：此次访谈的目的、时间等。② 探索式访谈早期访谈具有探索性质，重点是了解用户一些基本属性。问题通常较为广泛、开放。较少探究细节。目的是为了对用户有了一个比较彻底的了解。如果访谈人员直接切入核心话题的话，就会导致用户省略原因和背景，直接表述结果的情况发生。③ 开放式访谈在对用户有一个比较深入的了解之后，设计师可以按照大纲提出开放式和明确的问题，形成初步轮廓。这时的问题通常更关注于细节和深度。用户在回答一些问题后，可以适当的进行补充提问，确保得到用户更开放、深入的回答。④ 封闭式访谈访谈的后期，设计师依靠先前观察到的用户模式，快速回顾访谈的内容和回答。聚焦到与调研目的相关的核心信息，对任务和信息需要的假设进行细微调整，提出更多侧重封闭型的问题，对数据进行收尾。⑤ 结束语结束的时候向用户表明本次访谈已结束。向用户表达感谢。如果访谈过程中得到了一些负向的反馈，告知用户问题我们很重视，会尽快把收集到的访谈内容反馈给相关部门。如果提供了奖品和红包也需在访谈结束后一并发给用户。一些参与度高、善于沟通的优质客户，需要在访谈结束后维护好关系，方便再次访谈。3. 输出结论① 整理原始记录原始记录不需要任何修改，一般来说，负责记录的人员会在访谈的间隙快速整理笔记，对之前记录不完全的部分进行补充以及快速的检查。但难免会有一些问题记录的不够充分。这个时候需要设计师整理一下原始记录。对记录进行查漏补缺。② 问题归类没有任何一个开发人员希望拿着访谈录音再听一遍。对不同用户遇到的相似问题进行归类，聚焦到大致的问题类别。适当情况下，可以突出问题比较多的模块。这样不仅方便其他成员进行查阅，对后续解决问题也有指导性的帮助。4. 报告产出① 原始文档原始文档一般包括 2 份，录音文档和笔记的文本文档。如果录音清晰的话，可以使用一些转化工具，直接生成录音的文本，提高产出效率。② 优化建议不是所有的访谈都要给出明确的产品建议，但对于报告来说，优化建议很重要。访谈研究的建议往往基于访谈记录以及被访者提出的问题。很多设计师会把访谈过程中的用户建议当作产品下一步的推进方向。其实这是不正确的。设计师要理解和转化用户真实的需求和动机，然后再把真实的需求落实到具体的产品流程中，从而给出产品的优化建议。三、测试测试是测量用户与产品交互特点的一系列技术总称。一般来说。测试需要在较为完善和连贯的设计成品上进行，通常是为了验证某一个产品的设计。也就意味着，测试一般是放到设计周期的后期进行。常见的测试类型有可用性测试、A/B 测试、眼动测试等。测试的流程和访谈类似，但操作内容有区别，访谈流程也可以分为 4 部分：测试准备-进行测试-输出结论-报告产出。现在越来越多的公司将测试流程纳入产品生产周期，甚至有专业的测试团队进行测试。对设计师来说，测试可以保障线上还原度和体验闭环，对于保障用户体验至关重要。这里主要介绍可用性测试。1. 测试准备① 建立测试标准组织者需要在测试前建立测试标准，目的是更好的观测用户体验。国际标准化组织覆盖（ISO）人机交互部分把计算机“可用性“规定为 3 个指标：有效性、效率、用户满意度，这 3 种指标是比较常用的可用性指标。组织者可根据测试目标，自定义二级指标内容和规则。② 招募测试人员现在的互联网环境中，很少有公司会花费成本招聘外部人员进行可用性测试。所以可用性测试人员一般都是公司内部的相关人员。如果需要招聘外部人员进行测试，招募渠道可以参考访谈的招募渠道类型。③ 准备测试材料测试的准备材料主要包括测试文档、测试设备、录音设备、录屏设备、记录本等。测试文档：包括测试前的测试标准表、任务脚本；过程中的记录表格；测试后的体验测评的表格等。测试设备：取决于目标用户群体主要使用的设备，如果目标群体大部分是安卓系统，那么我们应该配备不同型号的安卓手机。如果我们测试网页这种涉及多设备的场景，需要准备好不同的设备。录音设备：和访谈一样，我们需要录音设备记录测试的过程。便于测试结束后进行详细的信息整理，可使用手机自带录音功能或专业录音笔。录屏设备：录屏资料可以帮助定位到操作过程中的许多细节。一般的电脑、手机这些测试设备都会自带录屏功能。如果部分测试设备无法录屏，则需要自备录屏道具。记录本：记录测试过程中用户的行为。④ 确认时间、地点和访谈一样，测试前需要确认好地点和时间，一般来说，大部分的测试地点是在会议室进行，需要注意的是，测试的过程需要录屏和观察，所以测试区域的分配上要保留测试区和观察区两块区域，保证能够清晰的看到测试者的情况。2. 进行测试① 发布测试任务进行测试之前，我们需要将测试剧本分配到具体的测试者，测试任务一般包括 2 点：任务目标和情境条件。任务目标：指的是本次测试想要完成的最终目的，情境条件：指的把任务润色成用户一个实际的使用场景，或者给任务设置约束条件。比如你想测试某个购买流程，目标是让用户完成购买操作，情景条件是价位、品类和功能限制。测试任务可以写成：你想要购买一个价位在 150-200 之间的 XX 品类商品，不使用搜索功能的条件下完成本次购物操作。② 观察与记录观察：观察员通常由项目高参与度的专业人员担任，设计师或者产品经理。观察用户的操作过程中的表情、行为、表述内容等。观察员在观察过程中应该保持中立、客观，可以适当的时候深入问询问题，帮助用户表达潜在的意图。记录：观察员需要尽可能的完整记录被访用户的言语内容、情绪、用户操作路径、完成情况等。这样比起后续听录音笔、看用户操作视频再来记录会更高效。而且在用户测试完毕后，需要对测试过程中遇到的问题进行补充提问。③ 体验评测一般可用性测试完毕后，可以使用一些方式去评测流程的整体满意度。除了直接询问外，比较常用的方法有场景后问卷（ASQ）和系统可用性问卷（SUS）。场景后问卷：ASQ 是一份五点或者七点量表，共有 3 道题目，评估维度从任务难度、完成效率、帮助信息三个方面获取测试者的直接反馈。通过得分/总分的方式取得一个平均分值，平均分值越高代表体验越好，只有大于 0.6 才能合格。系统可用性问卷：SUS 量表被认为是 80 年代经典的可用性问卷标准，SUS 用于评估对整体系统的可用性，它是一份五点量表，共有 10 道题目，评估维度有可用性和可学习性。SUS 分数计算比较复杂，经过大批数据的研究和应用迭代。最终的分数计算方式有 3 步，步骤一：所有奇数题目得分减一后相加；步骤二：所有偶数题目得分由五减去后相加；步骤三：将奇数题最终得分+偶数项最终得分，然后再乘以 2.5 即最终 SUS 得分；得到的总分对应以下不同的评级，共有 ABCDE5 个级别，一般来说，大于 70 属于合格。3. 输出结论① 数据收归一般来说，测试过程中的问题一般会聚集到某个点，数据收归的目的是对各种问题进行分类整理，类别可以按照划分的指标类型、解决优先级或者问题类型来分布。这样能够很直观的展现问题缺陷与突破口，同时能够快速体现测试价值，或者说你进行可用性测试为业务带来的价值。② 确认优化排期测试的一大好处是测试结论可以直接转化为产品文档进行后续的产品改良。所以在我们进行数据收归后，应及时协同内部团队做好后续的排期优化工作，将设计调研结果的价值发挥到最大。这一步才是最重要的，也是设计师价值提升的体现。4. 报告产出① 测试报告当我们完成所有数据收归后，需要产出一份完整的测试报告。报告的撰写可以从测试背景-测试过程-测试结论-优化排期四个维度来完成，这里不做赘述。② 材料归档可用性测试是产品研发周期的必要流程，每次测试报告的归档和管理也至关重要。归档材料主要包括被访用户基本信息、任务测试记录表、每一个用户的录音与录屏材料、测试满意度的问卷及结果、可用性测试问题汇总表、总结报告。在这一步才表示我们所有的设计调研工作结束了。总结用户研究是做好设计的关键，以上就是用户研究的 3 种常见类型。问卷调查和访谈能够帮助设计师在开发早期理解用户真实的需求、动机。测试能够评判设计是否简单高效。在开发周期各个阶段采用合适的用研方法，产品将会最终收益。对于设计师来说，虽然日常工作中并不是都有机会进行用户研究，但用户研究是项不可缺少的技能。暂时不用没关系，Mark 一下。源文件链接：https://www.figma.com/file/BwLfmNE64MVakvohIzBvRB本篇来源：优设网原文地址：https://www.uisdc.com/user-research-type
测试 用户 可用性 前言这篇文章针对车载行业的可用性测试，我们做一下深入探讨，前面几篇跟下来的读者也都知道我写作的节奏，前面会深入讲解该主题的基础内容，并结合一些我工作中实际案例给予大家去了解，后半部分以实践案例为主，将前面基础知识融入进来，结合案例进行剖析可用性测试，这次文章大纲分为三大内容：可用性基础知识、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
测试 剪裁 像素 UX 设计师与开发、测试同事交流有障碍？沟通费时？不用怕，读完这篇文章你将掌握开发、测试常用术语及基础知识，沟通效率+10086。背景概述：设计师在日常工作中，避免不了与开发、测试同事沟通交流。他们说的话，你真的听明白了吗？如何更快、更好的无障碍交流？这就需要我们设计师，多多了解开发、测试同事们常用的术语，以及一些与设计相关的代码知识。常用术语1. 开发测试常说的 DEV 环境、黑盒、沙盒、SIT、UAT 是什么？开发的流程是怎样的？UE/UI 在何时介入验收测试比较好？设计师日常工作中，除了设计输出，设计验收也很重要。你们是否遇到过以下情况：不知道什么时候开始设计验收，等到上线了才发现设计还原不到位；测试通知设计验收，给出验收文档后，却因为已经到了上线节点，延后处理（这是因为验收的节点不对，测试通知晚了）；提前主动要求验收，开发测试给过来各种各样的安装包，DEV 环境、黑盒、沙盒等等，每次的叫法让人晕头转向，账号都搞不清了。如果你有以上问题，就跟着我来一起了解一下，开发测试的常用环境术语吧～DEV 环境：develop，即代码开发的环境黑盒/SIT：黑盒测试/系统集成测试(System Integration Testing)，黑盒=SIT，开发人员、测试人员测试流程是否走通。它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。沙盒/UAT：沙盒测试/用户验收测试((User Acceptance Testing)，沙盒=UAT，由专门的测试人员验证，验收完成才能上生产环境。计算机专业术语，在计算机安全领域中是一种安全机制，为运行中的程序提供的隔离环境。通常是作为一些来源不可信、具破坏力或无法判定程序意图的程序提供实验之用。通常是由最终软件的用户（通常这些用户不了解软件的具体逻辑，而对业务逻辑却相当熟悉）进行的测试，因此是面向最终用户的测试，结束之后通常就可以发布生产环境了。每个公司所使用的环境或开发流程顺序可能不一样，可以先通过对于上图的基础了解，去跟自己公司的开发测试同学询问学习，深入了解自己公司的开发测试流程，制定属于你自己的设计验收规范～2. “冒烟”是什么意思？冒烟即冒烟测试，跟黑盒、沙盒测试的侧重点不一样，黑盒、沙盒是手动测试流程、样式、交互等等，而冒烟测试主要用于压力测试，比如同时载入 N 条数据或者点击动作，测试服务器是否能承载这样的操作，整体流程是否会有阻塞等等。冒烟测试执行，与正式测试的区别在于二者侧重点不同，冒烟测试关注的是阻塞型缺陷，包括但不限于流程不通、主要功能未实现等，而正式测试则属于全面、细致的测试，需要尽可能的发现全部缺陷并按其严重性进行区分。这个术语，跟设计师关系很小，此处只是简单讲解，大家了解即可。3. “栈”是什么？在设计中有怎样的体现？栈，存储货物或供旅客住宿的地方，可引申为仓库、中转站，引入到计算机领域里，就是指数据暂时存储的地方，所以才有进栈、出栈的说法。栈在程序的运行中有着举足轻重的作用。最重要的是栈保存了一个函数调用时所需要的维护信息，这常常称之为堆栈帧或者活动记录。堆栈帧一般包含如下几方面的信息：函数的返回地址和参数 临时变量：包括函数的非静态局部变量以及编译器自动生成的其他临时变量。在设计中的体现，例如下图的密码登录流程：设计与开发1. 文字、段落的适配，开发是如何实现的？对于段落文字的显示，最终落地效果，经常达不到 UI 的预期。一方面是 UI 在设计的过程中考虑不完善，一方面是开发在实现的过程中偷懒使用了默认属性。对于文字，常见适配方式有以下几种：1、无适配；2、省略；3、换行以上这些属性可以结合使用，达到我们想要的 UI 效果，比如超过多少行省略都是可以实现的。对于适配方式，我们最好告知开发或在UI上有所体现，以呈现较完整的视觉样式，不然开发就会按照自己的理解随便写样式。结合一些其他属性，我们来看看，对于需要自适应控件的设计，开发是如何实现的，我们需要注意些什么案例一：文本段落的设计还原比如上图设计稿：单行的上下间距和多行的就不一样，到了开发那边实现，开发若是给了一个定值，这就造成了最终的落地稿和视觉稿有误差。若是按照设计稿上的实现，收起展开就会出现动效过渡抖动的情况。如何解决：我们在设计的过程中多注意一下代码规律，能统一的尽量统一，非必要的避免单独定制（因为不同平台的代码特性，除了通用的，单独定制的多少会有差异）案例二：按钮的设计还原2. 不同平台，可拉伸元素是如何使用的？哪些元素需要拉伸使用：气泡、不规则背景板、特殊投影切图等等为什么要使用可拉伸元素：1. 为了自适应适配：如果一个样式，里面的内容有多有少，我们不能每种场景都切一张图吧2. 为了适配不同分辨率：可拉伸元素，不同分辨率下用一张就足够了3. 为了减少图片的大小：比如一张带特殊投影的背景板，正常切图体积很大的时候，我们可以考虑只切一部分以减少图片体积不同平台如何使用可拉伸元素：1. 安卓：点 9 即.9 是 andriod 平台的应用软件开发里的一种特殊的图片形式，文件扩展名为：.9.png；这种图片能告诉开发哪部分可以被拉伸，哪一点部分不能被拉伸需要保持原有比例；2. iOS：自带拉伸属性只需要提供图片质量较高的切图，拉伸效果可由代码控制；3. H5：切图+开发自己写规则图形拼接（都是规则图形：规则三角+规则矩形，开发自己写）如果气泡的小三角是规则的三角形，就不需要提供切图如果气泡的小三角是带圆角的三角形，是需要提供切图的，可以给一个三角形的 svg。3. 各型号的手机的适配、倍率关系与实现效果首先，我们需要先了解以下基础概念：英寸、分辨率、设备独立像素、设备像素比等等常见走查疑问：为什么在不同手机上样式呈现有差异？随着手机设备的多样化，有些手机的设备独立像素和设备像素比的乘积并不等于物理像素，这就造成了在不同手机上样式呈现有差异的原因。为什么 iPhone 12 的文字显示比 iPhone 11 大？一个原则：同样大小的屏幕，逻辑分辨率越低，字体越大。为什么在同一个手机上 H5 文字看起来比本地偏大？这点要根据不同公司使用的开发单位去看。H5 的 1px 细线问题，为什么有的开发写出来的细线比较粗？因为移动端的屏幕不仅仅分辨率有差异，其实还有 Retina 屏的问题。正常情况下，我们代码里的 1px 在屏幕上就应该显示一个像素点，但是在 Retina 屏下则不仅仅是一个像素点。以 iPhone6 为例，其 dpr（device pixel ratio）设备像素比为 2，css 中一个 1×1 的点，其实在 iPhone6 上是 2×2 的点,并且 1px 的边框在 devicePixelRatio=2 的 Retina 屏下会显示成 2px。常见各类手机设计像素和倍率关系表：https://uiiiuiii.com/screen/4. 开发是如何进行图片适配与剪裁的？在我们页面走查的过程中，有时候会发现给到开发的图片，被拉伸变形了或者重要信息被剪裁了。例如下图：想要知道出现这种情况的原因，首先我们需要先了解下开发进行图片适配与剪裁的几种方式，以 H5 为例子（iOS 和安卓同理）：结合以上开发适配剪裁方式，总结 banner 展示效果不佳，图片被拉伸变形、重要元素被剪裁掉的主要原因可能有1. banner 通常是由后台上传配置的，如果后台上传尺寸和前端的展示尺寸不一致，例如后台只设置了一个上传入口，前端我们需要在手机端、PC 端同时展示该 banner（两个端展示尺寸还不一样），就会出现以上情况。2. 不同型号的手机，图片适配方式不一样3. 对于 PC 端的动态自适应，开发适配方式使用错误如何解决？除了后台设置多入口，匹配后台和前端的尺寸，我们还可以使用以上代码特性+设置 banner 剪裁安全区域去更好的展示 banner。（开发有的时候不会想那么多，就使用默认的适配方式，我们可以告诉他怎么做）刚刚变形、被剪裁的 banner，开发一开始就是一张图去无限拉伸适配，在拉伸的过程中使用的属性也不对，造成各种变形。经过沟通，设计了一张最大的 banner，并将文案内容设置在安全区域内，其他区域根据窗体尺寸动态剪裁。5. APP 界面适配方式，固定尺寸还是固定比例？屏幕适配的原则是：大屏手机显示更多的内容；所以并不是大屏手机就根据屏幕宽高比将 UI 控件进行等比例缩放界面里的元素样式适配有两种形式：固定尺寸：不论在什么型号的手机上面，显示尺寸都是一样的固定比例（固定边距）：会根据不同型号的手机分辨率，按照在页面中的占比进行等比缩放适配。参考文章：开发丨值得设计师看看的5个开发小知识@韩重赞 ：这里整理了几点关于设计的开发知识。阅读文章 > https://www.zhihu.com/question/19939866H5 适配方式： https://developer.mozilla.org/zh-CN/docs/Web/CSS/object-fit关于移动端适配，你必须要知道的： https://blog.csdn.net/weixin_39670849/article/details/111655506如何看待 iPhone 12 系列的逻辑分辨率设置？苹果可能是如何考虑的？ https://www.zhihu.com/question/425893492从第一代 iPhone 细数到 iPhone 12，iPhone 屏幕尺寸进化历程背后的 app 设计哲学： https://sspai.com/post/62198部分配图源自网络，仅做交流学习使用，如果侵权，请联系我删除。对日常工作中与开发测试同学对接的一些知识经验总结就到这里，欢迎评论交流，让我们的设计稿落地更精致～点赞收藏给点鼓励～我会持续给大家分享日常工作实战经验总结，一起进步呀～本篇来源：优设网原文地址：https://www.uisdc.com/the-development-of-knowledge
测试 可用性 用户 设计师面试被提问可用性测试？挺意外的，就着机会结合个人的一点小心得，聊点不一样的“可用性测试”技巧。可用性测试的应用场景与作用可用性测试(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
飞翔的企鹅
在路上
落霞与孤鹜
张大湿
