登入帳戶　 |　訂單查詢　 |　購物車/收銀台( 0 )　|　在線留言板　 |　付款方式　 |　聯絡我們　 |　運費計算　 |　幫助中心　|　 加入書簽
	全部範圍 - 圖書 - 　- 中文簡體書(大陸書) - 　- 英文書（原版） - - 音碟 - 　- 音樂 - 　- 影視 - - 雜誌 - 全文 精確	會員登入 新註冊 |　新用戶登記

HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類閱讀雜誌

香港／國際用戶

最新/最熱/最齊全的簡體書網

品種：超過100萬種書，正品正价，放心網購，悭钱省心

送貨：速遞 / EMS，時效：出貨後2-3日

新書推薦： 《 犯罪心理X档案：法医精神科医生真实办案手记（第一季）法医精神科医师心理解剖手记 》 售價：NT$ 269.0 《 台湾农业产业发展研究 》 售價：NT$ 549.0 《 流风回雪：六朝名士的庙堂与山林（论衡系列） 》 售價：NT$ 381.0 《 妈妈，我想为自己而活 》 售價：NT$ 325.0 《 再造大唐：郭子仪评传 》 售價：NT$ 437.0 《 人性的博弈：为什么做个好人这么难 》 售價：NT$ 381.0 《 不完美的自我：接纳与放手，让自己活得更有韧性 》 售價：NT$ 330.0 《 苏菲的世界（漫画版）：寻找自我的旅程 》 售價：NT$ 442.0

建議一齊購買： + NT$ 621 《 设计之下——搜狐新闻客户端的用户体验设计（全彩） 》 + NT$ 642 《 情感与设计 》 + NT$ 642 《 Android应用UI设计模式 》 + NT$ 456 《 精益设计：设计团队如何改善用户体验 》 + NT$ 363 《 惊奇UCD：高效重塑用户体验 》 + NT$ 642 《 移动互联：用户体验设计指南 》 內容簡介： 《UX最佳实践：提高用户体验影响力的艺术》是用户体验领域的集大成之作，来自世界各地的数十位顶级用户体验专家分享了包括Google、Yahoo!、西门子、SAP、腾讯在内的数十家世界一流企业在用户体验领域积累的宝贵经验和最佳实践。《UX最佳实践：提高用户体验影响力的艺术》是独一无二的，它与现有的所有用户体验相关著作都不一样，它关注的不只是提升用户体验的方法和工具，更多的是阐述了如何通过用户体验实践来提升用户体验的影响力，以及如何通过用户体验来催化整个组织取得成功，让组织持续创造出成功的产品和服务。 第1章，探讨了设计的本质、设计大纲的应用及意义；第2章，介绍了如何在大型企业将用户体验制度化，并建立以用户为中心的设计流程；第3章，突出了用户体验团队与其他团队的合作意义，并透射出用户体验测试的效果；第4章，通过用户体验改进前后的产品对比，明晰了用户体验质量的关键要素；第5章，介绍了如何建立以用户为中心的端到端的产品开发流程；第6章，介绍了怎样采用敏捷开发流程和设计思维，并从不同角度呈现了参与者对用户体验的看法；第7章，阐述了建立和运营用户体验考评体系；第8章，介绍了如何采用原型法快速达成共识并提高产品开发效率；第9章，阐述了应用界面设计模式达成跨产品的一致性，并引进了可复用元素的概念；第10章，介绍了快速测试系统的应用，在满足消费者需求的前提下使产品快速进入市场，缩短测试和研发的流程；第11章，介绍了用户体验学科发展的方向，突出了设计思维的概念及其在公司内的演变。 關於作者： Helmut Degen博士，用户体验专家，是西门子美国研究院的团队负责人和项目群经理。曾担任沃达丰国际市场（德国杜塞尔多夫）的用户体验主管和高级用户体验经理，并曾工作于西门子用户界面设计中心（德国慕尼黑）。在用户体验方面，他有杰出的理论基础，并且已经在多年的实践中应用和验证了自己的理论。 袁小伟博士中国国家标准化管理委员会的专家委员，伊飒尔界面设计有限公司的创始人，曾任西门子用户界面设计中心（北京）的主管，是将用户体验概念从欧洲介绍到中国的先锋人物之一。他早在10年前就开始在学术领域和应用领域推广用户体验的概念，当时，中文里还没有"可用性"（Usability）或"用户体验"（User Experience）之类的单词，他通过巨大的努力和热情，使该理念在中国生根开花。他曾与联想、海尔、中国电信和平安等知名企业合作，帮助这些企业开始建立以用户体验为中心的工作流程。他还任职于多所大学，为用户体验领域培养了诸多专业人才。 目錄： 译者序 序 前言 关于作者 第1章 协作的、创新的设计大纲：使用户体验设计成为公司认可、信赖的商业核心战略性竞争力的重要工具 　1.1 到底什么是设计大纲 　1.2 设计大纲模板 　1.3 设计大纲该写多长 　1.4 什么时候需要设计大纲 　1.5 设计大纲由谁来写 1.5.1 是客户？还是合作伙伴 1.5.2 共同负责 1.5.3 共同负责人应来自哪个级别 　1.6 设计是一门解决问题的学科 　1.7 大纲的协作撰写流程 　1.8 设计大纲的主要内容：通向成功的任务清单 　1.9 协作设计大纲的商业影响 1.9.1 成为战略合作伙伴 1.9.2 认可和信赖 　1.10 总结 第2章 用户体验制度化，成就企业 　2.1 SAP是谁 　2.2 什么是SAP Business ByDesign 2.2.1 项目历程 2.2.2 为什么SAP Business ByDesign与众不同 　2.3 用户体验团队的角色 　2.4 项目阶段 2.4.1 第一阶段：设计解决方案（目标设计） 2.4.2 第二阶段：更接近目标设计 2.4.3 第三阶段：开始精益软件开发 　2.5 主要经验与建议 2.5.1 关于扩大对技术影响力的建议 2.5.2 关于扩大对组织和人员影响力的建议 2.5.3 关于影响开发流程的建议 　2.6 结论 　2.7 总结 第3章 建立和持续发展用户体验的影响：基于不同阶段的策略选择 　3.1 谁是中国平安 　3.2 中国平安网站在平安集团中的角色 3.2.1 中国平安网站的用户类型 3.2.2 中国平安网站对用户体验的要求 3.2.3 为什么用户体验对中国平安网站很重要 3.2.4 在中国平安开展用户体验工作的优势与局限 3.2.5 用户体验在平安的地位及发展过程 　3.3 工作流程中各个角色的密切配合使用户体验达到更好效果 3.3.1 部门间以及同事间是如何合作的 3.3.2 用户体验团队成员的职责 3.3.3 领导者对推动用户体验工作有极其重要的作用，通过分享业内案例和研究结论让领导者了解用户体验带来的价值 3.3.4 通过用户研究的结论数据让销售经理理解用户体验带来的价值 3.3.5 通过用户体验方法，帮助项目经理解决他们的难题以增加其参与度 3.3.6 让产品经理到测试现场倾听用户的反馈，使产品经理能更多从用户角度考虑产品销售流程 3.3.7 通过同业站点的竞争分析和销售数据使IT技术人员了解自己的工作给网络销售带来了效益 　3.4 用户体验的应用 3.4.1 使用人物角色和焦点小组了解目标用户群需求 3.4.2 在产品开发的执行过程中，要分清轻重缓急 3.4.3 产品发布后，使用其他方法与UX Office软件发现问题 3.4.4 与用户保持长期沟通，不断完善销售流程并挖掘用户群需求 　3.5 建议 　3.6 总结 第4章 从以功能为中心到以人为中心 　4.1 文档流程管理 　4.2 CORSA的建立 　4.3 微软Windows的到来 　4.4 转折点 　4.5 专家的观点 　4.6 更进一步 　4.7 试运行 　4.8 标准化，标准化，标准化 　4.9 颜色和按钮之外：制度化 　4.10 用户成了推销员 　4.11 总结 　参考资源 第5章 高效的“以用户为中心的端到端”产品开发流程 　5.1 认识：用户体验对当前电信产品开发的战略意义 　5.2 困惑：用户体验的研究范畴 5.2.1 关注多终端、多业务用户体验 5.2.2 在产品开发过程中的系统和部门之间的合作 　5.3 执行：如何进行“端到端”全流程基于用户体验的电信产品开发 5.3.1 以用户为中心的产品开发流程 再造 5.3.2 优化资源配置，建立用户体验专业团队和用户体验实验室 5.3.3 以全流程穿越测试为抓手，建立横向协同联动的端到端的用户体验测试模式 5.3.4 建立以用户为中心的产品开发 实践的考核与保障机制 5.3.5 组织文化的宣传贯彻，推动 员工的以用户为中心的观念的 转变 　5.4 效果：用户体验的好处 　5.5 结论 　5.6 总结 第6章 用户体验和敏捷开发 　6.1 商业背景 　6.2 开发环境 6.2.1 团队组成 6.2.2 Scrum 　6.3 在Scrum中实践敏捷用户体验 6.3.1 用户体验实践所需的支持 6.3.2 预先思考：敏捷软件开发和用户体验的结合 6.3.3 敏捷用户体验方法 　6.4 产品影响 　6.5 总结 　参考资源 第7章 以用户价值为依归-把用户综合评价作为产品部门的考评指标 　7.1 关于腾讯公司 7.1.1 腾讯公司和相关产品介绍 7.1.2 腾讯公司的经营理念 　7.2 为什么要建立用户体验考评体系 7.2.1 为商业决策提供用户的声音 7.2.2 帮助产品持续健康发展 7.2.3 用户体验的考评需要成为一个体系 　7.3 如何建立用户体验考评体系 7.3.1 基本流程 7.3.2 资料搜集方法 7.3.3 资料统计方法 　7.4 如何运营用户体验考评体系 7.4.1 自上而下地推动 7.4.2 敏捷高效地实施 7.4.3 更有价值地反馈考评结果 7.4.4 持续地验证并优化考评体系 　7.5 用户体验考评体系价值重大、影响深远 　7.6 最后的思考 　7.7 总结 第8章 重新设计My Yahoo!页面：使用原型来促进沟通 　8.1 重新设计产品 　8.2 最初的设计过程和头脑风暴 　8.3 使用原型进行产品设计 8.3.1 概念证明型原型 8.3.2 特定功能原型 8.3.3 综合原型 　8.4 用原型来沟通 　8.5 最后的想法 　8.6 总结 　参考资源 第9章 界面设计模式：用户的可持续定向 　9.1 商业背景 9.1.1 产品 9.1.2 客户 9.1.3 市场 9.1.4 组织 　9.2 商业问题 　9.3 制约和先决条件 　9.4 开发背景 9.4.1 构建界面设计模式库 9.4.2 确保利益相关者的参与 9.4.3 定义库结构 9.4.4 识别界面设计模式 9.4.5 描述界面设计模式 9.4.6 审查界面设计模式 9.4.7 发布界面设计模式 　9.5 使用界面设计模式 9.5.1 需求定义 9.5.2 需求分析 9.5.3 实现 　9.6 具有说服力的事件 　9.7 对产品产生的影响 　9.8 建议 　9.9 总结 　参考资源 第10章 快速测试体系 　10.1 海尔为什么重视用户体验 　10.2 海尔的用户体验设计流程 　10.3 为什么快速研发对海尔很重要 　10.4 如何进行快速测试 10.4.1 标准化的材料 10.4.2 利用外部资源 　10.5 快速测试平台应用的主要阶段 10.5.1 概念测试 10.5.2 效果图评估 10.5.3 模型接受度测试 　10.6 带来的影响 　10.7 总结 第11章 设计思维：让设计师以外的成员采用用户体验方法 　11.1 设计思维 11.1.1 识别要解决的问题 11.1.2 寻找灵感 11.1.3 酝酿多种想法 11.1.4 生成原型 11.1.5 征求用户反馈 　11.2 设计思维的好处 　11.3 商业背景 　11.4 设计思维的推进 11.4.1 高层支持 11.4.2 激励讲座 11.4.3 工作坊 11.4.4 编程马拉松 11.4.5 快速实验 　11.5 研发流程是如何改善的 11.5.1 加速研发流程 11.5.2 提高研发过程效率 11.5.3 让工程师发挥更大的作用 　11.6 设计思维对于用户体验的意义 11.6.1 设计的战略意义 11.6.2 继续设计职能 11.6.3 让设计变得透明 　11.7 设计思维对商业的意义 11.7.1 促进想法的形成 11.7.2 开辟新的市场 11.7.3 创建知识产权 11.7.4 缩短进入市场的时间 11.7.5 降低成本 11.7.6 提高商业利润 　11.8 如何在你的组织内开始设计思维 11.8.1 识别并重用组织内的设计人才 11.8.2 从小事开始 11.8.3 别光说不做 　11.9 总结 　参考资源 　补充阅读 內容試閱： 第1章 协作的、创新的设计大纲：使用户体验设计成为公司认可、信赖的商业核心战略性竞争力的重要工具 彼得 L 菲利普斯（Peter L. Phillips） 不同的人对设计有不同的理解。设计各式各样，设计师也分很多种。例如，产品设计师、平面设计师、包装设计师、用户体验（下文简称UX）设计师、用户界面（下文简称UI）设计师、景观设计师、花艺设计师、室内设计师、建筑师、甚至“设计”芯片电路的工程师，等等。因此，当我们说自己是设计师时，别人常常没法确定我们究竟是哪种类型的设计师！ 什么是设计？在我看来，著名设计师保罗兰德（Paul Rand）的回答堪称极致。兰德说：“设计是一门解决问题的学科。”无论哪个领域的设计，设计师们都是在用特定的知识和技术解决问题。通常，这些问题或多或少都会牵扯到某个具体的商业领域。 依我30多年的专业平面设计师和设计经理的经验，我发现新产品的失败率高达30%～40%。这些产品为何失败？原因可能很多。然而，据我所知，至少从某种角度上讲，很多设计项目的失败都是因为设计师或设计团队不能充分理解他们需要用设计技巧去解决的问题而造成的。而其中最常见的情况就是，因为团队根本没有撰写任何形式的设计大纲（design brief），抑或大纲写得太差而不能够反映实际问题。 那么为什么大家不用设计大纲呢？我最常听到的借口就是撰写大纲太费时和费钱。其实许多业务经理完全不懂怎样写设计大纲，或没有类似的经验，我猜这是设计大纲没有普及的另一大原因。 依我的经验，设计方案被市场淘汰的另一个原因是：项目负责人和设计师之间缺乏战略协作。通常人们只把设计当做发布新产品过程中必须附带的一项支持性工序。 既然设计是门解决问题的学科，那么如果设计师连要解决的问题是什么都不能清楚表述出来，那么设计方案失败的可能性将大大增加。为了在设计过程开始之前就明确问题，项目负责人和设计师必须在战略层面紧密合作，并肩作战。 本章不在于介绍某个具体的UX设计项目或问题，而是介绍一些技巧，帮助团队去识别并清楚表述出要解决的商业问题。这需要UX设计部门与项目管理团队建立战略伙伴关系，彼此认可、彼此信任。 迎合商业需求、建立战略伙伴关系的最佳工具就是一份协作创新的设计大纲。 1.1　到底什么是设计大纲 什么是设计大纲，在我的职业生涯中，我听到过许多不同的叫法。许多人称之为创意大纲（creative brief），其他人更习惯像营销大纲（marketing brief）、项目大纲（project brief）、任务标签（job ticket）的叫法，还有我最喜欢的叫法—创新大纲（innovation brief）。但无论哪种叫法，都是指设计项目的书面描述。 我最不喜欢的叫法是任务标签。任务标签不过是列出了项目名称、截止日期、预算、需求方（个人或团队）和其他一些战术层面的数据，一般不超过一页。我认为在实际的设计阶段，这些任务标签可以说是作用甚微。 正如我前面所说的，我十分认可创新大纲的叫法，这种叫法在欧洲很常见。我喜欢它所蕴含的深意。但很遗憾，大多数公司并不认为设计是一个创新的过程，更算不上商业层面的战略过程，他们认为设计不过是一项支持性的服务工作罢了。 1.2　设计大纲模板 设计大纲模板有很多，没有唯一的标准，也无优劣之别。我看过通篇是一段接一段的描述的优秀设计大纲；也看过以列表形式一项项列出的设计大纲，有些也做得十分出彩。最近越来越多的人使用一种电脑程序，需求方只需回答一些关键问题，将答案填入空白栏，电脑即可自动生成一份设计大纲。另外，还有一些很优秀的设计大纲是由PPT写成的。 你最终采用的模板很大程度上取决于你具体从事的设计类型，以及你的公司最适合的风格。当然，无论应用哪种模板，清晰易读和便于跟踪查询才是关键。其次，大纲必须涵盖流程中每位利益方所需的所有信息和数据。最后，设计大纲必须既有纸质版又有在线版。 过去几年里，我碰到的设计师似乎都认电脑程序自动生成的模板最具挑战性。但讽刺的是，过半的设计师都用了这种电脑生成的模板！其实并不是这些模板设计得太差，而是人们没有用合适的方法去使用这些模板。设计师们常抱怨需求方要不就是留了太多空白栏没有填写，要不就是填写的信息不全。举个典型的例子，问题栏是“目标用户”，而需求方只填了“客户”。这和没填简直没什么两样！ 找到最适合组织的模板的重要性不容忽视。多花点时间，多尝试几次，建立一套满足公司上下实际需求的模板。总之，最后你要形成一套满足自身具体需求的模板。对我来说，最适合我的模板首先是陈述性模板，其次是列表模板。 1.3　设计大纲该写多长 简答说来，设计大纲的长度应按需而定。许多参与我的设计大纲工作坊的人都跟我说，总是有人不断地要求他们把设计大纲写得越短越好。但是我们不应该以短为目标，而是需要让设计大纲尽可能完整、实用。大纲最终长度是依具体项目的需要和复杂程度而定的。 1.4　什么时候需要设计大纲 每个设计项目都需要设计大纲吗？当然不是！那些例行项目或是已经开始的设计项目并不需要一份正式的设计大纲。但各个设计类别中，包括UX设计，大部分项目必须有一份书面的设计大纲。请注意，这里所说的设计大纲不是口头的，而是书面的！我最常听到的没写正式的项目设计大纲的借口就是项目时间太紧，来不及写。第二大理由是书面的设计大纲不利于发挥创造力。我不这么认为，我相信我所推崇的这种设计大纲并不会扼杀创造性，反而会增强创造性。 说得更明白点，一些重大项目如果只有口头的设计大纲，项目时间将会大大延长。口头的大纲常常会带给团队误解、不良的情绪、意见的分歧和严重的挫败感，最后的设计方案也总是不能体现真正的水平。 我总听到一些设计师和设计部门经理抱怨：“他们不理解我。”“他们给的时间不够长。”“他们给的钱不够多。”“他们不让我发挥创造力。”“他们不理解UX设计流程！”我知道这是常有的事，但即使真实情况确实如此，我的回答也是错不在他们，而是我们自己。如果设计师们得不到定位商业问题和解决问题所需的战略信息，那么应该感到惭愧的是我们自己。如果“他们”不理解，是因为我们做得不够好。我们没能有效地沟通、表达我们的需求，仅此而已。设计行业的人要学会变得积极主动，从决策人的角度出发，让别人发现设计的价值，并肯定其具有核心商业竞争力的战略地位。在开始学习编写完美的设计大纲之前，我们需要理解怎样将设计理解为一种商务战略方面的资源，而非一项支持服务。 1.5　设计大纲由谁来写 一旦确立了设计部门要解决的具体商业需求，确定了将要执行这个项目的设计团队，就该马上展开设计大纲的编写工作。 第一步就是要确定谁将是项目负责人。负责人也是项目的最终责问人。即项目成功了功归于谁，失败了由谁来承担责任。 我坚定地认为每个项目都应该由两个人共同负责。一位代表有设计需求的业务团队，另一位代表要解决这一需求的设计团队。做项目的时候，双方都是平等的合作伙伴。他们之间是战略意义上的商业合作伙伴关系，而不是客户和服务商之间的关系。 设计师和设计部门经理必须改变思维定势，将角色定位从服务商转向战略意义上平等的商业伙伴。如果项目出了差错，设计师也要大胆站出来承担责任。 1.5.1　是客户？还是合作伙伴 我认识的大多数设计师和设计部门经理总是过度使用客户这个词。“我的客户想要这样。”“我的客户很难合作。”“我的客户不让我早点参与。”“我的客户不懂设计。”频繁地使用客户这个词在一定程度上反映出了我们处理项目的方式。其实称对方为“客户”的同时，我们也等于在说，设计不是我们做主，而是他们。为什么不以合作伙伴相称呢？为什么不分摊责任呢？ 我自己在做咨询项目时，总是尽量避免用客户这个词，我一般都说我和别人正合作一个项目。严格来讲，这些人确实是我的客户，但我不想只把他们当做客户；我也不希望他们只当我是服务方；我想成为他们的合作伙伴。 设计行业的人应该和我们所谓的客户成为平等的合作伙伴，承担相同的责任。他们需要我们的专业技术，向我们求助，仅此而已。如果我们接受了这一思维的转变，事情或许会变得更顺利，合作将擦出新的火花，好的设计也会接踵而至。这种工作关系还会带给设计师更多的自主性。 1.5.2　共同负责 我认为如果只是让有商业需求的一方撰写好设计大纲，然后交给设计方执行，这么做没有意义。同样，如果单由设计方撰写设计大纲，而没有将合作伙伴掌握的具有商业价值的重要信息纳入考虑，这么做也没有意义。因此，许多年前我定了一个规矩，设计大纲的撰写至少得有两人参与：一方代表商业需求方；另一方代表设计方。当然，有时也有超过两个人负责撰写设计大纲的情况。中间可能有第三方，这种情况通常在有商业联盟参与的项目中比较常见。但是大多数情况下，撰写设计大纲两个人就足够了。 尽管我强烈主张设计大纲的撰写应由多人共同负责，但我并不提倡成立一个委员会团队来撰写。一旦太多人认为自己负责设计大纲的实际开发和撰写，而且都去扮演设计师的角色，一切都将乱了套。一个设计大纲团队可以有多个成员，但“负责人”只应有两位，或者三位。设计大纲团队成员的职责是提供信息，并审核通过设计大纲，并不一定需要实际参与大纲的撰写。 1.5.3　共同负责人应来自哪个级别 设计大纲需要什么级别的负责人，这取决于项目的大小以及项目对公司的重要性。新推出的、突破性的产品和服务通常是由资深设计执行官、设计部门经理或设计总监负责。此外，现有产品的一些改进工作一般由中层市场专员和资深设计师来共同承担。其实，负责人所属的管理层高低并不太影响设计大纲的开发，开发流程还是一样的。 最后，我要说说客户经理、项目经理。许多公司都会雇客户经理，也就是我们常说的“西装革履的人”。这些人可否成为共同负责人呢？我认为客户经理也可以共同负责设计大纲的撰写，但是有个前提，客户经理必须十分了解设计、设计流程以及设计师需要的是什么信息。过去我接触到许多客户经理，他们销售做得很棒，也是很出色的项目经理。但遗憾的是，他们对设计知之甚少。在我看来，如果在设计师和客户合作伙伴之间安排这样一个角色，反而是一个阻碍，设计师和客户之间有了阻隔，不利于设计出一套好的方案。设计师必须和设计方案的需求方直接接触。 1.6　设计是一门解决问题的学科 那些到达一定境界的设计大师都知道，设计是一个解决问题的学科。设计与艺术的区别在于：艺术家专注于对事物的个人解读，而设计所关注的是为一个已知问题设计一套解决方案。因此，设计师必须明确确切的商业问题，并提出相应的设计方案。这也是为什么设计师和商业伙伴必须一起合作开发出一套解决实际问题的设计大纲。 一个真正有效的设计方案必须能够解决问题。这就要求：首先，问题需要被清晰地定义；另外，问题的解决方案所需要达成的商业目标也需要被清楚表述。只有当大家对实际的商业问题和其目标都有了清晰的认识之时，相应的设计方案才可能被提出。 1.7　大纲的协作撰写流程 大纲撰写流程的第一步是：共同负责人一起确定设计项目要完成的所有商业目标，并描述具体细节。这一步要回答的关键问题是：我们究竟要解决什么样的商业问题？我们到底想做出什么？ 下一步是讨论设计项目的商业动机，即目标背后的实际需求。最后，共同负责人要用文字清楚地将设计活动完成后需实现的所有效果记录下来。 1.8　设计大纲的主要内容：通向成功的任务清单 共同负责人确定并清楚记录了商业内容、市场需求和项目预期后，就可以接着撰写大纲了。 大纲的内容包括： 项目背景和项目描述 类别行业综述 目标用户综述 公司作品集 商业目标和UX设计策略 项目阶段：规模、时间表、预算 研究数据 附录（按需而定） 下面我简单总结了每个部分的内容。 项目背景和项目描述　第一部分包涵了项目背景介绍和项目市场环境描述。 类别行业综述　第二部分是关于项目当前所属的行业划分，通常包含了市场竞争，行业趋势，品牌和旗下品牌的定位、定价，产品和服务的推广策略、营销策略等信息。 目标用户综述　第三部分通常是对产品和服务的目标用户进行全面综合的讨论。特别是要说明你希望哪些用户会对设计解决方案感兴趣，会如何使用。 公司作品集　这一部分需要理清公司所有的产品或它所提供的所有服务。这个项目和公司其他产品或服务有什么关联？该设计项目如何体现了公司的品牌定位？ 商业目标和UX设计策略　这一块或许是整个设计大纲中最关键的部分。它需要设计师根据具体的商业目标制定出相应的设计方案开发策略。 就UX设计案例而言，有一个撰写设计大纲的技巧很有效：共同负责人创建一个如表1-1所示的三栏表格，许多团队试过后都觉得十分奏效。第一栏的标题是“商业问题”。在这一标题下面列出具体的商业目标。第二栏的标题是“UX相关问题”，列出具体的UX问题。最后，第三栏的标题是“UX设计策略”。这一栏应该由UX设计团队来写，所列出的策略需要共同负责人达成共识。 表1-1　移动电话公司商业视角下的UX案例 商业问题 UX相关问题 UX设计策略 改善产品的易用性，使收入增长x% （1）用户不好找到相机功能（用例：照相并发送） （2）用户不发彩信，原因不明 （3）用户回复信息不如预期的频繁（用例： 回复收到的信息） （4）用户有时会忽略收到的信息 （5）会议邀请功能不好用（用例：邀请参会） （1）进行可用性测试：设计、原型、可用性测试 （2）焦点小组 （3）实地调研：设计、原型、可用性测试 （4）使用日志：设计、原型、可用性测试 品牌知名度提高y% （1）“操作性”不够独特，容易被忽视 （2）在广告、书刊、产品和交互（如 图形化用户界面）中用更显眼的品牌标志元素 （1）品牌概念：打造品牌特有的交互设计模式（正如苹果现在所做的） （2）通过各种渠道和媒体宣传品牌概念并测试反馈 这个方法优点很多。最重要的是，它的确有助于加速整个撰写流程。此外，它几乎完全避免了在整个流程中可能出现的许多误解。有了这种列表模板，所有的利益方都能了解要解决的问题是什么以及 UX团队所做出的应对策略。这样，每个人都能对项目有一定的了解。 项目阶段：范围、时间表、预算　每个大纲都得涉及一些具体策略，通常我们称之为“项目阶段”，或项目时间表。 列出设计流程的每个阶段。每个阶段都要标明这一阶段的持续时间以及所需开支。还要注明可能需要目标用户参与的概念测试。考虑范围要涵盖到所有可能会对最终产品产生影响的辅助项，例如，包装、使用说明书、疑难排解指南等。 这一部分需要包含设计流程中非常重要的三个阶段，但却常常被忽略。第一个阶段是最后的审批阶段。你要列出掌握设计项目最终决定权人的具体信息。第二个阶段常被忽略，是执行阶段。一旦设计通过，就需要投入大量的时间和金钱在市场上推动设计方案执行。最后一个阶段是评估阶段。如何判定产品是否成功？判定成功与失败的标准又是什么？谁来评估？评估该持续多长？ 研究数据　你可能还需要总结一些关键的研究数据，用来说明为什么UX设计团队最好从一开始就介入项目。 附录　附录通常包含了竞争对手的产品照片或草图、研究数据报告和配色方案推荐等项。 1.9　协作设计大纲的商业影响 目前的研究表明，在过去的六年里，最成功的产品都是从撰写一份全面综合的设计大纲开始的。前面提到的“没有时间撰写设计大纲”的障碍并不存在。如果合作撰写一份大纲需要6到8个小时，那么设计执行阶段省下的时间至少是它的10倍。当你对一个个摆在面前的有待解决的商业问题都进行过全面透彻的分析时，你设计出的产品通常能在市场上获得更大的成功。 1.9.1　成为战略合作伙伴 设计行业的人如何成为撰写设计大纲的共同负责人，并享有平等的地位呢？首先，我们作为核心商业竞争力的战略地位必须得到肯定。我设计了一个模型，用来解释成为这种战略伙伴需要走哪几步？ 模型 图1-1很好地展示了如何一步步成为战略伙伴，这对于那些想要加深公司对设计的认识，加强设计在公司中的影响力的设计师和设计部门经理而言，十分奏效。要按这个模型一步步顺利进行，设计大纲是关键的工具。 图1-1　模型 你的价值　这是模型中的第一步，也是最重要的一步。如果连你自己都不知道自己的价值所在和设计的价值所在，其他人就更不知道了。我们大都自认为很清楚自己的价值，但是清楚与有效沟通完全是两码事。而且，我们自认为体现自身价值的东西，在别人看来或许意义并不大。对别人来说，我们在短时间内按时完成我们的工作是理所当然的。另外，预算最好也不要超。要有创意？那当然了，不然他们为什么雇你！一个人应付多个项目？他们不也天天如此。这样的问题还有很多。在说明自己的价值的时候，设计师们通常会列出他们每天做了哪些“策略层面”的事。但我看到的没几个能真正达到“战略层面”。 要想让自己的价值得到肯定，在项目中享有平等的合作伙伴地位，核心商业竞争力的战略地位得到认可，设计师必须学会用商业的行话解释自己在做的东西会带来的商业收益。举个例子，假如你希望成为撰写设计大纲的共同负责人和平等的合作伙伴，你就必须有效地沟通，让别人知道你在从战略层面考虑如何通过设计解决具体的商业问题。但如果你只关注视觉效果和技术层面的东西，没有人会把你当成真正的合作伙伴。你只会是一个“装修工”，或一项“设计服务提供者”。我并不是说视觉效果和技术层面不重要，只是你不能只关注这些。 “你的价值”中的“你”具体指谁？这个模型中牵扯到两个“你”。一个是个人的你，那个想成为平等的合作伙伴的你；另一个是集体的你，代表整个UX设计部门，你希望设计部门的价值得到认可，成为组织的重要部分，你也希望获得设计过程负责人所应得的重视和信任。 从一个测试开始 如果你想要凸显自己在公司的价值，我推荐一个十分奏效的测试。你可以自己进行测试，看看自己能给公司带来多少附加值；你也可以和设计团队一起进行测试，弄清楚设计是如何给公司带来附加值的。无论哪种形式，测试的技巧都是一样的。 首先，列出所有你认为你或者设计能给公司带来价值的原因。写下所有你能想到的点。这个时候不要考虑用词，甚至不用考虑这是否和答案相关。只要想到了，就写下来。一般来说，你很快就能写出一长串列表。这时你一般会很有成就感。我看到好多人写完之后盯着那一长串列表，自豪地说：“哇，原来我擅长这么多东西！”这时要把列表放到一边。过一段时间，也就是一两天后，再拿出来看看，并一项项地过一遍。看到每一项，都问问自己：“不搞设计的商业人士真的会在乎这个吗？“如果答案是“否”，那么就把这项划掉。我和各种团队做过上百次这样的测试。这里我举出一些被我们划掉的例子，为了说明问题，这些例子可能有点极端。“即使多个项目缠身，我也能记清楚许多细节。”“我对人很友好，容易相处。”“我特别擅长使用研究数据。”这些都是优点，但对于商业价值来讲毫无意义。 我希望第一遍你能写下所有你能想到的点，因为当你划掉那些不相关的点时，你会有一个直观的印象，你就能记住哪些类型的事虽然你们每天都在讨论，却不容易引起设计之外的人的兴趣。 当初看到这一长串列表的成就感这时候大概也就没有了。你的列表要比你预期的短得多。 下一步要重新列个表。但这次不要草草记下所有想到的点，把重心放在那些不搞设计的人会认为是附加值的点上，同时也要注意你描述它们时的用词。这个步骤花的时间要比第一轮多得多。但它的结果也同样令人期待。这次的列表相对较短，但它所包含的信息却更多了，因为这部分要说明设计到底如何增加商业的附加值。切记，这时不能从美学角度考虑，而是得从商业角度出发。思考设计能为商业做什么？ 我在第二次列出的列表上看过一些很有说服力的点，措辞可能不尽相同，但意思大体是：“我们可以缩短销售周期。”“我们可以让公司的唱片或服务在视觉上从混乱的市场中脱颖而出。”“我们创造了一个强劲的竞争优势。”“我们通过视觉效果和体验方式凸显了公司的商业战略。” 这些才会令那些非设计出身的资深业务经理们打起精神，才能引起他们的注意。“我们的任务是通过视觉效果和用户体验凸显董事会和股东们通过的全盘商业战略决策。”这是我们看到的另一个十分有说服力而且又新颖的表述。这句话听起来一点也不像是出自技术服务人员之口，更像是战略商业团队中的一员说出的话。你应该成为这种人。 一旦发现了自身的价值所在，你就应该把自己的想法融入到你所做的每件事中。一些团队做了这个测试后，制定了一套“设计哲学”。将这些说服力强、从商业角度出发的战略性观点应用到备忘录、演讲、会议、日常对话和设计大纲中去。 你可能常会碰到这种情况：开会时，公司里的其他与会人员并不了解你的工作。这在所难免，他们会问你是做什么的。我在课上做了个实验，我让学生告诉我“设计师是干什么的”。从他们嘴里蹦出的第一个词几乎都是“嗯？”，接下来就是像“我做设计是为了获得更好的用户体验（或其他什么）”之类的回答。然后他们就停了下来，不知道该从哪方面回答这个问题。做完这个测试后，你就该能给出一长串答案，这些答案在你头脑里已经根深蒂固了，也能引起发问人的注意。内心深处，你希望他们能够意识到设计对于商业的重要性，你希望他们说“真没想到，我原来还以为你们只是干技术活，我们应该多聊聊！” 许多做人力资源的人都认为，面试时的头两分钟对于整个面试的结果至关重要，他们把这一诀窍叫做“两分钟效应”。和人交流时，你必须学会言简意赅，并且得让人信服，让别人看到你提出的东西的独到之处。弄清作为一名设计专业人士真正的附加值是什么之后，你应该也有能力学会怎样在两分钟或更短的时间内向别人说清你的价值。这需要一些练习，但若想改变商业圈对设计的认识，有效沟通是很重要的一步。 要想在商业圈里得到真正的重视，首先，你必须知道自己的价值是什么（我们都是有价值的！），另外，你也必须会用商业的行话简洁、清晰、迅速地说明你的价值。如果连你自己都不清楚你的价值在哪，你的优势在哪，其他人就更不知道了。在进行模型中描述的其他步骤之前，先做一做这个测试。这个测试也很适合作为UX设计团队会议上的一项活动而提上日程。团队里的每位成员对自身价值的理解要保持一致。这比那种只让设计师一个接一个地进行情况汇报的枯燥会议要好多了。 认清UX设计的商业角色　“认清UX设计的商业角色”也可以表述为“UX设计在商业中的角色”。无论哪种说法，每位设计师或设计部门经理做商业设计项目时都必须了解怎样通过好的设计增加产品在市场上的商业价值。要牢记，设计是一门解决问题的学科。如果你接的设计项目涉及某个商业领域，那么你想通过设计解决的问题就是一个业务问题。那么UX设计能在多大程度上解决商业问题，怎么解决？我的回答是：“通过设计解决商业问题的途径比大多数人预期的要多！” 我有一个密友，同时也是我的同事，很直白地跟我：说设计在最终处理实际商业问题方面真的起不了太大作用。他是一名出色的商业战略分析家，特别擅长金融领域。他坚持认为之所以需要设计是因为它是一个载体，提供一种环境，用来承载公司产品或服务的相关信息。在商业圈里，持有相同观点的人很多，确切地说应该是比比皆是。当然也有一些公司的成功是完全取决于设计，例如苹果、沃达丰（Vodafone）和伊莱克斯（Electrolux）。 从事设计行业的人去有义务去改变人们的这种看法。坦白讲，我认为过去几年我们在这方面做得很差。要想清晰地向别人说明设计的角色和价值，首先，我们自己必须先了解设计在商业中扮演的角色。 你所处的公司或合作客户的公司面临着什么样的商业问题？设想一下：“是什么让首席执行官辗转反侧？他最棘手的商业问题是什么？”然后再反问自己：“有效的UX设计在解决问题的过程中如何发挥作用？” 建立互利关系　在公司内部建立互利关系是设计部门和设计部门经理成为战略伙伴的关键环节，但设计部门却最常忽视它。我常常遇到这种情况，设计师和设计部门经理们不是很乐意和其他部门打交道，在商业问题上也不是很积极。 其实，设计部门经理应该多与商业部门的负责人联系，建立同盟关系，成为他们的合作伙伴，给予UX设计方面的帮助；成为他们的盟友，先耐心倾听，进而给出创造性意见，帮助部门负责人完成商业目标。这才是真正的互利关系。 原来我在公司就职的时候，常常打电话给某个部门的经理，介绍自己并表达自己愿意出席他们以后的部门会议，说明设计如何在他们从事的具体商业领域发挥作用。很多人根本意识不到他们的工作常常需要设计。他们对设计的看法有了很大的转变。在员工会议上，我会花10到15分钟去阐述设计如何在他们的工作中发挥作用，这时如果他们有需要的话，我会就他们遇到的和设计有关的难题给一些建议。我并不亲自设计去解决他们的问题，而是帮助他们利用其他资源更好地解决问题。这么做有几个优点。1）让很多人明白了日常生活中处处有设计。2）提升了设计部门的专业技能在公司中的知名度。3）让设计部门的专业技能获得广泛认可。4）我能够获得一手信息，了解各部门最关心的商业问题是什么。最后，我和公司各部门都建立了同盟关系，可以进一步发展为互利关系，这对设计部门以后的项目绝对大有裨益。例如，建立了这种互利关系后，撰写设计大纲时再列出所有的利益方就简单多了。 我认为这是在公司内部建立互利关系的最好沟通方式。当你在某团队的员工会议上做这件事时，可以先观察一下哪些人可能会成为设计的真正拥护者，然后重点和这样的一两个人发展关系。 我在公司建立的最强的联盟关系之一，是与法务部门达成的。当今，似乎我们的所有设计工作都会涉及法务需要考虑的方面。与法务部门建立互利关系，比每次都面临枯燥的“法务审核”要好多了吧。 建立牢靠、良好的关系并非易事。这需要时间，还需要你处事圆滑，懂得倾听，要表现出你真的很关心他们团队的需求，而不是只顾着自己的需求。总之，设计部门经理若想成为战略上的商业伙伴，成为公司重要的财富，获得尊重和信任，就要花心思、花时间去经营这种关系，而不要老给人一种“格格不入”的感觉。没有这种部门间的互利关系，你永远也不可能成为真正意义上的核心战略合作伙伴。你只能继续扮演“服务提供者”的角色。 执行“和……工作”的高效流程　注意标题的用词是“和……工作”。它和“为……工作”恰恰相反。我们说的是战略伙伴，而不是只提供支持服务者。你不只是个的士司机，把你的“客户”带到任何他们想去的地方就可以了。你应该成为他们的交通顾问，根据乘客的需求、时间和预算为他们推荐最佳路线。 和他人工作，与为他人工作是截然不同的。连很多设计师和设计部门经理都认为自己只是服务提供者，算不上是商业战略伙伴。相信我，如果连你自己都这么想，那么其他人也会这么想。另外，如果你的行为也只停留在服务提供者的水平上，那么你和设计部门在公司中的地位也只能如此了。 上文提到的几个要素都是这一角色转变的基础。此刻，你应该已经明白设计对公司的真正价值所在，并学会用商业语言表达出来。你也做过了测试，充分理解了设计在商业中的角色定位，即核心商业战略的视觉表达。你还主动出击，找到了公司中主要利益方，并和他们建立了互助互利的关系。现在是时候摆脱服务者的枷锁，成为真正意义上的合作伙伴了。 一些人很懂得怎样和人打交道，怎样与人合作，怎样和同事相处，但对有些人而言，这可能确实是一个很大的障碍。这需要你对你的专业技术、所学的知识及其商业附加值抱有与生俱来的坚定信念。就算我们是专业的UX设计师，但我们的商业眼光是被认可的吗？看看我们周围在这方面做得不错的人。律师、医生、CEO、市场营销人员、工程师，几乎所有的职业人员都认识到自己的专业技术是各自的立身之本。严格来讲，从字典的定义看来，这些人也有自己的客户，但他们并没有表现出低人一等，把客户捧为自己的“主人”。他们清楚自己提供的“服务”会影响事情的成败。从事UX设计的专业人士也同样，如果你只是一个服务提供者，那么在市场环境下，你的价值就不可能得到真正的认可。人们会看重那些有突出作为的人。 当然，这与设计大纲有直接关系。“目标用户综述”这一部分要将世界各地所有用户的需求清楚地表述出来。商业目标和UX设计策略这一部分要分别列出所有的区域性商业目标，并根据各个区域性目标制定出相应的具体设计策略。为了防止设计走偏，你必须找到不同国家的用户代表，把他们列入主要利益方这一部分，另外在设计大纲的整个撰写过程中也一定要向他们咨询意见。 设计部门经理必须尽全力调查各种类型的用户，学会如何开发出满足各类用户需求的有效设计解决方案，处理全球性的商业项目时更是如此。我强烈建议设计师和设计部门经理多参加全国性、国际性的销售会议，以及展销会这样的活动。尽管这些活动的主题本身看起来和设计并没有直接联系，但他们却是设计专业人士直接获取商业需求的绝佳机会。 两耳不闻窗外事、一心只做设计的时代早就过去。做设计的人要走出设计工作室，看看世界的变化。设计专业人士不仅要主动倾听公司内部主要利益相关者的需求，也要倾听各类目标用户的需求，给他们提供有效的设计解决方案。光靠坐在小隔间里埋头苦干是不可能设计出优秀的设计方案的。因为要和那些从未谋面、从没交谈过的人合作，给他们做设计，这谈何容易。 1.9.2　认可和信赖 若想作为业务战略伙伴的地位被逐渐认可，你需要做到以下几点：充分意识到你个人和设计部门给公司带来的附加价值；理解并能够清晰地表达设计在业务中扮演的角色；能够建立互利关系，注意是“相互”的；学会与他人共事（不是为他人工作）的技巧。 有了知识，才会理解。有了理解，才有欣赏和认可。有了认可，才有信赖。首先，人们得知道一些相关知识，了解设计的附加价值。只有了解了这些之后，他们才懂得欣赏出色的设计。当你的设计方案真正解决了项目的商业需求，认可也就随之而来。一旦你得到了认可，获得信赖也只是时间问题了。 我们已经反复说过，之所以这么多设计师抱怨时间不够，预算不足，参与项目的时间点太晚，不被欣赏，不被理解，是因为他们的商业能力从一开始就不被信任。别忘了，无论营利性组织还是非营利性组织都是为了赚钱。非营利性组织也必须赚钱来抵扣支出，否则它也坚持不了多久。营利性组织就更是如此了。 在商业人士眼里，设计的首要任务就是达成商业目标。做设计的人要让业务人士知道这也是我们的目标。我们得让我们的商业合作伙伴知道，设计的作用远不止“美观精致”而已。 设计方案的最终决定权几乎都是掌握在非设计行业的人手里。这个现象很值得思考。为什么那些对设计不甚理解的人却掌握着设计的最终决定权？他们既没有受过相关的设计训练，也没有设计的专业技能！因为设计师的商业评估能力不被信任。大多数非设计行业的人都会承认在设计技巧和元素方面专业设计师确实比他们懂得多。他们只是不放心让设计师做最终的评估，去判断设计解决方案是否能够解决实际商业需求。只有获得了非设计行业的合作伙伴的认可与信赖，设计师才能够成为享有平等地位的共同负责人，设计团队在撰写设计大纲时才能享受战略合作伙伴的平等待遇。 我设计的这套模型已经成功地帮助了许多设计团队赢得认可与信赖。当然，我自己也很受用。协作的设计大纲是实现这套模型的精髓的最佳途径、最佳工具。尝试一下吧！ 1.10　总结 设计大纲如何帮助测量设计项目的投资回报率？ 一份好的设计大纲会对设计要解决的问题、要实现的核心商业目标、设计方案的预期执行结果进行透彻分析。这些因素决定了评估设计项目的资金投放标准。 如何判断新项目是否真的需要设计大纲？ 如果设计项目规模较小，只是已有产品的一两个小修正，那么并不一定需要设计大纲。但如果项目需要开发出一套全新的设计方案，那么设计大纲将发挥重要作用。 为什么要让设计项目负责人和设计师共同撰写设计大纲？ 因为通过这种合作方式，双方能够各取所长，一起做好项目。而且双方在合作撰写设计大纲时，就已经几乎将所有可能出现的问题摆在台面上了，并且提前妥善处理了，这样在执行阶段就可以节省大量的时间。 设计大纲太长，我们一直都没时间写，有没有什么其他捷径？ 说句实话，并没有捷径。对那些从一开始就备受重视的项目而言，是否撰写设计大纲对项目的最终成败至关重要。设计项目执行阶段省下的时间要比项目开始时撰写大纲所花的时间多得多。 为什么要让目标用户测试设计概念？ 公司里参与设计的人对项目太熟悉，不能够真正客观地判断哪个设计概念的效果更好。你是在为目标用户做设计，只有他们才能真正让你知道—你的设计方案是否适合他们。 执行项目时，设计大纲要用到什么时候？什么时候可以不再需要它？ 项目的整个流程都需要设计大纲。最后三个阶段包括：1）决定设计解决方案能否通过的展示阶段；2）最终设计解决方案的执行规划阶段；3）设计解决方案面世后的评估阶段。项目完成后，最后的评估阶段可能还要持续一些时间。 第2章 用户体验制度化，成就企业 Andreas Hauser，SAP公司 过去十年里，客户期望和软件开发流程都发生了改变。许多公司已经意识到有必要为客户提供更好的服务，特别是为最终用户，因为购买企业管理软件的决策者已经不再是首席信息官（chief information officer，CIO），而是该软件的直接使用部门。能否成功卖出产品，用户体验在其中的作用变得越发重要。但与此同时，许多公司的软件开发流程仍是一成不变。公司的技术部门依然脱离最终用户，凭自己的意愿对所开发产品的特性与功能进行取舍。 几年前，SAP决定要开发一套开创性的商业解决方案，并希望能因此大幅度提高方案在中小型企业市场的渗透率。为了开发出这么一套推陈出新的解决方案，SAP从技术、流程和组织方面彻底地改变了此前开发应用程序的常规路数（见图2-1）。SAP从一开始就把用户体验作为优先考虑的重点，并希望将体验作为产品的特色和竞争优势。 图2-1　挑战 为了开发这个方案，我们必须搭建一个全新的技术平台，以在此之上开发一些开放灵活的企业管理应用。我们还搭建了一套纯服务导向型架构（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实践对你和你的公司应该会有所帮助。但有些实践更适合在流程更复杂的大型公司和全球性组织中执行。你可以听取一些我们的建议，试着在你的公司中执行。你会知道哪些是有用的，哪些需要根据自己的实际情况做调整。 2.1　SAP是谁 SAP是欧洲最大的软件公司，拥有53 000名员工。在全球120多个国家，有超过10.9万个公司都在使用SAP软件。每天都有逾3500万人在使用SAP软件。SAP在行业内触及之深，覆盖面之广，已让它成为行业中的佼佼者。 过去35年中，SAP一直致力于帮助其他公司成为各自行业的领军人。在与世界各地的合作伙伴和客户打交道的过程中积累的大量行业经验，让SAP能够准确洞察企业需求，帮助他们解决问题，更好地运营企业。在这些方面很少有其他公司可以与SAP媲美。 2.2　什么是SAP Business ByDesign SAP Business ByDesign是SAP新推出的按需配置的企业管理解决方案，主要面向中小型企业。这一解决方案因其存在很多创新之处，可以使其区别于市场上的其他产品。SAP Business ByDesign是全球最完备、最灵活、按需配置的企业管理解决方案。与其他按需配置的企业管理软件不同，SAP Business ByDesign（见图2-2）让企业端到端的每个流程都更透明且易于掌控，这其中包含了客户关系管理（CRM）、供应商关系管理（SRM）、供应链管理（SCM）、财务管理（FIN）和人力资源（HR）。此方案让企业能立即对自己的情况进行360度掌握，并且它简单易用，能快速配合商业需求的变动。 图2-2　SAP Business ByDesign（版权归SAP AG. 所有，2010） SAP Business ByDesign设计时考虑了以下几个关键原则： 坚持以市场为导向的设计思路与开发路线。 在项目初期整合最终用户的反馈并融入迭代开发流程。 提供突破性的用户体验。 扩大模式驱动（model-driven）、服务导向（service-oriented）的架构的影响力。 2.2.1　项目历程 几年前，SAP决定开始一个新的研发项目，利用面向服务的架构优势，建立一个企业级应用的新原型。项目的主要目标是提供卓越的用户体验，降低软件复杂度，降低总所有成本（Total Cost of Ownership，TCO）。 我参与了解决方案的规划，而后我们团队设计出了最初的软件构架图。随后，我们成功地向董事会展示了规划图并通过了审批。公司问我是否愿意去领导用户界面相关的工作。之后的几个月里，我们与开发团队一起搭建UI架构，建立最初的原型，并为不同用户角色设计了一系列不同的应用程序。我们有很大的自主权，可以自己定义新的软件架构、采取新的开发流程和设计新的应用程序。 此研发项目的结果很成功，SAP董事会决定在这一研究项目得出的软件架构基础上，搭建一个新的面向中小型企业的企业管理解决方案。2007年9月这一全新的企业管理解决方案正式发布。此后这一产品就叫做“SAP Business ByDesign”。 2.2.2　为什么SAP Business ByDesign与众不同 SAP Business ByDesign 将用户需求作为设计的中心，解决企业管理软件中与“人”有关的问题。这一定位至关重要，因为购买企业管理软件的决策者已不再是首席信息官（CIO），而是使用该软件的部门。我们的目标是设计出一套满足用户期望的解决方案，并确保每位用户都能高效地使用该系统。为达到这一目标，我们制定了一套以用户为中心的设计流程（见图2-3），并在组织上下强制执行。 图2-3　以用户为中心的设计流程（版权归SAP AG. 所有，2010） 对客户而言，糟糕的UI带来的使用成本（例如，使用户培训时间延长、造成低下的使用效率，更有甚者用户可能会拒绝使用这个软件）可能高达购买应用程序本身费用的数倍。因此，对他们而言，卓越的用户体验至关重要。 SAP Business ByDesign的主要目标是： 简单易用　软件必须易学、易用。用户希望软件可以轻松上手，不希望在培训上花大把的时间。特别是在中型企业市场，员工往往一人承担多种角色。因此，软件的易用性和一致性十分重要。我们使用了基于模式的设计方法，有助于保持整个软件系列的一致性，使得用户可以用同样的方法有效地执行相似的任务。 以人为本的设计　要提供直观的用户体验，设计者必须理解最终用户的需要。首先，在软件开发周期之初，我们就要确定用户需求，深入用户的工作环境，并了解用户所需的信息、工作流程、工作目标、工作动机、沟通方式等。然后将这些发散的用户需要（user need）转化为具体的用户需求（user requirement），进而转化为系统需求。最后编写出用例（use case）并设计出线框图（wireframe）。随后我们通过最终用户测试用例和线框图，并在移交开发部门之前将用户的反馈融入线框图。 我们也会对开发完成后的产品进行可用性测试，但相比之下，我们在开发初期基于线框图进行的测试要更多。此类更早期的测试效果更好，因为改变早期设计比改变一个已开发的应用程序花费要更少。在整个开发流程中与最终用户保持持续的迭代反馈循环至关重要。 灵活的UI技术　所采用的UI技术必须灵活，能够快速适应和满足市场需求、客户需求和用户需求。我们的整个解决方案都是在模式驱动和服务导向的框架上开发的。这能确保我们的客户和合作伙伴有足够的弹性空间去对解决方案进行调整和扩展，同时，这也让最终用户个人能根据自己的需求去自定义系统。在开发过程中使用UI模式有利于保持一致性，并极大地提高了开发团队的生产力。 2.3　用户体验团队的角色 在成立的头两年里，ByDesign用户体验团队就迅速发展成为一个跨越多个国家的大团队。由于不可能在很短的时间内就招到足够多的人，我们与几家外包供应商也有合作。 我们聘用了许多具有优秀交互设计和用户研究背景的人，他们都很年轻且充满创意。同时，我们也很看重所招聘的人是不是有团队精神。为什么这点很重要？ 用户体验团队在整个产品开发流程中扮演着重要角色，因为他们是对接方案管理部门和开发部门的桥梁以及最终用户需求的传达者。用户体验团队必须站在用户的立场去沟通，但同时他们对产品的理解很可能不如解决方案经理。因此他们需要与开发者和解决方案经理不断协调沟通，以最终更好提升产品用户体验。在这个过程中，团队精神这样的软技能非常重要。 SAP Business ByDesign只有一个用户体验团队，底下分为三个小团队： UI概念与准则　团队为产品定义UI风格指南，为新的UI模式编写详细描述，并协助UI架构技术团队（属于技术团队，负责搭建产品的技术平台）将UI模式应用到产品开发中。为了保证软件一致性，我们将UI模式开发出来并整合到开发工具中。UI 概念与准则团队要协助设计师与开发人员使用UI设计风格指南，并收集面向未来的新的UI需求。另外，他们还负责提出并定义UI的创新概念。 最终用户相关基础设施　最终用户相关基础设施团队负责组织和协调客户活动、合作方活动、用户活动（例如，现场观察、焦点小组、用例验证、UI验证、可用性测试以及基准测试等）。他们负责在全球建立并管理一些基础设施，以支持设计师和用户研究人员在多个国家与用户进行互动。 此外，团队也负责定义UCD方法论，并对解决方案经理、开发人员和用户体验从业者进行UCD培训。团队还要参与产品开发流程的定义与执行，并确保UCD活动能够顺利地融入到开发流程中去。 应用程序设计　此团队中包括交互设计师和用户研究人员。他们与开发人员、解决方案经理同属于应用程序团队。他们的任务是设计企业管理应用程序，例如财务管理应用程序、人力资源管理应用程序、客户关系管理应用程序。他们是用户需求的代言人，也是整个应用程序团队中以用户为中心的设计的推动者。每个应用程序都由一名用户研究人员负责，专门筹划并开展相关的用户研究活动。用户研究中得到的结论都能立即与开发人员和解决方案经理进行讨论。结论中提出的需求可能当前版本就能满足，也可能需要暂存起来，下次更新时再解决。交互设计师参照设计风格指南，负责设计所有的交互界面并协助开发过程。 用户研究为何如此重要？ 因为只有了解了用户的需求才能设计出好的解决方案。怎样挖掘用户需求，直接问用户你想要什么就可以了吗？当然不是。用户很难表达清楚未来的软件解决方案该是怎样的。如果在汽车刚发明出来之前问他们有什么需求，你得到的答案很可能是“跑得更快的马”。用户研究之美在于观察用户并挖掘他们的真实需求，这也是神奇所在之处。用户的陈述和行为都是表面现象，研究者存在的意义是：他们能够透过现象看到本质，并挖掘出用户的真实需求。 我们应该在项目初期多花时间进行用户研究，并与最终用户一起改善设计。这么做能够缩短开发周期，并最终带来更高的用户满意度和使用效率。另外，这对你自身而言也是益处良多，因为你获取了大量真实的研究数据，当有人问起为什么软件包含了这个功能，而不是那个功能时，它能够为你提供数据支持。 以我个人的一段经历为例，那是我第一次意识到用户研究的重要性。当时我们去一位客户的现场做用户研究，地点在上海。我们观察了一位用户，他的任务是把几百张发货单的内容手动输入电脑。他当时用的并不是SAP软件。他把发货单文档放在键盘的左侧，然后输入数据。输入了10个发货单的内容后，他点了保存按钮，等了一会，然后又点了10次刷新按钮，确认软件是否正确处理了发货单的内容。他说他必须这么做，如果发现错误，他就能马上纠正。通过这次观察，我们产生了一个想法，其实系统自己就能够为用户做这个事。用户只需要输入发货单内容，如果出现错误系统应该自动提醒用户。但是，这位用户却告诉我们，他对他当时使用的那个软件很满意。因此，只有当你亲自到了用户的办公现场，仔细观察用户是如何操作的，才能够真正意识到用户研究的重要性。 然而，要做出创新的设计，仅靠观察用户是远远不够的。你必须访问合作伙伴、受理投诉的服务部门、数据分析师和销售人员。收集了所有研究数据之后，研究人员会和解决方案经理、用户体验设计师以及开发人员一道将这些发现转化为创新的设计。 在我的职业生涯里，许多人提出过绝佳的创意点子，但是大多数想法都没能进入到产品阶段，这样的例子我看得太多了。创新需要执行力，把创意推向市场。光有想法是不够的，你必须为之努力，将其变为可行的解决方案。没有成功就没有影响力，换句话说，你的想法不过是又一个美好的想法罢了…… 2.4　项目阶段 项目要经历三个阶段，如图2-4所示。在第一个阶段，我们有意将开发流程与UCD流程分开进行。解决方案管理团队负责通过外部驱动研究方法定义目标解决方案，与此同时，开发团队并行开发技术平台。从一开始，ByDesign用户体验团队就同时协助解决方案管理团队和负责开发技术平台的UI架构团队。用户体验设计师与解决方案经理紧密合作，一起定义应用程序的目标设计。同时，我们也必须确保在UI架构中能完美地实现出UI模式，撰写详尽的UI规范文档，并在开发阶段协助框架开发人员。在第二阶段，我们得让已实现的解决方案更接近目标设计。等到了第三阶段，我们就开始转入精益开发（LEAN）与敏捷开发（agile development）模式。刚开始时，我们并没有明确地区分每个阶段。但随着经验的积累，情况逐渐清晰起来。每个阶段我们都学到许多技术、流程和全球性组织管理的经验，而且团队在这些方面的表现也大大提升了。 2.4.1　第一阶段：设计解决方案（目标设计） 尽管当时没有现成的技术，我们也必须开始设计。我们的目标是打入新市场，吸引新客户群。解决方案经理和用户体验设计师的首要目标是解读市场需求和用户需求。他们为新解决方案提供目标设计。 他们设计了上千个界面，用HTML制作可点击的原型，这些原型在外观和使用感上与真正的应用程序相差无几，但这一过程并不需要写代码。然后我们让上千名分布在世界各地的用户验证这些界面，通过不断迭代改进解决方案。我们还与管理团队、执行董事们花了好几天一起检查HTML原型的界面。虽然这一过程比较耗费时间，但是相比等到商业目标确定以及框架编程也完成后才开始测试的代价要小得多。我们从中得出一个经验：一个HTML原型胜过千言万语。因为这是一种所有开发人员、解决方案经理、董事会成员、经理以及来自各种文化背景的人都能理解的语言。 我们希望产品能吸引那些以前不用SAP产品的新客户、新用户，而不是仅仅利用现有的SAP客户群。因此，我们必须建立自己的基础设施，接触那些还没使用SAP产品的用户。我们通过市场研究公司找到符合要求的用户，并借助外部的可用性实验室开展用户活动。 合理性测试（The Sanity Check） 在这个阶段设计UI原型是个难题。在设计用来描述目标设计的UI设计风格指南时，需要假设许多技术的可行性。然而，随着项目的进展，我们有些技术并没有足够的时间去实现。我们必须一次次地更新UI设计风格指南，不断提高它与技术框架的一致性。在这种情况下，让参与项目的每个人都及时了解最新变化又成了另一大难题。为此我们建立了一个维基站点提供最新信息并定期开展信息交流会。解决方案经理和UX设计师在将UI原型移交应用程序开发人员之前必须根据这些变化做出相应调整。我们希望UI原型能呈现出最好的品质，它必须尽可能精准地呈现出我们最后想要的效果。为了确保UI 原型能够与设计风格指南保持一致，我们决定在开发流程中添加一道“合理性测试”门槛。 在解决方案经理和UX设计师将UI原型移交给开发部门之前，原型要先经过我和SAP的用户体验部门高级副总裁丹罗森伯格（Dan Rosenberg），也是用户体验方面的专家，召开正式审核会议来决定。我们对设计风格指南了然于心而且也熟悉大部分技术细节。在这一阶段进行质量测试至关重要。合理性测试是必须通过的一道门槛。它强调了UI设计风格保持一致的重要性。在合理性测试阶段，我们将不同的UI原型标记为“红灯”“黄灯”“绿灯”三个状态。“绿灯”代表UI原型与设计风格指南一致，开发部门可以开始开发。“黄灯”表明UI原型在移交开发部门之前还需要做些细节上的改动。“红灯”意味着未通过，即UI原型与设计风格完全不符合，需要重新修改后再次进行合理性测试。刚开始执行、记录合理性测试的时候相当吃力。我们看了上千个界面。进行合理性测试的时候，我们不能深入到很细节的方面，而只是指出一些明显的问题。但我们的努力是值得的。我们定位问题的速度越来越快，而且随着时间的增长，UI原型合理性测试中出现的“绿灯”越来越多。 我们定期将合理性测试的总体结果汇报给管理层，这让用户体验有了更多的曝光机会。在当时的情况下，进行合理性测试是一个正确的选择，它是一个很好的工具。如今我们已经不再需要进行合理性测试了，因为得益于稳定的UI风格指南，UI原型质量已经大大提升。 基于模式的用户界面 从一开始我们就很清楚地认识到为了提高开发的一致性，我们必须将UI模式整合到开发环境中。这是正确的决定，因为大多数开发人员都不想花时间去读UI设计风格指南。 我们对企业软件的常用模式做了大量研究，从中提取出UI模式。在开始SAP Business ByDesign项目之前，我们在另一个SAP产品中就已经初次接触过UI模式。第一个产品的客户和用户使用这些UI模式时给予的反馈对提高Business ByDesign UI模式库的质量起到了很大的帮助作用。 UI模式是针对用户完成的某些任务而设计的。举一个UI模式的例子—目标工作列表，如图2-5所示。这个模式支持用户完成搜索商业目标、定位目标、预览数据或者开始实现目标等任务。同一个UI模式里的所有UI元素和元素间的交互方式都是预先设定好的。这样就开发人员不需要再操心这些问题。最后呈现给用户的是一个具备基本搜索与高级搜索功能的搜索区域。用户单击“搜索”按钮之后，所有的结果将出现在搜索区域下方的表格中。当用户选择了表格中的一项后，相关的商业目标细节就会出现在预览区域。 刚开始的时候，我们并不确定有多少UI应该采用基于模式的设计流程，有多少应该采用“自由风格”才能够迎合用户的需求。开始我们估计70%的UI可以套用模式，30%采用自由风格。然而当我们设计完所有的页面后，我们终于有了答案：90%的UI都套用了模式，10%采用了自由风格。但这个比例并不是一定的，因为这一结果很大程度上取决于你的模式数量以及你要搭建的应用程序的类型。例如，图2-5所示的“目标工作列表”UI模式在我们的解决方案中用到了350次。这也表明使用UI模式会带来的高回报。 另外，我们也不是很确定每个UI模式应该留给开发者多大的自由发挥的余地。如果严格限制模式，解决方案可达到高度一致，但你将无法通过优化UI让用户更好地完成任务。所以我们决定多给开发人员一些自由度。然而，在有些情况下灵活度稍微有点过头了，以至于我们不得不在项目后期花大量的时间处理细节上的一致性问题。 在第一阶段，解决方案管理部门主导产品定义。他们负责具体的需求定义。UX设计师负责用户体验设计，但整体的解决方案仍是由解决方案管理部门负责。他们负责推动将设计移交给开发部门的这一环节，并与开发部门沟通。而UX设计师需要参与到任何需要他们的环节。UX初步制度化的一个标志是：开发人员只有从解决方案管理部门拿到UI原型后才可以开始开发。 我们在第一阶段面临的挑战是在不清楚技术局限的情况下开始设计解决方案。我们在UI架构的规范文档的基础上建立了UI设计风格指南。我们在设计时抱有的预期是：一年内，在UI架构的基础上实现UI规范，并且能够及时移交给应用程序开发人员。一年后，第一版的UI架构完成，开发人员开始实现应用程序的界面。从用户体验的角度看来，第一版的SAP Business ByDesign并不完美。因为技术平台团队与应用程序开发人员无法在有限的时间内开发出与目标原型相同的界面。我们必须在下一版本中做出改进。 图2-5　基于模式的用户界面（版权归SAP AG. 所有，2010） 引入关键绩效指标（KPI）评估产品表现 项目开始的时候，我们设定了每个版本应该达到用户体验KPI目标值并在版本末期评估产品表现。我们通过基准可用性测试评估用户使用效率，有效性和满意度。我们很清楚不可能在第一个版本就达到最终目标。我们为第一个版本设定了6分的可用性KPI目标值（总分是10分）。然而，我们选择了一些关键用例对他们进行基准可用性测试，结果显示：第一个版本的KPI只有4.8，甚至没有达到我们为第一个版本设定的目标值！我们将这一结果上报给管理层，显然我们需要增加项目投入。同时，我们也计划了改进措施以期用户体验在下一版本上有重大提升。用户体验是下一版本需要最先考虑的问题，开发人员也需要集中精力提升用户体验。 2.4.2　第二阶段：更接近目标设计 在第一阶段，我们有意将目标解决方案的设计与技术平台的开发并行进行。一方面，解决方案经理、UX设计师在设计解决方案（不断迭代），并且有最终用户参与全过程。另一方面，技术和应用程序开发人员同时在搭建新的软件架构，并开发第一版SAP Business ByDesign。他们的表现都相当出色，但这也意味着第一个版本快发布的时候将必然存在对接问题。 因此，第二阶段的目标就是让已实现的解决方案更靠近目标设计。 “UI润饰篇” 我们开展了一个UI润饰项目，目的是根据最终用户的反馈和内部反馈，提升已实现的多个应用程序的用户体验。尽管我们已经在开发工具中融入了UI模式，但由于一开始UI模式被赋予更多的灵活度，开发人员仍可能开发出不一致的界面。公司任命开发团队的一名经验丰富的同事和我接手负责这个项目。我认为这种共同负责项目的方式很好，双方可以将开发与用户体验方面的专业技术得以结合。 我们成立了一个核心团队，团队成员来自应用程序开发部门、用户体验部门、UI架构部门和技术部门。我们让所有必要的参与方都坐到一张桌子边上，一起制定出一个各方都认可共同方案。我们待在房间里整整两天，最后终于得出了一个方案。 发现问题　UX团队负责发现并监控已实现解决方案的所有UI问题。 排列优先级　核心团队根据客户和用户的反馈一起排列问题的优先级。 解决问题　技术团队负责解决技术问题；UX团队解决UI设计风格指南的相关问题；应用程序开发团队解决应用程序相关问题。他们必须像一个团队一样合作才能解决问题。 记录　UI架构团队和UX团队负责补充UI润饰准则并传达给开发人员。 实现　应用程序开发团队负责在所有的应用程序实现UI润饰风格指南，与之保持一致。 UI问题可分为三类：技术问题、应用程序问题和UI设计风格指南问题。我们从核心团队中为每种类型的问题指定了一名相关负责人。 在完成了项目部署并全体通过了计划后，我们开始了痛苦的执行阶段。我们把所有的UI问题集中到一起，然后把它们按优先级排列，确定要优先解决的问题。 我们决定让组织和管理层都能看到其中高优先级的问题。每个月我们都会创建一份UI润饰报告，描述问题解决的具体情况。我们画了一个时间轴，标明了可以向客户发布修正版本的时间点，这是PPT里最重要的一页。另外，我们每个问题都只用一页PPT，附上图片以及一两句描述的话。为的是让执行总监迅速了解要解决的问题，这一点很重要。我们遇到的难度最大的问题是，技术团队决定要开发一种新功能后，所有的应用程序开发人员需要将这一功能潜入到他们各自程序的UI中。那时，我们已经完成了数千个页面。即使假设我们只需要在部分页面中实现这个新功能，开发每个页面只需几个小时，开发团队也得安排大量的人力和时间去修改那些受到影响的界面。不过，那些单靠技术团队就能解决的修改执行起来就容易多了。他们只需要将其加入到新版本中，而不需要其他所有应用程序开发人员做出相应调整。 我们花了不少时间解决了大多数关键问题。这一过程对技术开发人员、应用程序开发人员和UX设计师而言都十分痛苦。技术平台实现某个新功能，UI架构团队与UX团队就得马上制定出一套UI润饰准则。准则包含两个部分：UI设计风格说明以及如何实现该功能的细致的技术说明。 另外，我们还需要估计应用程序开发人员实现某个新功能的工作量，获得各个开发团队的认可，让他们参与其中。这是往往是一场资源与时间的争夺战。但ByDesign管理团队十分重视改进过程，所以大多数情况下我们都能成功。每天我们都在为每一个UI问题积极争取资源。 UX团队和开发团队确立了一个共同执行方案。我们给应用程序的每个模块指定一名开发人员作为UI润饰工作的首要联系人。另外，我们也给每个模块指定了一名UX设计师。开发人员负责根据UI润饰准则的要求实现新功能；而UX设计师主要负责测试，看开发人员是否正确地实现了准则，以及在开发人员遇到问题时协助他们。尽管这样的工作对UX设计师而言相对枯燥，但是为了让产品质量达到目标，这也是必不可少的。我们建立一张庞大的Excel表用于监控和追踪页面的所有UI润饰问题。开发人员根据准则将新功能实现到界面后，就会在Excel表格中将状态改为“已实现”。之后UX设计师进行测试，再将状态改为“通过”或“不通过”。刚开始的时候参与的人都觉得不太适应这个新流程，但几周后就进展得越来越顺利。 我们每周都会发布一份报告，将每个应用程序模块里的UI润饰测试结果汇总。通过这个周报我们可以很清楚地看到哪些区域的进展与原计划一致，哪些不一致。它是一个很好的工具，既客观地显示了每个应用程序区域的进展又给负责不同模块的团队制造了小小的竞争。最后，我们执行并测试了上千个UI润饰问题，测试覆盖率达到了100%。这对整个组织而言都是一个巨大的成就。 通常情况下，UX设计师都不会从事这方面的工作，但我们的UX团队花费了一半的精力去完成它。然而，我们的努力是值得的！这个项目也同时让我们与开发人员的关系更近了一步。而且，人们对UX团队的信任也借此得到了提升，因为我们顺利地解决了问题，也踏踏实实地做了很多具体的工作。有时候为了达到你的目标，你得下定决心做些不一样的事。 你所在的公司并没有把UI问题摆在合适的优先级？如果这样，以下是我给的一些建议： 将这些问题披露给管理团队和组织。 为解决问题准备充足的预算与时间。 渗透—积极推动项目进度，不断让管理层看到项目的进展。 找到合适的人参与其中。 确立一个好的执行计划。 坚持到底！ “分担痛苦篇” 第二阶段开始的时候，第一版的SAP Business ByDesign面市。我们在纽约举办了一个大型午餐会，邀请用户上台分享这个创新的解决方案是如何帮助他们改善业务的。真正的用户越来越频繁地开始使用我们的系统。我们做了很多现场观察，了解用户如何使用我们的新解决方案。大多数用户都很大方，给予了很多帮助。他们准许我们录下他们实际的操作过程。观察用户使用系统的真实情况可以帮助解决方案经理、UX设计师、知识管理部门经理以及开发人员更清楚解决方案需要改进之处。 一位在人力资源部门工作的女士负责招聘员工。她50多岁，在这一行业积累了丰富的经验。她的任务是把一名新员工的劳动合同的信息输入系统，同时还得保证效率。然而，系统却没法按照她习惯的操作方式帮助她完成工作。 当输入完员工具体信息后，她切换到下一个操作页面，需要输入合同有效期限。她看到屏幕上出现了有效期这一栏，“从”某个时间“至”某个时间有效，这两个都是必须填写的。“从”这一栏系统显示了当前时间。而“至”这一栏系统显示的是“31.12.9999”。它表示合同永远有效，她对系统给出的这个日期比较困惑，所以她把“31.12.9999”删掉了。接着她收到了一个错误提醒，说她需要输入一个日期。因为这一栏是必须填写的。她让系统的反应完全搞晕了。然后她又重新输入了正确的日期，最终顺利进入到下一个页面。这个操作花了不少时间，房间里有人为此忍不住笑了。终于，填完了下一个页面后她把所有信息都输入了系统，本以为这样就可以保存数据了。但系统只弹出了一个“错误”框，没有任何解释。她完全迷惑了，然后关掉了界面。 这时那些在看录像的人沉默了。有人说他之前压根没想到这会引起这么大的问题。也是在这一天，高级管理层再一次意识到了用户体验的重要性，有必要把它作为开发团队关注的焦点问题。两天后，系统的这一问题得到了解决，因为要解决它其实花不了多大工夫。执行了这个修正后，使用这个界面的用户，特别是那位女士，对此都十分满意。 一个图片、一段视频要胜过千言万语！人们需要了解用户是如何使用系统的，他们遇到了什么问题。然而准备这样一段视频来说明你的观点也要费很大的工夫，所以你只能选择那些重要的案例。但是通过录像人们可以感受到用户的情绪，体现了用户体验设计的价值。这是PPT上的一个列表无法传达的感染力。 “UI流程改进篇” 从一开始我们就在组织上下强制执行以用户为中心的设计。大部分事情进展得很顺利，但我们也发现一些需要改进的地方，改正后可以让整个流程更加高效。 第二阶段初期，我们成立了一个由UX设计师和解决方案经理组成的小团队，让他们分析目前流程中存在的问题并提出一些改进的建议。这么做很值得。他们发现了一些问题，主要有以下几种类型：质量关注度、用户参与、用例定义、“一个团队”路线、团队角色定位、UI验证、原型制作和UI工具。团队为每个问题提出了改进的建议，并且说明了实施这些变化的好处。 他们把这一结果展示给解决方案管理部门的高级副总裁（Senior Vice President，SVP），他很喜欢这些提议并帮我们推动它们的实施。然后团队又把这些提议展示给开发部门的SVP，也得到了他们的支持。我们决定开展试点项目，验证我们的流程改进提议。 试点项目的效果很好，UX部门以外的其他人也对以用户为中心的设计和我们的流程改进建议给予了肯定。这里我列出了一些解决方案经理和开发人员的评价。 公司决定实施以实地调研和用例为导向的解决方案定义流程，这种办法投资回报比高得让人难以置信。 “一个团队”路线能更快、更高效地产生出技术可行的设计方案。 解决方案规划图和用例让我们在项目初期就能保持对需求理解的一致，快速、高效地设计出线框图。 当时负责这块内容的执行董事也很喜欢我们的想法和方式。他让我和一位开发副总裁负责定义以后的开发流程。此后，开发流程改进成为了ByDesign管理团队的主要议题，我们也得到了许多关注与支持。 让两个人（一位来自开发团队，一位拥有UX背景）共同推动开发流程是个明智的决定。为了让所有的利益相关者参与到项目中，我们确实花了一些时间。解决方案管理团队、UX团队、信息管理团队、翻译团队、开发团队、运营团队和服务部门的人都需要参与到流程设计中来。 我们从这次经历中学到的最重要的一点就是：UCD流程并不是独立于开发流程存在的。 相比于将UCD活动和产品开发流程分两套文档描述的办法，我们只有一套产品开发流程的描述文件，其中无缝整合了UCD活动和产品开发流程的相关内容。这样一个小改动有助于我们把UCD设计流程更好融入到我们的组织中。在此之前，很多人都认为UCD设计只是从事用户体验的人才需要做的事。我们都知道这种看法是错误的，但是组织中的确有很多人持有这种观点。我们将两个流程描述文件合二为一。组织中所有的人都在用相同的流程文档、模板和用例。像用例、线框图这样的UCD元素在项目中都被定为交付的必要项。大家渐渐了解用例不只是对UX团队重要，其他团队也需要通过它来了解解决方案想要达到的效果。 所有的需求（包括UI需求）都要记录下来并排列优先级。UI相关的需求要通过线框图和UI规范文档来描述。 他们是开发团队执行的基础。单个应用程序层面的UX设计师不需要再描述UI模式的具体交互模式，因为我们在UI设计风格指南里已经系统地描述过了，而且UI模式也在开发工具中体现出来。应用程序的UX设计师只需要描述和应用程序相关的那一部分UI模式，例如，表格要用哪一列、要用UI模式中的哪一个配置选项（例如在表格中预设多少行可见）。 确定了流程描述文件后，我们让所有的利益相关者都看了一遍，这花了我们一些时间。等到大家都通过后，管理团队正式通过了这一新流程并决定从下一个版本开始执行。这对我和UX团队而言是一个巨大的里程碑。我们又发挥了自己的影响力，推动组织进入下一阶段的流程。为了定义这么一个端对端的流程，我投入的精力比预期要多出许多。其中，UCD流程只是整体项目中的一小部分，为了完成项目我还得处理信息管理流程、翻译流程和运营执行流程的问题。尽管这些远远超出了UX团队的职责范围，但我觉得我们的努力是很值得的。 在第二阶段，我们更深入地将用户体验制度化了。组织上下对用户体验的认识加深了, 我们还把以用户为中心的设计流程成功地融入到整体开发流程中。此外，在UI润饰项目中的紧密合作大大拉近了UX团队与开发团队的关系。开发人员遇到UI设计相关问题的时候，他们会主动找UX设计师探讨。第二阶段接近尾声时，产品的可用性KPI值达到了6.8分（满分10）。与第一阶段末期的4.8分相比有了大大的改善。 2.4.3　第三阶段：开始精益软件开发 我们在第二阶段做出的改变大大提升了流程效率，同时改善了解决方案的用户体验。第三阶段的目标是进一步改善流程，让组织运转更有效率。我们决定让整个组织向精益软件开发（Lean Software Development）转型。我们把精益开发初期阶段的一些核心概念和Scrum概念引入开发部门。我们必须找到一个更加实际的方法，调整精益软件开发让它更好地与UCD流程融合，在利用精益软件开发的优势的同时，精心引入用户参与的环节。这需要UX从业者重新思考过去的做法，重新调整用户体验方法论，让它更顺利地融入到整体软件开发流程。 我们在第三阶段做出的最重要的改变就是“一个团队路线”（one-team approach）和“共处一室”（co-location）。当负责不同领域的团队在一个工作地点甚至在同一个房间工作时，他们的效率是最高的。与要解决的问题相关的团队成员都聚到了一块，其中包括解决方案经理、UX设计师、技术文档开发人员、开发架构师、开发人员等。这不仅给了团队更多的灵活度，也加速了决策流程。团队对问题有了共识，并且一起完成了用户研究。通过这种方式让原本来自不同背景的人有了共同语言，沟通起来就简单多了。 我们还引入了待处理需求列表，列出下一软件版本要优先解决的问题。需求列表里所有的待处理项是按重要度降序排列的。每个版本都会有一个这样的列表，这让资源分配的决策变得更透明。在资源有限的时候，特别是用户研究员和UX设计师人手有限时，大家就能轻松决定应该优先做哪个项目。团队还可根据列表的排名决定哪个议题需要大量的客户和用户验证。 引入Scrum后给UX团队带来的主要挑战是它的开发周期很短。我们的开发冲刺（sprint）是两周，所以开始新设计的时间很短。同时，我们进行最终用户验证可用的时间也比以前更短了。如果我们希望将某个可用性测试的用户反馈加入到下一冲刺的待处理项目列表中，我们分析测试结果、提出改进建议的速度就必须很快。 弥补冲刺周期太短的方法是引入一个专注于需求和设计的零冲刺阶段（zero sprint）。零冲刺的周期通常是2～4个星期。这让团队成员在代码编写开始前能有一段时间规划更高层面的总体设计，但如果要进行可靠的实地调研、市场研究和用户研究，则零冲刺需要更多时间。你需要有一个足够长的产品定义阶段来进行用户研究和完成任务的高层面的总体设计。为了避免代价高昂的后期改动，总体信息架构需要在开发团队开始编码前完成。细节设计可以安排在开发前的一个冲刺或者更早，但我们也要保证设计留有一定的自由度，因为它还需要根据与开发冲刺并行的用户验证冲刺的结果做调整。 在第三阶段，我们不仅改善了开发流程，还改进了UI开发工具，以便更好地融入UI准则。 “UX规则篇” 在第2阶段的UI润饰项目中，我们花了大量的精力对已实现的用户界面进行测试和质量检查，大大改善了用户界面的质量以及它与UI准则的一致性。然而，我们为此付出了许多人力物力，这次我们想换个做法。 我们一直在想怎样才能提高组织在这方面的效率，于是就有了“UX规则”。 我们已经成功地把UI模式融入到开发工具中以保证一致性，但UI模式仍需要给开发人员留有一定的自由度。许多UI准则只是建议，我们无法将这些准则用硬编码写入开发工具。我们还给开发人员提供了UI风格指南，向他们解释什么时候要用什么UI模式，还解释了那些无法用硬编码写入UI模式的UI准则。 我们很清楚大多数开发人员都不会细看UI风格指南，有些甚至可能从来都没看过。最后我们总结出：我们必须想办法把UI准则也融入到开发工具中。如果你看了UI 风格指南，你会知道UX规则有两种：硬规则和软规则。硬规则是所有应用程序开发人员都不能违背的规则。以我们的项目为例，每个屏幕都需要有“关闭”按钮，开发人员不能省略这个按钮。软规则实施起来难度更大。举个软规则的例子，每个表格不得超出7列。没错，有时候确实存在多出几列会更合适的例外情况，但你得把它们当成例外来对待。 为了更好地说明我们是如何把UX规则融入到开发工具中的，我需要先解释下UI开发工具是如何运作的。UI开发工具是基于模式并由模式驱动的工具。开发人员开始搭建界面时必须先选择要使用的UI模式。他还需要实现业务逻辑、查询、后端服务。例如，在UI开发工具中，开发人员必须确定哪些查询是用户可用的，哪些字段要在表格中显示，哪些字段要在预览区域显示。这一过程通过配置完成，你也可以称之为UI建模（UI modeling）。界面和后端数据在逻辑上是完全分离的。开发人员要做的就是把内容排到模式中，然后把UI与后端连通。上述配置在设计阶段就完成了。UI配置和运行阶段（runtime）是分开的，这样带来了更多的灵活度，并且可以很容易就切换到另一种运行环境中，并使用另一个UI技术。UI模型存储为XML格式，因此我们可以开发一套工具去检验XML文档，查看它是否遵循了UX规则。这种办法应用在对软规则的检查中。 我们的一名开发人员开发了一个引擎，该引擎能够检测应用程序开发人员创建的UI模式（XML）是否违反了UX规则。一旦发现了违规，开发人员就会在开发工具中收到一条警告消息。他可以选择改正模式让警告消息消失，也可以点一下按钮说明此处是个例外。所有的例外情况都会汇总到记录中，因此我们就能看到哪些规则的例外情况最多。这说明UI风格指南中的对应规则可能需要修改。发给开发人员的警告信息还包含了一个维基页面链接，解释为什么要遵守这一规则。点开这个链接后，开发人员还可以进入到UI风格指南里的对应章节了解更多信息。将规则融入到开发工具、在工具中加入UI风格指南链接，有助让开发人员更加关注UI准则。 我们从UI风格指南中总结出了大概300条规则，并把它们归类为“硬规则”和“软规则”。这些规则的质量必须是完美无瑕的。显然，如果开发人员收到的警告消息完全没有意义，他们就会认为这个工具不好用，并降低对该工具的信任度。我们引入规则时必须经过深思熟虑，并且在大量真实的UI模型中测试UX规则。 我们把部分UX规则融入到开发工具中，并给ByDesign管理团队展示开发人员如何在开发环境中使用UX规则。他们很喜欢这种方式，并让我们继续这一项目。我们在应用程序开发团队的一个模块中进行了试点项目，看看开发人员对UX规则的接受程度如何。试验的结果很好。随后我们把越来越多的规则融入到开发工具中，进行大量的测试后发布给开发人员。UX规则有助于提高解决方案的质量，最后还帮UX团队和开发人员省去了许多人工测试的麻烦。 我们最后终于让管理层认识到UX规则也应该成为评价软件版本KPI的正式指标之一。如今开发人员必须先解决所有违反UX硬规则的地方，然后我们才可以把软件递交给客户。这对UX团队而言又是一个里程碑，我们又向用户体验制度化迈出了巨大的一步。在第三阶段结束的时候，可用性KPI得分是7.3分（总分是10分）。与第二阶段结束时的6.8分相比，我们又提升了产品的用户体验。 2.5　主要经验与建议 经历了项目的各个阶段，我们知道了哪些实践是可行的，哪些需要改进。这曾是一个不断学习的过程，如今我们依然还在学习。 本章中推荐的大部分UX实践对你和你的公司应该会有所帮助。但有些实践更适合在流程更复杂的大型公司和全球性组织中执行。你可以听取一些我们的建议，试着在你的公司中执行。你将会知道哪些实践经验是有用的，哪些需要根据自己的实际情况做调整。 2.5.1　关于扩大对技术影响力的建议 明确UI需求的优先级　从客户和用户的角度考虑UI需求的优先级。运用用户研究数据和最终用户UI验证结果证明优先级的正确性。 让UI需求变得简单易懂　决策者需要理解UI需求。通过截图表达视觉效果，使用简单易懂的术语。如果你的需求是从可用性测试结果中发现的，还可以播放一段用户界面令用户抓狂的视频，只需要截选亮点即可。 为UI架构团队提出需求　在为UI架构提出需求的过程中，用户体验团队应该处于领导地位，并需要强力表达自己对于需求优先级的意见。UI架构团队是技术团队的一部分，负责搭建应用程序开发团队制作用户界面时使用的技术平台。例如，UI模式就是由UI架构团队开发的。 汇报UI需求执行的进展　经常向管理团队汇报UI需求的执行状况。当改进成果可发布时，向管理层展示成果。 与UI架构团队建立良好的个人关系　在用户体验团队和UI架构团队之间建立稳固的协作模式。如果你与UI架构团队建立了良好的个人关系，他们会更愿意协助你实现那些能够改善用户体验的UI需求。 为每一个真正用户的需求尽力争取实现　你必须争取实现每一个能够提升用户体验的需求。仅仅是把需求放到列表中，指望它能够按照你希望的方式实现，这是行不通的。你必须争取实现每一个需求，而且如果你的目标设计无法实现，你应该提出另一种可行方案。 建立合理的模式库　模式库里的样式数量应该足以让应用程序层面的设计师和开发人员可以选择以满足使用用户界面的用户的任务执行需求。 将UI风格指南融入开发工具　将UI风格指南融入开发工具中有助于显著提高产品质量，提高开发流程的效率，所以有必要让UI模式成为UI架构的一部分。基于模式的工具可以保证设计与开发的一致性和全面性。UI风格指南里的规则应该分为“硬规则”和“软规则”。“硬规则”可以用硬代码写入开发工具。“软规则”有时候只是建议或最佳实践。这些规则在90%的情况下都是可用的，只是有时候可能有些例外。把这些“软规则”融入到开发工具中，如果开发人员在开发过程中违反了某个规则，则系统会给他们发提醒信息。如果这一违规是有意的，开发人员只需要标记上“例外”的标记就可以继续工作了。如果此处并不是个例外，他可以马上解决该问题。UX规则拉近了UI风格指南和开发人员的距离。 规划好UI架构的迭代　落实用户需求以优化UI模式是一项富有挑战性的工作。你必须为开发过程中的迭代预留出足够的时间。通过最终用户测试已实现的模式，并不断改善模式。 邀请开发人员参与可用性测试　开发人员需要接触真正的用户，观察用户在使用软件时的感受。 引入自动化UI测试　自动化UI测试可以空出人力去完成更有成效的工作。自动化测试应该用于回归测试（regression test）。这有助于提高产品质量。3 2.5.2　关于扩大对组织和人员影响力的建议 获得最高管理层的认同　你必须让最高管理层认识到以用户为中心设计的价值，才能够获得足够的资源和预算。如果你无法做到这

書城介紹　 |　合作申請　|　索要書目　 |　新手入門　|　聯絡方式　 |　幫助中心　|　找書說明　 |　送貨方式　|　付款方式	香港用户　 |　台灣用户　|　海外用户
megBook.com.tw
Copyright (C) 2013 - 2024 （香港）大書城有限公司　All Rights Reserved.