好了 “菜花 上酸菜”
用户体验设计：多学科的演进之路
作者：J. Mayhew
1. 软件工程的早期简史
本节是60年代到80年代软件工程的简史
60年代到70年代
早期（60年代末），是程序员包打一切的年代。Period
这个时候的软件开发产业根本没有或者没有真正意义的劳动分工。程序员要去进行业务和功能分析，他们要去做项目管理，他们要去做系统架构，他们要去做用户界面设计，他们要编码，还有他们要做软件测试，质量控制和后期的用户支持。某些情况下，他们还要去做销售。
这个时候也没有实际使用中的任何标准或者商业的软件开发学。每个公司的开发项目团队的领导者（同样也是程序员）也是通过他们自身的经验来指导项目。我在1978年开始了我的软件行业的职业生涯。在那个时候，我正在攻读我的博士学位，其研究的内容是认知心理学。我在研究生院里做助理研究员时学到了一些编程技巧，同时暑假在一个软件开发咨询公司里找到一份程序员的工作来支持我能继续完成学业。我本来计划在暑假结束辞掉这个工作，然后全部精力投入到我的学位工作中。但是没想到的是我迷恋上了软件开发这个行业（更不用说还有一份不错的收入），于是我决定继续留下来。我是在咨询公司全职工作的情况下完成了我的博士学位。
80年代
时间回到80年代初，我还记得当公司试图首先推出一套标准的开发方法学时，我所在咨询公司程序员们愤怒的反应（他们正在试图标准化他们公司内部的开发方法学，希望最后能够像产品一样打包销售）。项目经理（当然他们还是程序员）为这个想法感到感到震惊，如果按照这种想法，他们以后就无法按照自己的方式来管理项目。他们抱怨遵循了这一套标准会压抑他们的创造性和创新的能力，也会降低他们工作的积极性。当公司准备开始进一步将项目开发团队的人力资源进一步细分和专业化的时候，开发者也因为同样的原因感到震惊。
早期最先分离出来的角色是“业务分析师”，这个角色不再是程序员，而是业务专家。程序员不再需要去做业务分析。这是从程序员包打一切的工作中分离出来的第一个职责。很快关于客户处理的职责也从程序员的工作中分离出来，处理这个职责的角色是“客户经理”，严格地讲，这也是一个业务角色。很快另一个新的专业角色也出现了——项目经理——该角色同样也不是真正意义的技术角色，他主要是管理角色。程序员又该不满了，因为他们需要被“管理”，同时更多地失去对项目的控制。
角色的专业化还在持续。在80年代中期，系统架构中出现了一种可以将用户界面代码方法从应用逻辑代码分离的技术。这种分离使得应用程序变得更加强大且易于维护。相应，程序员的角色也开始分为“后台工程师”和“前端程序员”——这样进一步的专业化使得从程序员角色里至少移除掉一部分用户界面设计角色，不过该角色仍然是在程序员角色中所控制。关于架构和构建独立界面代码的专业化工具开始出现，相应地在程序员社区一部分人开始致力于研究这些工具。
最终，使这个角色从程序员角色当中消失——是计算机的一个领域的出现——人机交互领域，它出现在70年代后期，它开始全面接掌这个角色。程序员开始不得不听取“用户界面设计师”和“人因”专家的建议，他们都不是专业的软件人员。他们多半有心理学或者人因专业背景。很多但也不是全部的程序员（特别是专注于用户界面工具的这部分人），他们已经习惯并且喜欢用户界面设计，他们也认为自己完全可以胜任该领域，同时他们也不愿意失去对这个领域的控制。早期的可用性专家通常被程序员认为是不受欢迎的闯入者，同样一直不受管理者的理解和支持。在80年代这是一个非常艰难的角色。
2. 软件可用性工程近来简史
下面一节是90年代和二十一世纪初的软件可用性工程发展史。
90年代
90年代初期，在软件开发产业中，角色的专业化和标准的开发方法学变得普遍和被人们接受，特别是来到这个产业的新人，他们没有这种历史上的极为宽泛的角色，他们能够更加自由地管理他们自己和他们的项目。另外一方面，在软件开发团队中，成为一个可用性专家仍然是不容易让人接受，而且仍然是一个很艰难的角色，仍然不受程序员的欢迎，仍然不受上级领导的支持。然而软件产业到现在已经采用了标准的开发方法学，可用性专家在这个方法论里找不到自己的正式位置，他还像早期80年代的程序员一样——是一个多面手，在任何一个特定的可用性角色里都没有完全的专业化（比如用户界面设计师，可用性需求分析师，可用性测试师等），他们也没有任何专业的，标准的方法将他们的经验和工作整合到软件开发团队和方法学中。历史又一次重演。
90年代后期进入到了.com时代。
我记得我就是在这个时候开始了长期的dot com的咨询工作。我现在已经快50岁了，在软件产业有25年的工作经历，而绝大部分雇员刚刚入行的时候，仅仅20岁，刚刚离开学校。他们对自己专业化的角色（后台程序员和前端程序员）没有任何消极的感受，因为这就是他们所知道的一切。一部分专业的人员应该对程序员他们所构建的用户体验完全负责。在这一点上，他们毫无异议。
在和客户公司交互的过程中也出现了一个新的类型用户体验专业——平面设计师。突然之间，类似我这样的可用性专家和20年前的程序员处在了同样的位置，需要和这个新的完全是另一类的可用性专家共同承担责任，而在过去则完全是由我们来负责。不久之后，又出现了一个新的专业用户体验角色——信息架构师。
我的书：可用性工程生命周期（Morgan Kaufmann Publishers，1999，http://drdeb.vineyard.net/index2.php?loc=7&nloc=1）更多的是引入了可用性工程的实践，主张通过结构化和工程性的方法学来达到好的界面设计，同时这些方法能够和软件开发方法整合起来，和当时的软件工程实践非常类似。这样的标准化方法在当时对可用性领域来说是全新的，这种变化就好像20年前程序员所面临的变化。生命周期的方法也更清楚地明确了在一个开发团队里用户体验专业的各类不同角色。我们需要与时俱进。
我还记得最初，学习如何为用户体验设计区分平面设计角色和信息架构角色的权责是一件非常有意思的挑战。很清楚，我从一开始就认识到强强联合的重要性，但是我发现可用性原则经常会和平面设计以及品牌原则发生冲突，难以达到最优化的联合。这就需要在一定程度上，我们彼此了解对方的经验。我感到在这点上开始清除我们之间的技术和责任的分界线。同时也感到作为一个用户体验设计团队会比各自为战要有效率得多。
2000年代
近来，我发现有一种新的用户体验专业出现：“劝导架构师”。这种专家会有市场和销售背景，专注于网站用户体验设计如何有利于“转换”，即网站有多少或者一定比例的访问者能够最终直接达到网站的商业目的，比如购买商品，登录即时通讯产品，注册或者使用网站支持等等。这是设计的两个不同方面，劝导设计是有利于将访问者转换成客户，而以前的设计是有利于任务快速和简单的完成，提高网站视觉上的吸引力，或者以最自然的方式构建网站信息或者功能。
我有一个新的商业伙伴（Todd Follansbee,网络资源营销者），他即是一个优秀的劝导架构师。我已经开始和他合作，他开发了一个新工具，可以用来快速，客观和定量的评价网站的用户体验设计，特别是电子商务网站。这个工具结合了公司目前基本的可用性原则，内容原则，平面设计原则和劝导架构原则，让评测者获得该网站的一个分数。我已经将该软件的Beta版本应用在我自己公司网站的评测中。虽然我的公司网站获得较高的可用性原则的分数，但是在劝导架构原则上得分很低。这就不是我所擅长的。同样平面设计也不是我所擅长的，这也反映在了我的网站设计上。
在Dudley工具里劝导架构的评测是考查网站是否遵循如下营销概念和原则的：
在首页上提供一个清楚的“价值主张（Value Proposition）”；（注：参见维基百科上的术语解释
http://en.wikipedia.org/wiki/Value_proposition）
关注产品或者服务利益而不是其功能（客户关心的语言）；
有效地解决信誉和信任问题；
有效地解决隐私保护问题；
使用访问者的语言（避免行业或者企业的专业术语）；
提供访问者需要的全部信息，便于访问者沿着业务路径及时决定每一步；
呈现显著和清楚的“行动召唤”
这些标准的市场概念和原则不一定能在专业的用户体验设计师（比如可用性工程师和平面设计师）打造的网站中找到。我重新设计了我的网站以达到Dudley的劝导原则。有很明显的改善（过去显示在Google搜索结果中可能是1-10页，现在是1-2页）
3 展望
我们这些可用性专业人士需要和这种新的专业人精诚合作。在Web世界里，任务的完成（传统可用性的目标）是不够的，一个吸引人的网站界面设计也是不够的。网站不仅仅要吸引住网站的访问者，还需要解决他们如何购买产品，注册或者登录等问题。您要比其他竞争网站更能快速地告诉访问者您能满足他们的需求，他们也能够迅速地在您的网站上购买产品。这是整个网站成功的关键。
因此，在这个位置上的我们需要让用户体验行业里接受和采用新的专业。在这一点上，一个多学科团队是我们成功的关键。正如20年前的程序员，用户体验行业也需要包含新的专业，然后学会如何和他们一起有效地工作。另外一个关键的问题是定义和采用开发方法学，该方法学要以一种平衡的方式整合所有类型的技巧。这可能是未来摆在我们面前的最主要的挑战。程序员们从60年代开始经历了很多的改变，也采用了很多的方法。但是他们仍然被认为是软件开发中不可获取的一部分。而用户体验专家进入这个行业经历了很多成长也超过了25年，我们仍然在很大程度上没有被认为是其中一部分或者是不可或缺的角色。通过我们和其他用户体验专家精诚合作，在我们的组织中，将我们的方法整合到标准的软件开发方法学中，这样对于我们达到一个大的战略目标上将会有更好的机会
喜欢 
顶
难过
囧
围观
无聊
