易用性测试如何进行可用性测试和用户研究

简述社交游戏的测试内容

游戏的易用性测试是一个相对新的领域，它的侧重点从“该游戏是否能被使用”转变到“该游戏是否能被使用，并是否具有趣味性”，这种转变意味着以前所公认的测试方法不得不重新作出调整，通过提供更有效的游戏评估和强调游戏易用性问题，游戏开发者才能够更好地满足用户的游戏体验需求。

所以，在游戏行业中出现了很多种测试游戏易用性的方法。

但是这些方法却不一定能够适用于社交游戏。

在进行进一步的讨论前，我们先来谈谈社交游戏的定义。

这篇文章中，社交游戏是指在网友之间进行互动的游戏（游戏邦注：例如在Facebook上进行游戏） 社交游戏需要进行恰当的游戏易用性测试的两个原因： 一是比起传统游戏，社交游戏拥有更广的用户群体，这就意味着社交游戏更注重游戏的易用性而不是竞争性。

二是社交游戏没有“市场壁垒”。

因为这种游戏通常都是免费的，所以玩家会有更多的选择。

也就是如果游戏开发者不能够快速吸引玩家，他们将彻底失去这些用户。

这就意味着游戏开发者不得不更加关注于游戏的易懂性和易用性，他们不能只是依赖于以前所学的“游戏知识”，而应该深入思考如何做才能够吸引到更多的游戏玩家

如何进行可用性评估

可用性评估，它的主要目的是为了找出可用性方面的问题，即用户能否很好地使用产品的各项功能。

用户研究是制作原型和可用性评估的基础和前提，只有通过用户研究，设计人员才知道用户对界面的特定需求和使用特点，才能在这些知识的基础上制作原型，同时在对原型评估时，也必须根据用户自身及使用时的特点来对原型的好坏进行判断。

根据在评估过程中是否有用户参与，可用性评估可以分为两大类。

第一类是没有用户参与的评估方法，第二类是用户参与进行评估的方法，为什么会存在没有用户参与的方法呢？以下是两个主要原因： 第一， 用户以及用户的时间都不是免费的、何时想要何时就能得到的一种资源，大部分用户都有自己的工作要做，他们只能抽出很少的时间来帮助你进行可用性评估。

因此，即使是不考虑经济方面的成本，有些时候你仍可能无法找到用户来进行评估。

第二，有时请用户进行评估也并不总是能发现所有问题的，这仍是因为可供测试的用户数量有限，只有很少功能能被评估工作覆盖到。

另一方面，用户的熟练程度也决定了只有特定的问题会被发现。

例如，新手用户进行评估很可能发现产品在易学习性方面的问题，但却不容易发现使用效率方面的问题，而熟练用户的情况则相反，如果由设计人员进行评估，就可以系统地对所有的功能在可用性的所有方面进行评估。

下面我们首先来讨论两种不需要用户参与评估的方法：认知走查和启发式评估。

认知走查（Cognitive Walkthrough） 认知走查法试图想象出人们在第一次使用某个产品时的想法以及所采取的动作，它的大致流程是这样的，你已经有一个原型或对于界面的详细描述，或者就是一个真正的产品。

同时，你知道可能的用户是谁。

此时，你可以选择产品所能支持的某个功能来进行评估。

评估的具体过程就是把用户在完成这个功能时所做的所有动作进述成一个令人可以信服的故事。

为了使得这个故事可信，针对于用户所做的每一个动作，你必须要能够证明，根据用户的知识水平以及界面上的各种信息提示及反馈，用户做出该动作是合情合理的。

认知走查前的准备工作： 需要有一个可供评估的原型或真正产品，或者对于界面使用方法的详细描述，产品的使用手册也可以，这些描述或使用手册越详细越好，因为只有这样才能发现更多的问题。

需要一个对于要完成的任务的描述，这个任务最好是用户在使用产品时的典型任务。

需要有一个用户在完成上述任务时所执行的一系列动作的完整而详细的描述。

有关用户自身生理、心理特点以及他们的知识和经验的描述。

怎样在认知鼠查中发现可用性问题？ 在上述准备工作的基础上，认知走查的核心部分就是对假定的用户所采取的每一个动作进行质疑，看看它的发生是否合乎情理，我们可以从以下四个方面加以考虑： 第一、用户能否想到去做某个动作。

第二、用户能否找到执行某个动作的控件在哪里。

第三、用户能否看出操作控件可以产生他们想要的效果。

第四、在用户执行操作后，界面是否提供了适当的反馈，用户能否较好地理解这些反馈来有效地指导的后续的操作。

如何进行可用性测试和用户研究

可用性测试是一种操作性较强的迭代设计方法。

关于迭代设计，还有一种说法叫“MVP"（Minimum Viable Product，最低可行产品），即快速推出产品，后续不断改进。

这能有效地降低产品研发周期，快速占领市场，快速获得客户反馈。

很多人对设计的误解，认为设计师都是些不食人间烟火，深夜案头苦思冥想闭门几个月最终憋出来一个惊世设计方案，而当灵感枯竭时则颓废懒散无所事事的人， 认为设计依赖于捉摸不定的灵感而无法进行项目时间管控。

这种观点更多地认为设计就是临门一脚的结果。

事实上，假如脱离了中场组织和调整，缺少了必要的控球倒脚，临门一脚往往无果而终。

设计更多是过程，沟通过程。

可用性测试提供了这样一种简单直接的沟通方式。

通过这种方式获得用户反馈，并以此为设计依据迅速调整产品功能乃至产品方向。

如能秉持这种设计即沟通的理念，自然不会将可用性测试仅仅看做是一种无奈之选。

小到一个图标的辨识，页面导航，功能使用，大到某项业务的办理，都可以拿来做可用性测试。

测试对象的选取也没有过多要求，任何不相关的同事，朋友，甚至路人都可以被请来参加你的可用性测试。

除了专业度很高的比如业务处理等，一般性的操作对是否具有真正用户资质的要求并不高。

原因在于，可用性测试最大的作用是发现明显的可用性问题（不要怀疑设计师的水平，有太多设计失败案例是源于看起来简单愚蠢之极的错误），而这些问题多数跟专业无关，只跟常识有关。

具体操作也很简单，无需拘泥于测试地点，准备材料，等等，一张纸一枝笔足够矣。

这里操作关键的点在， 1. 场景代入，2. 观察和倾听。

场景代入是指让被试者知道大概的背景，比如这个软件功能是做什么的，谁会是使用者等，但不告诉具体如何操作（有点小白鼠的意思）。

观察，靠的不仅仅是眼睛，而是心。

只有清楚自己要借助测试得到什么，才能不错过转瞬即逝的细节。

这要求主试者本人对设计有较深的理解。

其他的工作则是为了确保可用性测试顺利进行。

比如前期需要邀请，需要准备任务清单，提问清单，需要记录的设备工具，还有一点小意思。

但真正影响可用性测试质量的只取决于主试者自身的经验和水平。

链接：/question/20418124/answer/25583970 来源：知乎