通过可用性测试大大改进我客户APP.pdf

通过可用性测试大大改进我客户的A PP 大多数设计师花很多的时间使他们的设计达到他们自己想 的样子。然而最好的方法是收集真实用 户的反馈。通过测试能够找到没有被发现的痛点和流程 ，这些在设计过程中不是很容易被发现的。 最近 ，我有机会在第一时间体验“hello sign”这个应用 ，这个IO S应用可以让用户通过智能手机内置的 摄像机扫面文档、签字并通过把他们发送出去。通过测试发现问题 ，以及之后的改进设计 ，使这个 应用从4星变成了满分5星。接下来我们将头到尾说一下这个应用最初的样子、我们如何进行的测试 以及最后如何使丫变成满分的。 最初的设计 这个应用主 有4个模块 （对于用户来讲应该是“步骤” ）：注册\登录、欢迎、创建文档和编辑文档。 我们做的最大的改变是在登录注册和欢迎页面。我们先简单的看一下这些页面最初的设计 ，以便了 解这个应用是如何工作的~ 登陆注册和欢迎 登陆注册和欢迎是用户在最初体验产品时重 的页面 ，我们想使用户去注册或者——如果他们已经 有了Hello Sign websit e （此应用的网页版 ）的帐号——登录来创建文档。具体到这个应用来讲 ，他 是对网站的补充 ，大多数的用户基本都拥有帐号甚至对于功能的使用比较熟悉。因此 ，作为一个独 立的A PP注册登录环节对于用户来讲应当弱化为可选的操作而非必须的。 原始版本的登录、注册、欢迎页面 创建文档 文档创建流程中最重 的便是拍摄过程 ，通过引导使用户将文档放置在屏幕的拍摄框中。在设计这 个流程的时候 ，我们参考了Ipho ne的原生相机应用和Inst agram的设计 ，以及Schwab的存放检索应 用和Car .io 的信用卡扫描应用的相关页面。 文档编辑 创建完文档后 ，用户会看到编辑页面。在这里他们可以增加签名、文字、检查列表和日期水印。 用户测试 在最初版本登录appst o re后的几个月 ，我有机会来迭代下一个版本。在开始之前 ，我决定做一个用 户测试来了解这个应用最高效的地方以及需 改进的地方。 （下面的一段有点像是在做广告。。。 ） 有很多用户测试的服务可供选择 ，比如Verif y和uTest ，我选择UserTest ing.co m相对性价比较高。 不同的测试服务有各自的优势、特点和各种定制选项 ，应当针对资深的应用特点选择最适合你的目 标和需求的的服务。UserTest ing可以提供一系列的测试 ，通过视频记录用户在操作 配其任务的 每一步。你也可以附加一些补充问题 ，比如 ：“最使你郁闷的操作是哪里 ？”同时UserTest ing.co m为 每一个任务准备了4个非常完备的问题 ，基本能适用所有的测试。 就像Jako bNielsen所讲的 ，没有必 通过大量用户测试来得出结论 ，某些情况下即便是3到5 （这里 应当是目标用户 ，而不是随便的人 ）人就可以满足。由于这个应用是处理传输过程中的文档 ，我们 让用户进行了一个典型的操作流程 ：创建、编辑并发送一个文档。补充的问题是用户使用的难易 程度、比较难用的地方和觉得哪些地方可以改进。 我会观看 （每个用户的操作 ）视频两次 ，第一次只是确认所有的明显的问题和熟悉测试人员拍摄视 频的风格 （习惯、方式 ），第二遍的时候我会非常仔细的记录一些特殊的问题。在测试过程中 ，大 多数的用户不会提出他们遇到的一些问题 （也许是本身没有意识到 ），但是这些问题会通过他们的 行为会表现出来。当用户有下列举止的时候 ，就可以推断用户或许遇到了问题 ： ● 在试图完成一个操作的时候停顿了几秒 ● 被一个操作困扰需 回想之前的操作甚至需 重来一遍 ● 发出沮丧的声音 （一个叹息或牢骚一句 ） ● 完成一个目标的时间大于预期的时间 ● 整个任务无法完成 当然会有其他的反应也表示用户遇到了问题 ，这些事一些比较常见并值得为此来寻找原因的现象。 （分小组 ）测试的越多 ，就会有更多的问题被明确。如果可以的话 ，在每一次迭代开始之前进行测 试是非常有价值的。有的问题可能只会影响到你的一小部分用户 ，但有的就会有很大的影响。根据 你现有的功能列表、想要达到的目标、用户需求来合理的安排时间来优先解决那些影响较大的问题 。不是所有的问题都值得去解决。 设计改进 我们改进设计的目的是明确并解决影响用户的主 问题。之前提到了 ，问题是永远解决不完的 ，资 我们改进设计的目的是明确并解决影响用户的主 问题。之前提到了 ，问题是永远解决不完的 ，资 源与限制为我们圈定了范围。 我们得出了什么 ？ 通过测试发现在登陆注册页面有比较大的问题。多数用户不清楚所在的页面是登录