第2章
用户体验制度化，成就企业
Andreas Hauser，SAP公司
过去十年里，客户期望和软件开发流程都发生了改变。许多公司已经意识到有必要为客户提供更好的服务，特别是为最终用户，因为购买企业管理软件的决策者已经不再是首席信息官（chief information officer，CIO），而是该软件的直接使用部门。能否成功卖出产品，用户体验在其中的作用变得越发重要。但与此同时，许多公司的软件开发流程仍是一成不变。公司的技术部门依然脱离最终用户，凭自己的意愿对所开发产品的特性与功能进行取舍。
几年前，SAP决定要开发一套开创性的商业解决方案，并希望能因此大幅度提高方案在中小型企业市场的渗透率。为了开发出这么一套推陈出新的解决方案，SAP从技术、流程和组织方面彻底地改变了此前开发应用程序的常规路数（见图2-1）。SAP从一开始就把用户体验作为优先考虑的重点，并希望将体验作为产品的特色和竞争优势。
为了开发这个方案，我们必须搭建一个全新的技术平台，以在此之上开发一些开放灵活的企业管理应用。我们还搭建了一套纯服务导向型架构（service-oriented architecture，SOA），并将UI模式顺利地融入到开发工具中。
我们也彻底改变了先前的开发流程。我们的主要目标是提供卓越的用户体验（User Experience，UX），为此我们采用了一套外部驱动（outside-in driven）的迭代开发流程。在组织上下强制推行以用户为中心的设计（User-Centered Design，UCD）。为了评估我们定下的用户体验目标的完成情况，我们开发了一套UX关键绩效指标（key performance indicator，KPI），并将产品每个版本的KPI汇报给管理层。
除了新技术、新开发流程，我们还建立了全新的组织，它迅速成长壮大，如今已是一个大型的全球性组织。建立全新组织的原因是，我们的技术和企业管理应用程序都必须从零开始搭建。我们让人才在组织中平衡地分布，来自不同地区，有着不同文化背景的员工作为一个团队共同工作。
这个新组织的组织结构不同于其他的SAP部门。它分为解决方案管理（Solution Management）部门和开发部门。解决方案管理部门（其他公司也叫产品管理部门）负责确定市场需求及详尽的产品定义。UX设计师负责交互设计和协助执行用户研究，如现场观察（site visit）和用户界面（User Interface，UI）验证。开发部门则负责执行解决方案。
要在这样一个大型的全球性组织中，大规模地执行UCD设计流程是一个很大的挑战。即使一个小团队也需要大量的跨地域协作，有些团队分散在三个以上不同的地方，成员必须应对不同步的沟通、各种时差和文化差异等问题。我们必须学会听懂各种“蹩脚的英语”，学会如何组织网络设计会议。
当时我们面临的最大挑战是在我们开始设计解决方案的时候并没有现成可用的技术。我们需要在技术架构还只停留在理论阶段的时候，就开始挖掘市场的需求和用户需求。因为我们不可能空等上一两年，等技术可用了之后才开始。如果那样做，产品开发的持续时间就太长了。
随着组织不断壮大，我们需要不断地向不同背景的人（开发人员和解决方案经理）说明用户体验的价值，这也是一个不小的挑战。开发人员往往只关注产品特性与功能的执行。解决方案经理一般都有市场研究的背景，但对用户研究仍不甚了解。可用性专业人员虽然深知用户体验的价值，但在外人看来他们却更接近艺术家。我们必须想办法改变这种观点，让组织明确了解到用户体验的价值，并欣然接受。这一章我会举些例子，说明我们是如何一步步地让用户体验在组织内制度化的。
对我个人而言，这也是一段非凡的旅程。我们经历了许多起起落落，但却也乐在其中，我们特别享受和用户体验团队一起工作的时间，他们充满了朝气活力，创意十足。这一章，我想和大家分享过去几年里我的这段旅程，讲述我是如何扩大用户体验对开发部门和产品的影响力的。
那时我们确实面临着很大的挑战，因为据我所知，之前没有任何一家软件公司做过如此规模的事。我们没有可借鉴的经验，只能靠自己摸索，有时候我们只能通过尝试才能分辨什么是有用的，什么是没用的。当然，这段经历让我积累了许多经验。它们包括：
如何在全球性的组织中建立并执行以用户体验为中心的设计流程。
如何说服组织与同事搭上UCD设计的浪潮。
如何扩大对UI技术部门的影响力，让他们更关注用户体验需求。
我在这个项目中推荐的大部分UX实践对你和你的公司应该会有所帮助。但有些实践更适合在流程更复杂的大型公司和全球性组织中执行。你可以听取一些我们的建议，试着在你的公司中执行。你会知道哪些是有用的，哪些需要根据自己的实际情况做调整。
