【aepp技术周报】可用性测试


#1

在æternity,我们会测试所有关键用户界面,并根据不同区块链技术经验水平的用户期望进行设计。

您-用户体验在我们的设计过程中至关重要!

可用性测试过程

那么我们如何确保创建最直观的用户体验?我们的方法包括确认用户可能正在努力适应区块链上运行的应用程序的复杂性并改善其体验的所有领域。我们按照下面列出的流程执行此操作。

​准备工作

首先,我们确定了我们想要测试/改进的用户路径。然后我们准备一个包含这些路径的脚本。在脚本中,我们必须将路径表达为用户故事。在我们包含了我们想要在脚本中测试的所有用户故事之后,我们使用它们来创建原型。

选择测试人员

根据æpp和我们正在测试的æpp的功能,我们会寻找我们想要测试的适当受众。如前所述,我们希望涵盖各级经验和不同人口统计数据的受众群体。例如,在测试我们的代币迁移Web应用程序时,我们对以下用户感兴趣:

  • æternity代币持有人
  • 遍布全球的用户
  • 不是超级区块链先驱者用户,因为我们希望确保迁移界面对于不同区块链技术熟悉水平的体验都是直观的。

通常,我们总是可以选择亲自或模拟进行用户测试。但在上面的示例中,在全球范围内寻找测试人员并进行模拟测试将会更有意义。

在会议期间

会话总是通过屏幕和录音实时完成。在每次会议期间,来自æternity的主持人要求测试人员浏览脚本中的用户故事,收集有关这些路径的摩擦或平滑体验反馈。此外,我们也收集用户提供的一般或自由形式反馈。

分析数据输入

在完成所有会话之后,我们会提取会话期间收到的反馈。

我们会根据用户遇到的障碍的严重程度来确定所有输入点的优先级顺序。

例如,如果用户故事包括用户从æpp的一个部分导航,那么让我们假设Bаse æpp中的账户管理者,另一个是æpps浏览器,并且由于某种原因他们没有意识到在哪里打开æpps浏览器,我们认为这是一个相当严重的障碍,因为它阻止他们完成用户故事概述的任务(在这种情况下从账户管理者切换到æpps浏览器功能)。

一旦我们有了一份我们想要处理的项目清单,我们就把它们变成了具体的任务。我们通过返回用户故事来说明“作为用户我希望能够因为Y、Z的原因而实现X”,并确定为用户提出的任务提供不同解决方案。

周期类型

我们根据用户在测试期间遇到的障碍/摩擦的严重程度选择不同的迭代类型。例如,如果用户无法完成基本路径,并且我们需要从脚本中为故事提出新的解决方案,那么创建新原型并从中获取用户反馈是有意义的(箭头#2:原型 =>反馈,在上图中)。

然而,如果我们不是从根本上改变我们的方法,比如说我们正在重新设计一个图标,一些用户容易理解、而其他用户难以理解,当我们需要测试更多基本的障碍时(箭头#1:设计=>反馈),我们可能只是决定要求内部重新设计反馈并在之后一段时间进行用户图标测试。在某些情况下,我们只需要进行小的改进(例如文本更改,添加说明)。如果是这种情况,我们可以调整我们的设计,然后直接实施设计并准备发布(箭头#3:设计 =>实施 =>发布)。

迭代、迭代、迭代

我们使用高度迭代的流程,其中心是用户 - 对我们来说,用户体验直观和无缝的æpps是最重要的,这使他们能够完成他们感兴趣的任务。根据我们的æpp和æpp功能我们我们正在努力,我们可能会在上面说明的循环中经历多次迭代/重复,直到我们达到我们想要发布的设计和构建的版本。此外,在每个sprint结束时,我们会向我们的æpps提供设计更新,并在内部获得反馈。

用户测试的价值

您和用户提供的观察结果将非常宝贵。

我们非常关注提供无摩擦的用户体验,我们在可用性测试会议期间收集的回馈极大地影响了我们的用户体验设计决策。

结论

我们希望通过对可用性测试过程的深入了解,读者可以了解设计和测试周期的重要性和内部工作原理。如果您对此有任何疑问或意见,请随时在论坛的æpps类别中询问。