软件中的易用性设计及测试（二）

先阐释3个名词：UCD,UI,UE

UCD：user-centered design，用户为中心的设计；

UI：user interface，用户界面；

UE：user experience，用户体验

可以看出，只有把用户考虑到设计中来，为改善其用户界面使用户得到好的用户体验，那么该软件产品才能获得很好的易用性。

 

易用性VS功能性

 

要想产品获得用户的认可，必须在功能性和易用性上下功夫，而且他们二者是不可替代的。

 

功能性：

表示软件完成其任务的能力，完成的任务越多，表明该产品功能越强。office软件可以完成很多报表，数据统计等等功能，但是对于一个初次使用电脑的人来说可能需要学习才能上手，可见功能强大，而计算器只是特定的完成计算的功能，很容易使用。

 

易用性：

易用性测试帮助你确定用户能否容易地执行特定的任务。但是，它并不能直接帮助你确定产品本身是否有价值或有功能。

 

这两种特性对于产品被用户接纳都是必要的。二者都是产品“有用”这个整体概念的组成部分。明显地，如果一个程序非常容易使用但却没有什么功能，没有人会有理由去使用它。而如果给用户一个功能非常强大的程序，但却很难使用，那么用户将很可能会抵制它或者寻求其他替代物。 需要做到2者的平衡，也不是件容易事啊。

 

喜欢它Vs 使用它

 

在一个产品中“受人喜欢”总是一个令人想要的特性。如果人们喜欢这个产品，他们更可能会去使用它并推荐给他人。但是你应该小心，不要把“受人喜欢”和“易用性”混淆。

 

人们经常会因为一些跟产品的易用性和功能性无关的理由而喜欢一个产品。他们常常因产品的式样外观或相信产品能赋予他们某种身份而被吸引。人们倾向于喜欢易于使用的产品，但你并不应该因此断定一个受人喜欢的产品是易用的。

 

易用性是关于用户能否使用产品来完成他们需要完成的任务。易用性测试主要衡量产品的性能，而非用户对它的偏爱。但是，可以用标准化的问卷调查测定用户对产品之间的偏爱。

 

发现Vs弄懂Vs 效率

 

易用性有很多方面，但传统上这个词特别是指“发现”、“弄懂”、“效率”等特征。

 

“发现（Discovery）”涉及用户根据需求去查找产品的某项功能（feature）。易用性测试可以测定用户找到某项功能需要花多长时间及用户在查找过程中会犯多少错误（找错位置）。

 

“弄懂（Learning）”涉及这样一个过程，即用户通过这个过程弄懂怎样去使用某项已发现的功能特点去完成手头上的任务。易用性测试可以测定这个过程需要多长时间及用户学会这个特点会犯多少错误。

 

“效率（Efficiency）”涉及一个时候，在此刻用户已经“精通”产品的功能并且不再需要进一步学习便可以使用它。易用性测试可以确定有经验的用户去使用某项功能特点所执行必须的步骤需要多长时间。

　　

手头上任务的性质和用户执行任务的频率强烈影响易用性的这三个基本方面。有些功能很少被使用或者太复杂以至于用户本质上必须每次都重新学习它，对于这些功能，微软经常通过向导（wizard）方式来引导用户。

 

为什么我应该关心？

　　如果你还没有把对易用性的考虑包含进你的产品设计过程中，你也许想知道为什么它是必须的或值得要的。归根结底，根本不进行任何易用性测试工作就可以发布一个可以运行的、没有错误的产品肯定是可能的，但是把“以用户为中心”的设计原则包含到设计过程中，会制造出一个在很多方面都被改进的产品。

　　进行易用性测试的最佳理由是减少用户寻求技术支持服务电话的数量。糟糕的易用性是用户打软件技术支持服务热线的主要原因，每一家软件公司的信息服务经理知道产品支持是多么地昂贵。再者，向用户收取支持服务费用将增加用户对产品潜在的不满意。如果用户觉得很容易使用你们的产品，他们将不需要经常拨大技术支持服务电话。

　　对于为内部使用开发的软件，把易用性作为开发过程中的重要部分的另一个最好理由是可以减少培训费用。一个很易用的产品比一个不重视易用性的产品让用户更加容易学习。用户能更快地学会功能特点，能更长时间地记得他们所学会的，这跟减少培训费用和培训时间直接相关。

　　易用性测试帮助提高用户对产品的认可程度。用户的认同源自于多种因素，包括“易用性”、“功能性”、“喜欢”。对于零售产品，用户的认可经常与重复购买或忠诚度直接相关，这意味着用户很可能向其他人推荐产品。对于内部使用的程序，用户的认可关系到用户是否愿意使用该软件，去完成能帮助提高生产率的任务。增强的易用性是能提高用户认可度的因素之一。

　　易用性能帮助把你的产品和竞争者的产品区分开来。如果两个产品在功能方面几乎是一样的，更易用的产品将可能被认为是更好的。另外，微软的Windows 风格外观和相应的编程规范造就了一致的基本用户界面，所以提供相似功能的很多程序看上去和用起来都很类似。这些相似性意味着，易用性方面的的细小差异可以对用户的偏爱有很大的影响。

　　最后，请记住：每个产品最终都会得到易用性测试。用户每次使用你的产品就是在进行易用性测试，用户通过不断地使用或很少使用产品的行动来给予他们的“裁决”。在产品发布到市场之前测试产品，你可以确保用户对产品的体验将是正面的。

 

它花费多少？
　　软件设计人员和项目经理经常担忧启动以用户为中心的设计过程及进行适当的易用性测试将需要无法接受的的时间和金钱。事实上，聚焦于用户所花费的时间和金钱常常是相对较小的，而且与不聚焦于用户所导致的花费相比肯定是较小的。

　　例如，考虑一下在开发周期的后期对设计进行修改所花费的时间和金钱，与早期进行修改所需的花费（那个时候产品还在绘图板上）之间的对比。如果你等到beta时期才把产品交给用户进行易用性测试，你也许会发现自己忙于把已经花了很多时间所开发的程序分解为多个部分。如果你等到产品实际发布之后，然后根据负面性的反馈才去变更或向糟糕的设计提供技术支持，会因为很高的产品技术支持费用或用户的不满，使得代价非常高。

　　一项合理的易用性研究通常可以在两个星期左右内完成，可大大地减少随后在开发周期中变更所导致的费用。进行测试所涉及的费用随产品的性质和欲进行测试的界面多少而异。

　　你可以把易用性测试与代码测试认为是类似的。成功的项目经理在计划一个开发项目时会觉得代码测试是合理的开销，他们不会把它看做是附加在项目日程计划和预算上的额外东西。项目经理更愿意接受代码测试，把之作为正常的开支之一，因为其他替代方式会将昂贵得多。同样地这也适用于易用性测试。

 

我怎么去得到一些易用性

　　在阅读和理解“易用性”的重要性的时候，软件设计人员有时也被诱惑去“获得一些”易用性，似乎它是一种可以简单地添加，使得一个产品更易用的成份。恰恰相反，易用性应该是设计过程本身的一部分，而不是一种你可以随意添加到过程中的某种东西。易用性专家提到要“聚焦于用户”及“以用户为中心进行设计”的理由是，易用性取决于把用户的需要保持作为设计过程的中心。
以用户为中心进行设计必然地涉及到更多的东西，不仅仅只是遵循一套规定在界面上按钮、菜单如何摆放的规则。易用性测试是一个可以检查你的设计工作的机会，它不是一种把易用性“添加”于你的产品中的途径。
Gould,Boies, 和Lewis (1991)确定了“以用户为中心进行设计”的四个重要原则：
尽早聚焦于客户的需求。设计人员在设计过程的早期就应该专注于理解用户的需要。
完整综合的设计。　设计的各个方面应该平行地进展，而非顺序地进行。　应该保持产品的内部设计和用户界面需求相一致。
较早地并持续不断地测试。　软件设计中目前唯一可行的途径是经验主义式的：只有实际用户认为设计好那么这个设计才是好的。把易用性测试贯穿于整个开发过程，可以让用户在产品发布之前对设计给予一个反馈的机会
反反复复的设计。　大问题经常掩盖小问题。设计人员和开发人员应该通过多轮测试反复修正设计。

 

为什么我们应该让用户参与其中？
　　设计人员应该明白他们他们并不是典型用户。他们比一般的普通用户对他们正在开发的软件熟悉得多。对大多数用户而言不清楚或令人糊涂的界面，对一直在开发这个项目的人员而言却是非常清晰的。有些软件设计人员在某种程度上能理解一般用户的感受，但是并没有什么可以替代物可以代替实际用户对产品的真实交互反应。

　　因此，通过尽早聚焦于典型用户的需要并经常根据用户测试修正设计，软件设计人员能创造出更好的设计，作为结果，那就是更好的产品。

　　更好的设计会得到来自用户更好的认可。对于零售软件，增加的购买所带来的好处是明显的：销量增加了。对于为内部使用所开发的软件，来自用户的认可也是重要的：增加的使用会导致生产率的提高和对技术支持需求的减少。从开发过程的开始就明显地让用户参与其中也向他们表明你对他们的关心和需要是关注的，也因此会增加他们去帮助你们开发更好软件的意愿。

 

为什么我不能仅仅遵循指南？
　　微软已经开发出一套windows平台的界面指导规范以确保windows程序具有一致性的外观。其他公司也开发出针对其他平台的类似指南。象Jakob Nielsen这样的易用性专家已经写了很多关于设计易用的网页方面的文章。有关于这些主题的大量信息可以获得，有时设计人员相信严格地遵循这些指南和标准便是制造出易用的产品所需的全部。

　　关于这种方式存在问题在于指南在本质上就是概括性的。指南必须适用于各种情况，因此并不总是能为你正在设计的特定程序提供了最佳的行动指南。遵循一个写得很好的指南可以帮助你设计出一个一致性的界面，但你不能肯定它就是易用的，除非你让真正的用户对其进行测试。当你使用指南的时候，不要象使用食谱那样去使用它们，不要期待一个指南为你指出可以获得全部最佳结果的道路。两个设计人员可以两种不同的方式实施同一指南，而且两种实施也许都不适合于情况。而且，有时候严格遵循指南会导致一个糟糕的结果，或者导致指南间的冲突。

　　在这些问题真正成为问题之前，只有以用户为中心的设计才能帮助解决这些问题。

　　让我们以另外一种方式来考虑这个问题吧：让“以用户为中心的设计”，而非用户界面指南，成为设计决定的仲裁者。

 

我需要建造一个易用性实验室吗？
　　不要断定易用性测试就意味着一个必需具有一个昂贵的实验室,在其中天花板上架设有摄像机、有one-way mirror(译注：一种可以透视的镜子，在镜子的一测，看上去跟正常的镜子一样，但在另一测却可以看穿镜子的另一面)及其他注意力监控设施等。可以肯定的是，那些需要做很多测试的公司将会发现建造一个专门的实验室会很方便。易用性测试咨询商经常有很多设施和设备提供给他们的顾客，但你可以在各种条件和情况下进行有用的、有效的测试。

　　一种方式是只需简单地找一个精通于人机对话研究和收集数据的测试人员坐在用户后面，观看用户怎样操作任务。这种测试可以在会议室或办公室里很容易地进行。Dumas 和Redish（1999）提供了大量的关于怎样通过观察进行测试方面的信息。

　　当你越来越多地涉及到易用性测试的时候，你可以添加诸如摄像机、one-way镜、或能让你实时观看和记录用户的显示器这样的设备。你不必一次性就添加好所有设备，即使一件件地添置设备也可以帮助你从易用性测试中获取很多价值。

　　另外一种替代方式是，你可以把你的易用性测试外包给易用性测试咨询人员。请看下面的“我怎样开始”了解关于寻找合适的咨询人员的技巧。

 

我怎样开始？
　　一旦你决定把“以用户为中心”的设计原则包含于你的开发过程中，你将需要决定是否需要雇佣易用性测试专家或把易用性测试外包给服务供应商。

易用性专家协会(Usability Professionals Association,UPA)提供了一个服务供应商指南，能帮助你找到易用性测试咨询专家为你进行易用性测试。

　　一些咨询团体也能帮你建立你自己的易用性实验室或开发一个内部使用的易用性程序，以便把易用性原则包含于你的设计过程中。

　　如果你愿意雇佣易用性方面的专家，人机工程协会(Human Factors and Ergonomics Society)提供了能帮助你找到潜在雇员的服务。很多易用性方面的专家也隶属于ACM Special Interest Group on Computer-Human Interaction (SIGCHI)和UPA，你可以在他们的出版物上或会议上放置招聘广告。

　　无论你选择采取那种方式，记住你是在雇佣易用性测试服务，易用性测试专家跟那些进入软件界面并告诉你什么有问题的普通用户是不一样的。设计人员不是典型用户的原则同样适用于易用性测试专家。