可用性测试介绍.doc

可用性测试1 - 究竟几名参试者才够？2006-08-30 15:40:29来源: UPA中国 网友评论 1 条 进入论坛“需要几名参试者”，相信凡是做过可用性测试的人来说都会遇到这个问题。由于出发点不同，团队中的不同人员，例如产品经理，项目经理，可用性工程师，技术开发人员等在这个问题上会有不同的看法。面对这样的讨论，不少从业者感觉自己是对的，要说服对方时却又没有把握、缺乏底气。这篇文章的目的就在于尝试帮助理清可用性测试的几个基本问题，以便“几个用户”类似问题的解决，更加灵活地运用可用性测试方法。可用性测试的属性 可用性测试是要发现问题可用性测试，故名思议是评估（测试）设计方案或者产品的可用性水平。目前最常用的评估可用性水平的指标有：用户在没有帮助的情况下完成任务的比例，完成任务所用的时间，用户寻求帮助的次数等等。这些指标对于描述可用性水平有益处，但却不是重点。可用性测试的更重要的成果是从可用性工程学的角度来支持这些数据，也就是发现并指出产品或者设计方案中存在的可用性问题当然也包含优点。可以说在大多的项目中，特别是在迭代反复的产品开发流程中，可用性测试的根本目的是发现问题并解决它，从而提高产品的可用性水平。从Nielson的这张“经典”的用户与发现可用性问题数量关系的图表中，你可以得到这样的体会：“5名用户的测试可以发现85%的可用性问题”请暂时忽略这里的具体数据，而关注并且记住这句话的主干：“测试发现问题”。可用性测试是定性研究绝大多数的可用性测试都是定性研究而不是定量研究。熟悉统计学的人都清楚，定量研究需要相当大的样本量才能达到一定的信度和效度。根据Nielson最近的一篇文章，要做定量的可用性测试研究，每个用户类型至少需要有20名用户 。这对于一般的测试项目来说成本太大以致无法承受。虽然有部分定量的可用性研究，但就我们目前所从事的大多可用性测试来说都是定性研究。也就是说绝大多数情况下，我们得到的只是描述性的结论，而那些尝试将测试结果推论到整个用户群体的想法都是不切实际的，徒劳的， 错误的。可用性测试不是万能的可用性测试是找可用性问题的方法，所以可用性测试非常适合于发现设计方案、产品中存在哪些可用性问题，并帮助解决它。这个优点，特别对于迭代式的产品开发流程来说，非常有效，经过测试改进再测试的几个周期，可以显著地提高产品的可用性水平。但是，如果你的项目经理希望通过这个测试来了解这个产品有多好，上市后有多少人会喜欢或者喜欢那个特殊设计点，或者有将来有多少比例的用户能顺利完成某个操作？不，请明确告诉他，这不是可用性测试能做的。记住，可用性测试是定性研究，定性研究的样本量得出来的结论不具备推论的效度。可用性测试中确实会有一些比例数据，但这个比例只能作为参考。究竟几个人合适？ 我的时间少，资源有限，三个人可以吗？面临时间短，资源有限，用户难找等问题，是可用性从业者普遍面临的问题。手头的资源仅够测试三个人，还值得去做吗？遇到这样问题的时候，我们往往会迟疑。回想前面提到的，可用性测试是要发现问题，解决问题。测试三个人能实现这个目的吗？当然可以！问题已经有答案了。是的，由于可用性测试是定性研究，而且就发现问题这个角度来说，三个人的测试和六个、八个的测试仅仅是发现问题数量上的差异。我们不仅赞成，而且非常鼓励这样规模小，周期短的测试。客户要求做十五个测试，有必要吗？国内外诸多经验，包括笔者两年多的工作经验中也体会到，在测试完5个用户之后，发现重要的可用性问题的几率，也就说测试的效率已经比较低。继续做更多的测试，最多情况是看更多的用户在同样的位置出现同样的错误。由于继续做测试的产出与投入的比例比较低，我们并不推荐这样做。有的人希望多测试几个人，希望了解有多少比例的用户会遇到特定的情况。对于这种需求，我们只能不胜其烦地解释：可用性测试作为定性研究，不能得出这样的推论。另外还有个很重要的问题需要考虑：发现四个人出现同样的问题后，真的有必要知道多少比例的人会出现这个问题？问题已经在那，你需要做的是想办法解决这个问题，而不是统计有多少人犯了这个错！另外可能有人说，我们希望找到尽可能多的，甚至所有的可用性问题。首先，从投入和产出的比例来说，这是非常昂贵而不聪明的做法；另外很遗憾的说，你不可能在一轮的测试中发现所有的问题。问题存在一定的情境当中，而不是孤立、凭空地存在，有的问题会“埋藏”在另一些问题的下面。例如说，任务3必须要在用户完成任务1之后才能做，但用户未能顺利完成任务1，此时要么在主持人指导下完成任务1而进入任务3，或者直接跳过任务3。而这两种方式都会影响任务3的真实情况，而错过它存在的问题。所以，要发现任务3存在的问题，就必须先解决任务1中存在的问题。推荐的做法 尽早开展测试，不要担心测试的人数太少而放弃宝贵的机会。记住，你要做的是发现最重要的可用性问题并且解决它，测试三个人可以发现可用性问题吗？可以，那就去做吧，你会有意想不到的收获。客户领导要求做大数量的测试？如果明确测试的目的是要发现产品中存在的问题，而不是要进行定量分析，那么你应该说服他们采取少人多轮的方式来进行，这样的做法最经济而且效果最好。公司要保持竞争力，必须让产品更易于使用，但经理们可能不会因此就雇用人因学或可用性测试方面的专家，因为他们看不到其中的价值，那么你怎么办？ 你可以主动出击，实施一个可用性测试使这些心存疑虑的家伙们信服。即使你没有心理学、人因学的背景或者缺乏测试经验，哪怕没有足够的预算甚至没有实验室，都没有关系。遵循以下的基本方法，不需要投入太多也可以完成一次象样的可用性测试。 成功的可用性测试，有十步： 1）做好准备工作； 2）制定测试计划； 3）设计测试过程； 4）安排测试地点和设备； 5）进行预测试； 6）招募用户； 7）准备测试房间； 8）测试； 9）数据整理和分析； 10）付诸行动。 1.做好准备工作 这里的信息并不是经验和培训的替代品，但可能会对你有一些帮助，让你成为一个可以胜任的测试人员。第一步就是武装自己，有很多可以利用的资源： 书籍和文章 学校的书店和图书馆，包括一些专业的期刊，它们是书籍和文章的最好来源。至少，你需要一个统计方面的介绍性材料、与测试有关的资料和人因学/人机界面设计的书。 研讨会 过去的五年中，关于可用性测试的文章种类越来越多。在可以寻求帮助的四种方法中，这个通常是最薄弱的，因为大部分的研讨会是理论性的。你需要的是约10%的“为什么”和90%的“怎样做”，而研讨会常常不是这样的。另外，参加研讨会往往费用较高。 咨询 咨询可能比研讨会来得合算，但是也有可能得不偿失。最有名气的公司可能并不适合你。例如，请一位在大学里面的人因学专家来做顾问，她会评估整个的测试过程，对记录测试数据的方式提出很多有效的建议，在预测试中指派一名研究生一起来控制整个过程，整个下来花费不多。 大学和学院 大学里提供了两样东西，课堂和教授。回到学校可能是你最不想做的一件事，但从一个人那里学习统计比从书本自学要容易得多。如果你的公司不需要你得到纸面文凭，那么你就可以旁听，可以通过也可以不及格。 可以直接与心理学和计算机科学的教授谈论与可用性测试相关的课程（统计学、测试、人因学、人机界面设计）。如果你愿意也可以参与一个与可用性测试有关的硕士生项目。 就像请顾问一样，教授的建议同样是丰富的资源。例如，你可以设计一个测试项目作为课程作业，教授就会帮助你并且可以减少花费。 2. 制定测试计划 对可用性测试有所了解之后，下一步就是写测试计划。描述可用性测试的目的，以及如何来完成，这很重要，原因如下：一是从管理者或其他人那里得到你所需要的支持；一个是使你的思路和目标变得清晰。测试计划中要包括： 为什么要测试 对管理层陈述需要花费时间和金钱的理由。例如：如果用户使用简版的手册，可以达到与现在使用的大部头手册同样的效果，我们就会减少打印手册的费用，如果效果更好的话，我们就可以减少客户服务中心的线路数量。 如何测试 谁主持，测试内容是什么，测谁，几名用户，如何分组等。 测试的花费 咨询费、招聘用户、用户报酬、录音、录像、租场地、印刷等费用。 测试的时间安排 时间表包括：定义你的测试，设计测试，安排测试地点和设备，招聘，测试和分析结果。 测试会持续多长时间 写一个时间表，包括：定义你要测试的任务，设计测试本身，安排测试地点和设备，招募用户，测试，分析结果。 3.设计过程 定义用户群 你的测试用户必须能够代表用户群。考虑的人口统计学特征有：教育水平、使用经验水平、工作类型、年龄、性别、种族、身体条件等。 定义想测试的内容 没错。但还是要确保绝对清楚哪些要测和哪些不测。内容越详尽，得到有效测试的机会就越大。还要定义如何度量测试得到的数据，如完成时间和成功完成的任务数。 写任务 考虑组成一个包括多个部门代表的小组来选择任务，例如客户支持部门可能会对关键任务有不同的看法。 任务应该是有意义的，以一定的逻辑顺序展现给用户，同时还要控制每个任务的完成时间，不能让用户把所有的时间都花费在一个任务上。 在每一页纸上写下一个任务。任务的指令要明确但不能有提示如何完成任务。 为测试人员写脚本 以同样的方式问候用户，以同样的方式解释测试，以同样的方式回答问题，以同样的方式进行提示等等。为了做到这点，需要为测试者制定执行的脚本。 准备记录表格 即使录像，也要在当时记录用户的行为。如果有一个记录表格，记录就会变得容易。可以有一个和用户任务相符的表格来记录用户行为和你的理解。第二种表格可以是菜单结构图，用来记录用户试图完成任务时的动作顺序。另外需要记录的是每个任务的完成时间，在哪些地方使用了帮助，在哪些地方参考了用户手册 4.安排测试地点和设备 可以在用户的地方或在自己的实验室里进行测试，也可以是一个更中立的地方。 在用户的地方有一个好处就是用户会因为熟悉周围的环境而感到放松。缺点包括：不可控制的中断；在路程上花费很多时间；调试你的设备等。 在自己的实验室进行测试应该是方便的，但是对用户来说不太方便，他们在一个陌生的环境里面可能会比较紧张。 在中立的地点进行测试的缺点与在你自己的地方测试是一样的。对你来说它也可能不方便（尤其是如果需要运送设备的话）。中立的测试地点可能即昂贵又难于安排。 对我们来说，采用一个现场的会议室最好。如果你使用你的一个房间，要找一个靠近出口也靠近休息间的房间。房间要整洁，吸引人，舒适（确信要在门上挂上“测试进行中请勿打扰”）。 5.进行预测试 无论你自己重复多少次测试过程，你都不会对一个测试需要多长时间有准确的估计，只有用一个新手用户进行预测试，你才能知道一些小的细节。这个人不需要与测试用户具备相同的特征，但他/她应该是产品的新手用户。 6.招募用户 如果比较早地招募了用户，他们就可能到时改变主意或者遗忘，所以不要在提前一周以上招募用户并确保在前一天给他打电话确认。把完整的测试地点的方位，包括地图用邮件或传真的方式发给他们。 因为你占用了用户的时间，并且你要确保他们出席，就要支付他们报酬-现金。在测试之前告诉人们测试需要多长时间和需要对整个过程录音，录像。 标准 定义你需要的用户的经验、技能、教育程度、工作类型和其它的统计资料。然后准备一个访谈脚本来筛选潜在的用户。大学生不会计较，很容易找到他们，费用也比较少，但如果他们不能真正代表你们用户特征的话，就不要管他们了。 自己来做 不要招募朋友，家人或者同事。要做专业的招募工作：在国家字典、商务期刊和黄页里面找到一些公司（公开的图书馆里可能也会有这些）。你应该一个在你建立的标准里面有不同业务的混合。 这有一个脚本的例子让你通过回答电话筛选用户。“你好，我是简，是真大公司的，是大镇的一个计算机生产商。我们正在设计某个新的PC产品。我想与您公司里面用电脑工作的人谈一谈，有哪些人呢，他们的职位和名字是什么呢？” 当你得到这些人的资料的时候，他们是否合格是基于筛选脚本的。例如，我们想要有PC经验的人，曾经使用过传真机。我们也想要多方面的人员职员类型的，管理的、技术的和专业人员类型的，所以我们要为此制定筛选脚本。 如果一个人可以满足你的这些标准，就可以邀请他们来参加这个研究。告诉他们需要多长时间，在哪测试，你会给他们多少报酬，你会对整个过程进行录像。如果所有这些条件被接受了，就可以安排时间了。要确保在两场测试之间有足够的时间来调试设备。 给招募者支付一定的费用 如果你的预算足够用，你可以雇佣一个招募者来招募用户。为我们的焦点小组来招募用户的费用是15个用户，478.14美元。这个费用包括：他们来制定筛选脚本（我们要检查和核实），筛选用户，安排时间，发出指引和确认信，并且在约定好的前一天给用户打电话。相信我，花这些钱是很值的。 7. 准备测试房间 如果你在测试前一天建立了测试间，你就有时间来改正操作时出现的问题。在任何情况下，要在每一次测试开始之前至少有半个小时的时间来保证测试已经准备好了。当可以挣到相当数量的钱时，人们通常会早些到。 8. 测试 用户在心理和身体上的适应会影响测试结果，并且你的所作所为直接影响到他们镇静和配合或者紧张和敌意。 问候用户 在用户刚进来的时候就以友好的口气与用户交流，如果他们提前到了就为他们提供一个合适的地方来休息等待。如果用户太热或太冷的时候可以调节测试间温度，这些会很有帮助。 给用户大致介绍并得到许可 你在引导可用性测试，不是心理学测试，所以告诉用户你的目的是什么，他们要做什么，为什么你要进行录音或录像。强调你测试的是产品，不是用户；他们所反映的是关于产品的问题，不是他们的问题。 因为你想知道的是为什么用户做某件事，不只是要让他们做，还要鼓励他们在完成任务时大声说出想法。鼓励他们在完成一个像安装一个订书器这样的简单任务时，通过描述行为来说明他的想法（用户经常在测试过程中慢慢地就沉默了，可以轻轻地提示他们“你在想什么？”而不要说“你为什么这样做？”） 然后让他们签订一个同意表（知情书）。知情书可能会包含上面所有的信息，你可以对用户大声地读，最后一段应该包含类似于这样的信息：“帮助我们评估结果，我们将要对整个过程进行录像，作为我们整理数据的备份之用，所有的录像不会用于商业目的，只是作为帮助我们分析结果之用。” 执行测试 把写好的任务交给用户（一个任务一页），邀请他/她完成你大声读出来的任务。 你不能总是在用户完成任务的时候告诉他，有时他们并不确定他们已经完成了任务，会继续做下去（或者在还没有完成任务时认为他们已经完成了）。这个信息是有价值的，因为这告诉你界面缺乏足够的反馈。你也想要用户回到一个自然的开始状态，所以他们要在软件的同一个地方开始下一个任务。所以可以在每个任务中包括一些类似于“在完成任务时说出来，并回到主菜单”的描述。 让用户自己来说出自己的想法，但当他们遇到困难时，可以提示他们。因为你不想他们因此沮丧，而在完成后面的任务时受到消极的影响。在测试脚本中也要使用提示。 即使你要掌握测试的时间，也不要让时间成为问题并且不要告诉用户有时间限制。当他们已经达到测试时间时，要提示他们结束这个任务（如果他们实在不能完成，清楚地告诉他们如何回到开始的地方），进行下一个任务。 如果你有一个大房间，或者会有一或两个测试人员在单面镜后面，考虑让两个或更多的测试人员/观察人员来参加。如果两个人能记录不同的内容就会容易些。例如，一个人可以记录用户选择的菜单项的顺序，哪些地方及什么时候使用“帮助”，另外一个人可以记录完成单个任务的时间，测试者给予的提示和任务是否成功完成了。如果多个测试人员会增加用户紧张感的话，可以让一个观察人员在测试后花费额外的时间来回顾录像。 用户总结性的描述 测试后，你可以询问用户对产品的印象，他们在哪些地方会感到困惑，有哪些可以使产品更容易使用的建议，等等。 9. 数据整理和分析 在测试过程中你不可能记录所有的事情，即使你有两份记录。这就是为什么要对测试进行录像的原因，就是为了再次观看录像（可能要一遍又一遍的看）直到你获取了所有需要的信息。 下一个步骤就是分析结果：计算完成每个任务和完成每个测试的平均时间，每个用户使用帮助或参考手册的次数，提示的次数，任务是否成功完成对你来说都是重要的信息。 所以，你已经得到了所有这些信息，应该可以支持你的假设。但是在你得到结论之前，要使用统计方法分析数据。如果你没有统计的背景，可买本统计学的书学习一下或者找一个专家来帮忙。 在没有进行统计分析时，说两组测试结果之间存在很大的差异是没有意义的。不仅得出的显著度结果和提出的建议是不可靠的，而且如果测试结果不支持一般的用户群体的特征，你和可用性测试都意味着失去了可信度。 一种比较廉价的获取帮助的方式是与一位教授一起组成团队。他会给你一些关于适合你的数据的统计方法或帮助你完成这些统计测试结果。 10.付诸行动 无论测试结果支持你的假设与否，你都可以从中获得经验，提出建议或实现计划。 例如，我们了解到，在两个测试组之间没有显著地差异，在线帮助没起到作用，因为它没有导航。通过这样的信息，我们就可以用最精简的手册（减少印刷费用）来重新设置标准手册，重新编辑帮助界面。 然而，从测试中得到的最大的利益就是它的长期影响。对于决策者来说，尤其是在一个工程的环境下，他们对数据是印象深刻的。另外一种非常有效的表现用户使用软件存在的问题的办法是展示用户测试中最让用户困惑的一段短的视频（美国有最搞笑的可用性测试录像）。因为已经了解了可用性测试的价值，许多地方已经有了安装了单面镜的测试实验室，许多项目负责人已经开始了在产品交付之前的测试工作。国际标准ISO/IEC 9126-1将可用性定义为“在特定使用情景下，软件产品能够被用户理解、学习、使用、能够吸引用户的能力” 【ISO/IEC 9126-1. Software engineering Product quality Part 1: Quality modelS. International Standards Organization,2001.】。 ISO/IEC 9126-1阐述了在产品开发过程中软件质量的六个方面（见下图），依次为功能性（functionality）、可靠性（reliability）、可用性（usability）、有效性（efficiency）、维护性（maintainability）、移植性（portability）。ISO/IEC 9126-1将“使用质量（Quality in use）”作为广义的目标：满足目标用户和支持用户的使用质量，功能性、可靠性、有效性和可用性决定着目标用户在特定情景中的使用质量，支持用户则关心维护性和移植性方面的质量。目前ISO/IEC 9126-1有两个作用，首先是作为具体软件设计活动的一部分（可用性定义），其次是提供软件满足用户需求的最终目标。 国际标准ISO 9241-11将可用性定义为“特定的用户在特定的使用情景下，有效、有效率、满意的使用产品达到特定的目标”【ISO9241-11. Ergonomic requirements for office work with visual display terminals (VDTs) Part 11: Guidance on usabilityS. International Standards Organization,1998.】。ISO 9241-11将可用性概括为三方面：有效性（effectiveness），用户使用系统完成各种任务所达到的精度（accuracy）和完整性（completeness）；效率（efficiency），用户按照精度和完整度完成任务所耗费的资源，资源包括智力、体力、时间、材料或经济资源；满意度（satisfaction），用户使用该系统的主观反应，描述了使用产品的舒适度和认可程度。 Nielsen（1994）认为实用性（utility）和可用性（usability）构成了系统能否用来达到特定目标的因素，称为有用性（usefulness）【Nielsen J可用性工程M刘正捷等译北京：机械工业出版社，2004：16-24】。可用性定义为“用户能否很好地使用系统的功能”，分为五个因素：可学习性（learnability），用户可以在短时间内使用系统完成相关任务；效率（efficiency），用户学会使用系统后，能够高效率地使用系统；可记忆性（memorability），用户在一段时间没有使用系统后，仍然能够使用系统；出错（errors），用户使用系统时能够少出错，系统必须防止灾难性错误发生；满意度（satisfaction），用户使用系统主观上感到满意。 Shackel（1991）将可用性定义为“按照人的功能特性，系统很容易、有效地被特定用户群使用，经过特定培训和用户支持，在特定的环境情景中，完成特定范围的任务”，并将可用性分为四个因素：有效性（effectiveness）、可学性（learnability）、灵活性（flexibility）、态度（attitude）。 编辑本段测试的方法所谓可用性评估，即是对软件“可用性”进行评估，检验其是否达到可用性标准。目前的可用性评估方法超过20种，按照参与可用性评估的人员划分，可以分为专家评估和用户评估；按照评估所处于的软件开发阶段，可以将可用性评估划分为形成性评估和总结性评估。形成性评估是指在软件开发或改进过程中，请用户对产品或原型进行测试，通过测试后收集的数据来改进产品或设计直至达到所要求的可用性目标。形成性评估的目标是发现尽可能多的可用性问题，通过修复可用性问题实现软件可用性的提高，总结性评估的目的是横向评估多个版本或者多个产品，输出评估数据进行对比。 编辑本段评估方法认知预演（Cognitive Walkthroughs）是由Wharton等（1990）提出的，该方法首先要定义目标用户、代表性的测试任务、每个任务正确的行动顺序、用户界面，然后进行行动预演并不断地提出问题，包括用户能否建立达到任务目的，用户能否获得有效的行动计划，用户能否采用适当的操作步骤，用户能否根据系统的反馈信息评价是否完成任务，最后进行评论，诸如要达到什么效果，某个行动是否有效，某个行动是否恰当，某个状况是否良好。该方法优点在于能够使用任何低保真原型，包括纸原型。该方法缺点在于：评价人不是真实的用户，不能很好地代表用户。 启发式评估（Heuristic Evaluation）由Nielsen和Molich（1990）提出，由多位评价人（通常4至6人）根据可用性原则反复浏览系统各个界面，独立评估系统，允许各位评价人在独立完成评估之后讨论各自的发现，共同找出可用性问题。该方法的优点在于专家决断比较快、使用资源少，能够提供综合评价，评价机动性好，但是也存在不足之处：一是会受到专家的主观影响，二是没有规定任务，会造成专家评估的不一致，三是评价后期阶段由于评价人的原因造成信度降低，四是专家评估与用户的期待存在差距，所发现的问题仅能代表专家的意思。 用户测试法（User Test）就是让用户真正地使用软件系统，由实验人员对实验过程进行观察、记录和测量。这种方法可以准确地反馈用户的使用表现、反映用户的需求，是一种非常有效的方法。用户测试可分为实验室测试和现场测试。实验室测试是在可用性测试实验室里进行的，而现场测试是由可用性测试人员到用户的实际使用现场进行观察和测试。 用户测试之后评估人员需要汇编和总结测试中获得的数据，例如完成时间的平均值、中间值、范围和标准偏差，用户成功完成任务的百分比，对于单个交互，用户做出各种不同倾向性悬着的直方图表示等。然后对数据进行分析，并根据问题的严重程度和紧急程度排序撰写最终测试报告。 编辑本段注意事项你测试的是产品，而不是使用者对一些用户而言， 测试有负面的涵义。我们要努力确保他们不认为测试是针对他们。我们要让他们明白，他们正在帮助我们测试原型或网站。事实上，我们可以不使用“测试”这个术语。相反，我们是邀请参加者为我们提供帮助， 勇于尝试原型 。 当用户难以完成任务时，我们应该改变网站，而不是改变用户。同时我们还应该思考该网站能在多大程度上符合那些典型用户的的目标，而不是关注用户在这个任务做的多好。 更多地依靠用户的表现，而不是他们的偏好通过测试我们可以测量到用户的表现，以及他们的偏好。用户的表现包括是否成功完成，所用时间，产生的错误等等。偏好包括用户自我报告的满意度和舒适度 。 一些设计人员认为，如果他们的设计能迎合用户的喜好，用户在该网站上就会有良好的表现。但证据并不支持这一点。事实上，用户的表现以及他们对产品的偏好并非一一对应。一项研究发现，约有百分之七十的用户同意表现和喜好有联系。也就是说，他们在喜爱的网站上表现良好，在不喜欢的网站上表现欠佳。 然而，还有相对比较大比例的人（ 30 ）认为 ，用户的表现以及他们对产品的偏好并非一一对应。他们在不喜爱的网站上可能表现良好，在喜欢的网站上也可能表现不佳。 关于人们为什么会对自己表现欠佳的网站给出较高的评价有多种解释。他们可能会把表现不佳归结到自己，而不是网站。或者说，他们可能担心给一个较低的评价会伤害网站设计者，也就是我们的感情。或者说，他们可能并没有完成任务，却自认为成功完成了，他们并没有意识到问题所在。基于所有这些理由，我们建议你：更多地依靠用户的表现，而不是他们的偏好。 把你掌握的测试结果应用起来可用性测试不仅仅是用于核对项目进度的一个里程碑，你要知道，当最后一个参与者完成任务的时候，可用性测试还没有结束。整个团队必须仔细研究结果，设定优先次序，基于结果对或者网站原型进行修改。 基于用户体验，找出问题的最佳解决方法制造任何产品，包括大部分网站和软件，需要考虑许多不同的用户的工作方式、体验、问题以及需要。大多数项目，包括设计或修改网站，都要处理时间、预算和资源等方面的限制。平衡各个方面对大部分项目来说都是一个重大的挑战。 在你权衡利弊时，最好优先开发那些能使最多用户完成任务的网站或软件。有研究表明，产品推出后，用于支持失败客户的花费远远高于开发时对产品修正所付出的花费。 你需要认真考虑假定用户、使用场景以及可用性测试的结果，试图找出针对不同客户需求的理想解决方法。找不到最好的解决方法，用户就不能够顺畅地完成任务。有证据表明，即使用户延长使用时间在一个不太完美的产品界面完成任务，也远不及在一个更好的产品界