将可用性测试数据变成行动而不会发疯

收集, 分类和理解在用户研究和可用性测试过程中收集的数据已成为UX从业人员越来越普遍的任务-实际上, 它已成为UX的一项关键技能。
可用性测试将告诉你目标用户是否可以使用你的产品。它有助于识别人们在特定UI上遇到的问题, 并揭示难以完成的任务和令人困惑的语言。通常, 可用性测试涉及广泛的准备和分析, 并且被认为是最有价值的研究技术之一。它能够提供定量和定性数据, 有助于指导产品团队寻求更好的解决方案。
但是, 这不是在公园散步。为了发现可用性问题, UX研究人员和设计人员经常不得不应对大量不完整, 不准确和令人困惑的数据。由五到十名参与者组成的常规可用性测试可以轻松产生六十多个问题。在等待恐惧的分析瘫痪抬起丑陋的头时, 感觉就像” 从水喉中喝水” 。

将可用性测试数据变成行动而不会发疯

文章图片
尝试解决可用性问题时面临的巨大风险是走错了路线, 试图提出无法真正解决眼前问题的解决方案。风险是发现的问题与确定的解决方案之间可能存在脱节。这些可能是由许多不同的因素引起的, 包括决策疲劳和许多类型的认知偏差。
如何将可用性测试数据变成可行的解决方案
为了克服上述障碍, 我们需要有效的方法来处理我们的测试数据, 同时确保我们为发现的问题选择最有效的解决方案。
首先, 从创意过程中借鉴一些想法。最强大的功能之一是英国设计委员会(The British Design Council)的双重钻石, 它反过来又运用了趋同收敛的思想。这是一个设计过程, 具有明确定义和集成的问题与解决方案阶段。
将可用性测试数据变成行动而不会发疯

文章图片
双重钻石分为四个不同的阶段-发现, 定义, 开发和交付-是设计过程的简单可视化视图。 (?英国设计委员会, 2005年)
双重优势正是我们需要建立一个框架来处理可用性问题并找到解决问题的方法。
使上述模型适应结果的可用性测试需要四个步骤:
  1. 数据采集
  2. 发行优先级
  3. 解决方案生成
  4. 解决方案优先级
将可用性测试数据变成行动而不会发疯

文章图片
让我们详细了解每个步骤, 包括如何将其付诸实践。
注意:我们将需要使用一些基本数学。不用担心, 它并不过分, 在本文结尾处, 你将找到一个可以自动完成整个过程的电子表格。如果仍然无法使用, 还有一种视觉方法, 你可以使用便利贴和白板。
步骤1:可用性研究数据收集
从你的研究问题开始, 第一步是收集可用性测试生成的数据。需要对其进行设置, 以便在稍后的过程中轻松产生想法并获得见解-关键是清楚地组织和组织数据以避免混乱。在大多数情况下, 足够:
  • 具有问题识别(ID)系统
  • 记下发生的地方(屏幕, 模块, UI小部件, 流程等)
  • 了解用户正在从事的任务
  • 提供问题的简要说明
Lewis和Sauro在” 量化用户体验” 一书中使用的一种组织可用性问题的常用方法是绘制数据, 如下表所示, 问题在行中, 参与者在最后几列中。
将可用性测试数据变成行动而不会发疯

文章图片
在上面的示例中, 由三名参与者进行的虚构可用性测试产生了两个问题:
  • 参加者第一次经历(P1)
  • 其他参与者第二名(P2和P3)
步骤2:发布优先顺序
由于资源有限, 必须以优化分析的方式对可用性问题进行优先排序。通常, 每个可用性问题都有一个严重等级, 受以下因素影响:
  • 任务关键度:如果任务未完成, 则根据对业务或用户的影响进行评估。
  • 发行频率:与各种参与者发生问题的次数。
  • 问题影响:它对尝试完成任务的用户有多大影响。
要确定优先级, 我们需要遵循以下步骤:
  1. 设置测试中执行的每个任务的关键评分。简而言之, 通过为其设置数值来定义任务对企业或用户的重要性。值可能来自简单的线性序列(例如1、2、3、4等), 也可能来自更复杂的斐波那契数列(1、2、3、5、8等), 与诸如计划扑克之类的敏捷方法。
  2. 通过为该比例尺的项目分配一个值(与上面相同)来设置每个问题的影响力得分:
    • 5 :(阻止程序)问题阻止用户完成任务
    • 3 :(严重)它会导致沮丧和/或延迟
    • 2 :(次要)对任务性能影响较小
    • 1 :(建议)这是参与者的建议
  3. 通过将出现次数除以总参与者, 可以找到问题的发布频率(%)。这是一个基本的百分比计算。
  4. 最后, 通过将上述三个变量相乘来计算每个问题的严重性。
让我们看看它在电子表格中的工作方式(当然, 我们想自动化它, 对吧?)。我们更新的表如下所示:
将可用性测试数据变成行动而不会发疯

文章图片
在上面的示例中, 我们有以下情形:
  • 三个参与者(p1, p2和p3)遇到的三个可用性问题;
  • 任务” 创建帖子” 出现两次并指定为5(严重), 而次要任务(社交登录)则指定为3;
  • 给每个问题分配一个具有影响力的值:5(阻止者), 3(严重)和2(对任务性能的轻微影响);
  • 每期问题的发生频率(例如, 第2期问题发生了两次, 三名参与者, 因此, 2/3 = 0.67);
  • 最后, 严重程度是由其他因素相乘得出的(例如3 x 5 x 0.33 = 4.95)。
现在就这样。我们按以下顺序找到了最重要的可用性问题:3、2和1。在此阶段, 我们对可用性问题也有很好的认识-可以帮助团队构架高层问题并在随后的阶段进行优化的全局图脚步。
让我们继续前进, 为这些问题找到一些解决方案。
步骤3:产生解决方案
通常, 如果没有一系列建议(通用建议)和解决方案(具体说明), 可用性测试就不会在结论时完成。有时解决方案非常明显, 例如更正UI组件的位置。对于那些采用非显而易见或许多可能解决方案的问题, 情况变得更加棘手。哪种解决方案更好?哪个更可行?进行实验以找出答案的成本/收益是多少?在这里, 常规的定期推荐方法是不够的。
为了降低做出错误的设计决策的风险, 我们需要:a)可供选择的几种解决方案, 以及b)有效的选择过程。我们将使用与上一阶段处理数据收集和发布优先级排序步骤相同的趋同收敛方法。这些步骤是:
  1. 对于每个问题, 请生成多个解决方案构想-解决该问题的可能方法是什么?在这里, 我们有很大的机会与团队的其他成员(开发人员, 设计师, 产品经理等)进行协作。
  2. 重新组织解决方案, 使其保持特定性-根据需要, 合并或拆分解决方案, 以避免冗余和过多的抽象。同样, 请具体说明, 以便更轻松地评估想法。例如, 与其说” 避免使用汉堡菜单” , 不如说一个具体的解决方案, 例如” 使用水平导航和垂直树菜单” 。
  3. 标记解决方案可能解决的其他问题-实际上, 一个好的解决方案可以解决多个问题。好的解决方案是多方面的!
按照上述步骤, 结果表如下所示:
将可用性测试数据变成行动而不会发疯

文章图片
在此示例中, 我们提供了集思广益的解决方案(行)的列表, 以及每个解决方案要解决的问题(列, 代表了前面步骤中发现的问题)。
接下来, 让我们看看如何改进此列表, 并找出哪种解决方案是实施的最佳选择, 以及选择的顺序。
步骤4:解决方案优先顺序
与发布优先级类似, 我们需要根据一些参数对解决方案进行优先级排序。在敏捷团队中, 这个问题得到了非常认真的对待, 通常会使用业务价值和复杂性, 这使我们能够计算投资回报率(ROI)。从这种逻辑中借用, 我们有以下步骤:
计算每种解决方案的有效性。
解决的问题越严重, 解决方案就越好。可以将其与敏捷方法中的业务价值进行粗略比较。汇总解决方案解决的所有问题的严重性。
Effectiveness = Sum of issue severities

磨练解决方案的复杂性。
  1. 开发此解决方案需要哪些资源?
  2. 技术涉及的标准是什么?
  3. 业务/用户需求有多清晰?
换句话说, 越努力和不确定性, 解决方案就越复杂。只需将其转换为可量化的值即可, 例如斐波那契数列(1、2、3、5、8等)。如果你是团队合作, 那么计划扑克非常适合。
计算解决方案的投资回报率。这是成本效益关系, 是通过将解决方案的有效性除以其复杂性而得出的。投资回报率越高, 效果越好。
ROI = Effectiveness / Complexity

让我们回到我们的电子表格, 现在看起来像这样:
将可用性测试数据变成行动而不会发疯

文章图片
在上面的示例中, 我们有:
  1. 解决方案列表(行)
  2. 问题(i1至i3)的严重程度(4.95、6.7和10.05)
  3. 每次解决(解决)问题时, 指标都为1
  4. 每种解决方案的有效性(4.95、4.95和16.75)
  5. 团队估算每个解决方案(1、3和5)的复杂性
  6. 每个解决方案的投资回报率(4.95、1.65、3.35)
根据此示例, 我们应按以下顺序(从较高到较低的ROI)优先考虑解决方案的开发:解决方案1, 然后是解决方案3和2。
总结这些步骤:我们首先收集数据, 然后根据特定参数对问题进行优先排序。之后, 我们针对这些问题生成了解决方案构想, 最后对它们进行了优先排序。
使用电子表格
上面的方法涉及多次重复的(基本)计算, 因此最好使用电子表格。
如果你想采用这种方法, 请使用以下模板(Google表格):https://goo.gl/RR4hEd。它是可下载的, 你可以根据需要自由定制它。
我讨厌电子表格!视觉效果如何?
我认识的几乎每个人(当??然包括我在内)都喜欢使用便签和白板, 这不仅是因为它通常更快, 更有趣, 而且还因为它促进了协作。如果你是敏捷或设计思维的从业者, 你就会明白我的意思。我们如何应用便签等视觉工具来使用本文中显示的方法?好吧, 这可能值得一整篇博客文章, 但让我们尝试一下。
一种方法是创建问题矩阵(影响x频率), 然后将其放置在解决问题的矩阵旁边(有效性x复杂度)。每个矩阵分为四个象限, 表示优先级。
将可用性测试数据变成行动而不会发疯

文章图片
问题矩阵和解决方案矩阵
步骤如下:
通过根据影响和频率将便签放置在适当的象限中来创建问题矩阵。为了简化这种方法, 我们不得不省略一个参数。在这种情况下, 任务至关重要。
根据每个解决方案的有效性和复杂性, 通过组织便签来创建解决方案矩阵:
  1. 为每个问题集思广益, 从问题矩阵第1象限中的问题开始(严重性更高的问题)。
  2. 从第1象限(左上方)开始, 将这些解决方案放入解决方案矩阵中。问题越严重, 解决方案就越有效。
  3. 通过在水平轴上移动每个解决方案来调整其复杂性(越复杂, 则向右移动得越远)。
  4. 对其余问题(象限2、3和4, 按此顺序)重复上述步骤。
在练习结束时, 第1象限中的解决方案是ROI最高(更有效, 更简单)的应用, 这是头等大事。结果如下图所示:
将可用性测试数据变成行动而不会发疯

文章图片
包括我们遗漏了一个参数(任务关键性)这一事实, 这里的缺点是你必须依靠视觉准确性而不是像电子表格中那样进行计算。从积极的方面来说, 我们有一种促进协作的方法, 这有时对于从团队中获得支持至关重要。
通过” 快速而肮脏的” 视觉分析来促进协作(以准确性为代价)是一种潜在的权衡。哪种方法更好?简短的答案:最适合你的情况并且最符合你的目标的答案。
可用性测试数据分析的最后要点
使用这些方法论得出了在各个项目中使用它的团队的以下观察结果:
  1. 尤其是在进行大型研究时, 问题优先级可让团队专注于真正重要的事情, 通过减少不必要的认知挑战(如信息过载, 分析瘫痪和决策疲劳)来节省时间和资源。
  2. 相连的端到端工作流程使解决方案与可用性测试输出保持更加一致(因为问题和解决方案是配对的), 从而降低了实施非最佳解决方案的风险;
  3. 我们可以使用在线工具轻松地协作(部分或全部)应用此方法。
了解这种方法的局限性很重要。例如, 在优先级划分阶段, 不包括测试中观察到的用户的积极态度和行为。重点是可用性问题。一个建议是分别记录此类数据, 并在需要时一路使用它来补充和平衡发现。
最后, 除了可用性测试之外, 这种方法还可以扩展到其他UX研究技术。应用” 双钻石” 方法(问题/解决方案相互融合/融合), 我们可以混合使用各种用户研究数据, 并在其他任何项目中使用上述方法。你的想象力是极限!
【将可用性测试数据变成行动而不会发疯】? ? ?
在srcmini设计博客上进一步阅读:
  • 电子商务UX –最佳做法概述(带有信息图)
  • 以人为本的设计在产品设计中的重要性
  • 最佳UX设计器产品组合–启发性的案例研究和示例
  • 移动接口的启发式原理
  • 预期设计:如何创建神奇的用户体验

    推荐阅读