企业可用性的成熟：1-4阶段 Corporate Usability Maturity: Stages 1-4

 

 

http://www.useit.com/alertbox/maturity.html 

企业可用性的成熟：1-4阶段 Corporate Usability Maturity: Stages 1-4

Summary:

As their usability approach matures, organizations typically progress through the same sequence of stages, from initial hostility to widespread reliance on user research.

总结：随着可用性实现方法的成熟，企业都经历着发展过程中的相同阶段，从最初的敌视到后来对用户研究的依赖。

 

 

企业可用性的成熟：1-4阶段

总结：随着可用性实现方法的成熟，企业都经历着发展过程中的相同阶段，从最初的敌视到后来对用户研究的依赖。

 

通常，可用性过程的发展和成熟的过程中，企业经历着几个不同的阶段，这些阶段有着普遍性，你可以根据以下描述看看你的企业将要经历一个怎样的阶段。

 

阶段1： 对可用性的敌视

 

用一句话来描述这个阶段，“好的用户是一个死用户。”开发人员不想听到任何有关用户或用户需求的消息。他们的唯一目标就是建立一些功能，并让它们在计算机上工作。在这里，人是无关的东西——有人告诉他们怎样去使用系统，至于操作是否简单易行就不管了。

 

在早些时候（1945—1965），这个方法对于大多说项目来说是成本最低的办法。当时硬件价格很高，因此让人来适应电脑是合理的。

 

大约到1965年，电脑开始变得越来越便宜，很多人开始使用它们。我们开始看到了减少培训成本增加用户生产力带来的经济回报。可用性开始在一些采用它的少数企业中显示出客观的投资回报率，但是在19世纪80年代以前，大多数IT商店对可用性还是采取敌视的态度。

 

即使今天，还有一些网页设计者忽视用户、抑制用户的需要，想把网络变成一种和电视一样的东西。

 

如果你的公司是处在这个阶段，那别想着宣传可用性了。一旦公司因为自己的固执而受到损失，管理人员就会考虑到可用性，并进入到下一个阶段。

 

 

阶段2： 以开发人员为中心的可用性

 

大多数公司迟早都会意识到简化设计的价值。在这个时候，最明显（但也是最不好）的办法就是让设计团队依靠他们自己的直觉来判断什么是好的可用性。

毕竟设计人员也是人，他们也使用电脑和网页，他们当然知道某个东西好用或不好用。现有的设计人员还能提供一个好处：那便是他们已经入职并参加了各个项目会议，在项目会议上他们勇于贡献自己的设计意见。

 

这个办法对于一类设计问题来说很有用：开发人员和其它技术人员所使用的开发工具，比如网站服务器。开源项目例如Perl, Linux,和Apache在以开发人员为中心的设计上取得了巨大的成功。但如果能从设计团队以外的人那里获得更加系统的可用性输入，那这些项目将会做得更好。

 

在Apache工作的程序设计师对它的了解一定比使用它而非攻击它的技术专家更深。

 

对那些针对非专业群体的项目来说，依赖设计团队对建议设计的理解必然是很早的。参与了项目的人了解太多，不能代表真正的用户。

 

幸运的是，一个设计团队的认知模式与普通用户的认知模式之间的差异是很容易解释的。这对设计团队的队员来说也是简单的，因为你的意思就是他们懂的太多了，不能代表普通的用户。

 

在第二阶段，你有一个很大的优势：那就是人们开始关心可用性了。你有可能从高级管理人员的嘴里听到“好的用户体验很重要”，尽管实际上它们并没有做多少实质的工作。所以，即使你不能直接从第二阶段过渡到一个精密的可用性进程，你也会发现人们已经接受了可用性逻辑。这些人会表现出向下一个阶段移动的意象——只要你在努力一点。

 

阶段3：粗糙的可用性

在这个阶段，企业意识到它不应该依赖设计团队个人对简便设计的判断。但是，大多数设计决定会继续依赖于它们的判断，因为人们往往认为它们是原型，它们是世界的中心。因此，即使设计团队知道他们应该得到外部数据，但也不想努力去获得。

 

尽管在这个阶段有这么多障碍，公司内的一些队伍还是会做出一些小范围的努力。也许某个人会请来少量用户来做简单的用户测试。或经理聘请一个外部的可用性专家来为公司进行前所未有的独立的用户体验质量的评估。

 

这个阶段与更高阶段的区别主要在于官方没有对可用性给予认可，也没有提前拨出相关的预算。所有的可用性活动都是临时的，都是因为需要一些数据来改善某个东西的质量。

 

尽管原始，这种可用性还是有效果的。小的可用性努力不能起到很大作用但能够在一个从没有在可用性方面努力过的公司内做出大的用户体验改进。

 

从第二阶段向第三阶段迈进的时候，你可以依靠逻辑——甚至是奉承——让设计团队的成员相信他们知道的东西太多根本不能代表普通用户。这个阶段以后，你就要看结果了。

 

如果能有限地进行可用性方面的考虑，他们就能变得更好——这个结果大家都知道。唯一的缺点就是真正好的可用性很明显，管理人员有可能意识不到简化设计需要付出多少努力。为了避免被忽略，请先保存出事的设计想法，它们有可能看起来不那么完善，但是能够用来作对来显示出在可用性方面的进步。

 

 

 

 

第四阶段 专项可用性预算

某经理在名目繁多的基金中抽出一点投入到可用性改进之中，也许他投入得更多一点，他会晋升到董事的主管的位置。也许一个来头不小的副总统决定在产品质量的可用性上投入更多。几个情景能让公司在可用性上投入更多。通常，主要的原因是三阶段不引人注意，特别的可用性项目吸引了上层的注意，使他们相信公司将会从更好的用户体验中获利。

第三阶段和第四阶段的差异在于是否为可用性设立了专门的预算。无论数目大小，预算要提前拨出，这意味这可用性已经和其它质量过程一样事先计划好了。

由于公司的大小不同，可用性预算可能只需要一个雇员的工作量，也有可能需要几个可用性专家的全职劳动量。无论哪一种情况，可用性人员都分布在整个公司内，不具备系统的流程。但至少他们将可用性列入了工作描述中，并为用户测试准备了一定的预算开支（每位用户平均需花费171美元。）

在这个阶段，公司主要将可用性视为一种洒在用户界面上能让其光彩照人的神奇药水。主要的可用性方法是用户测试，用户测试通常在开发流程的后期进行，至少要在用户界面已经部分实施好以后。

这与推荐的最好的办法相反，推荐的办法要求频繁且较早的测试，包括团队使用省去大规模设计实施花费的纸上模型。所作的用户界面实施的工作越多，管理人员就越不愿意做出改进，因为这些改进工作通常都是在设计对真正的用户开放以后才进行的。

想要从第四阶段继续往上走，需要更多的投资回报率。从第三阶段到第四阶段，很容易得到让人信服的结果：一旦在一个项目中做了一点可用性的工作，作用就很明显。有那些小基金的支持，取得这些进步很容易。

设立真正的预算以后，只有更大的改进才能与增长的可用性投资匹配。因为可用性方法有着惊人的高投资回报率，会有大的改进，只是需要一些时间。你需要更多的成功案例。你需要几个有着更高转换率的产品，更少的问题，更好的内网生产率，对公司来说重要的商业措施。

在可用性项目中收集结果，最终你将有足够的能力将商业案例移向第五个阶段：受到管理的可用性。