当用户体验设计遇上敏捷

A Digital Designer's Guide to Agile, Lean,and Continuous

陈宗斌　译

北京

图书在版编目（CIP）数据

当用户体验设计遇上敏捷/（英）拉特克利夫（Ratcliffe,L.），（英）麦克尼尔（McNeill,M.）著；陈宗斌译.--北京：人民邮电出版社，2013.4

ISBN　978-7-115-30551-0

Ⅰ.①当…　Ⅱ.①拉…②麦…③陈…　Ⅲ.①网页—设计　Ⅳ.①TP393.092

中国版本图书馆CIP数据核字（2013）第003383号

当用户体验设计遇上敏捷

◆著　［英］Lindsay Ratcliffe　Marc McNeill

译　陈宗斌

责任编辑　赵轩

◆人民邮电出版社出版发行　　北京市崇文区夕照寺街14号

邮编　100061　　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

北京天宇星印刷厂印刷

◆开本：880×1230　1/24

印张：12.5

字数：256千字　　2013年4月第1版

印数：1-3000册　　2013年4月北京第1次印刷

著作权合同登记号　图字：01-2012-5026 号

ISBN　978-7-115-30551-0

定价：49.00元

读者服务热线：(010)67132692　印装质量热线：(010)67129223

反盗版热线：(010)67171154

广告经营许可证：京崇工商广字第0021号

版权声明

Agile Experience Design

ISBN: 9780321804815

Lindsay Ratcliffe, Marc McNeill

Copyright Ó 2012

Authorized translation from the English language edition published by New Riders. All rights reserved.

本书中文简体字版由美国New Riders出版公司授权人民邮电出版社出版。未经出版者书面许可，对本书任何部分不得以任何方式复制或抄袭。版权所有，侵权必究。

内容提要

用户体验设计对于互联网产品及业务的成功至关重要，而使用敏捷方法进行产品的设计与开发是通向成功的捷径。本书以实践为基础，完整地展示了互联网产品设计如何与敏捷结合在一起，从而带来更好的用户体验。

本书分为三个部分：第一部分介绍了什么是敏捷。即使读者对敏捷完全了解，仍旧值得读一读这部分内容；第二部分介绍了项目过程，并探究敏捷框架中的体验设计技术，以便帮助读者完成和交付伟大的体验设计产品；第三部分是工具箱，读者可用它作为工具和技巧的快速参考指南，以及在敏捷环境中使用它们。

本书主要面向在敏捷环境中工作的体验设计师、产品经理、开发人员。测试人员或者业务分析师也可从本书中受益。

序

在一个富足而丰盛、却被白领工作的自动化和外包所扰乱的世界里，每个人，无论职业如何，都必须培养艺术感知力……今天，我们都必须成为设计师。

——Daniel Pink，A Whole New Mind

随着敏捷运动进入第二十个年头，它必须继续革新并适应新情况才能保持其实际意义。由Lindsay Ratcliffe和Marc McNeill所著的本书延续了敏捷革新。它将设计重新带回了软件交付等式中。“但是，但是”，敏捷人可能会说，“我们是做设计的。”但Ratchliffe和McNeill谈论的不是模块设计或者数据库设计，而是产品设计、平面设计、体验设计，等等。这是那些“难以定义，但我看到的时候就会知道”的东西之一。就如作者所说的，伟大的设计会带着吸引人的体验嫁给合人心意的产品，就如在苹果iPhone和iPad上看到的那种组合。

早期的敏捷运动是对瀑布开发问题的反应：角色的分裂、成堆的文档和极少的文案。给瀑布问题的解药包括以短小的迭代来工作、减少角色的扩散、削减文档以及促进全面合作。但随之而来的是，专业人才不再是主要问题，协作才是。随着敏捷运动的成熟，我们将专业人才加入其中，将他们集成到敏捷团队中。这不是说“杂家”不再那么有价值，而是在我们复杂的世界中，在特定领域仍旧需要专业技能。

在上一个十年中，另一个趋势是以不同的方式展示“敏捷不能为、也不能与xyz一同工作”这句话是错误的。大型项目、分布式团队、以数据库为中心的产品、过时的系统集成、非绿色领域开发、特殊技术和诸如用户界面和体验设计实践这样的问题都被革新的敏捷人所解决。

本书通过展示体验设计与敏捷产品的集成方法以及设计师如何与敏捷团队配合来延续这一趋势。本书深入研究了设计的许多方面以及它们如何与为用户创建吸引人的体验相结合，并且将设计的关键问题既带给设计师，也同样带给非设计师来考虑。

因为，用Daniel Pink的话说，“今天，我们都必须成为设计师。”

Jim Highsmith

《敏捷项目管理》作者

致谢

感谢所有对本书有所贡献的人。我们尤其要感谢那些创建并贡献了原始文字和图片材料的人士。我们也要感谢那些允许我们将他们的想法、工作、产品和照片用在本书的每个人，也感谢那些在出版本书过程中给我们反馈信息的每个人。非常感谢 Peachpit团队，他们在这个高强度的过程中给予了我们支持并且帮助我们让这本书付梓！

Lindsay ：要特别感谢丈夫Guy Ratcliffe，没有他什么都没有可能。你的爱、支持和不断的鼓励让我美梦成真。感谢我的“小家伙”，即使在压力很大的日子里，你依旧能融化我的心。感谢我的爸爸，您一直对我充满信心。想起您的微笑总让我心暖，我会永远想你。感谢我的妈妈，您的力量、坚持不懈和毅力一直激励着我。感谢我的兄弟，你对美好生活的不懈追求让我心生敬畏。感谢Marc McNeill，感谢你对所有一切事物永不熄灭的能量和热情。感谢分享这一旅程的人——我们组成了一个伟大的团队！感谢Hubertus B和StakenKidney，你们是我永远的良师益友。感谢PufaSistas，BitchnCharmer的另一半，我永远感激你的帮助。感谢Andrew、Sarah和Shane，你们是影响和激励我的人。感谢Claire和我其他的“EastTwick(enham)的巫师”，你们的支持和友谊是无价之宝。我还要对我所有的好朋友和ThoughtWorks的同事大吼一声，你们激发了我对设计、用户体验和技术的鲜活见解，并且对我们的写书过程给予了支持。

Marc ：感谢Graham Donaghue，感谢你让我来写这本书，也要感谢Luke Barrett的灵感和支持。感谢ThoughtWorkers的所有人，不管是过去的还是现在的，感谢你们耐心倾听我站在白板前手舞足蹈地对真正的用户的夸夸其谈。他们带我进行了一次敏捷的探索旅程：从以为“类”是我上学时的班级（译者注：类和班级是同一个词——class）开始，到对软件开发交付这一高尚艺术的敬仰。在这一群快乐的人中，我尤其要感谢Alex McNeil、Dan North、Luca Grulla、JM Domaingue、Prashant Gandhi和Diana Adorno。感谢我的合作者Lindsay愿意和我一起进入这一旅程。最后要感谢的是我的妻子Lindsey，感谢她对我的写作工作的耐心和理解。

第一部分 敏捷概览以及设计师为何要关注敏捷

第3章 我是设计师，这与我何干

“人们总是设计东西。人类最基础的特征之一就是制造各种不同的工具和其他人工制品来实现自己的目的。随着这些目的的改变……就有了精益……有时候全新类型的人工制品就会孕育、产生”。

——Nigel Cross，工程设计方法：产品设计的战略

设计师与此相干，因为敏捷蒸蒸日上，而这是一种完全不同的工作方式，要求用新的方法以及新的态度对待设计。

正在阅读本书的读者，可能是因为工作与敏捷相关，可能是进了一家新公司，而这个公司使用敏捷方法，也可能所做的工作采用敏捷。与许多设计师一样，读者可能之前对项目管理方法并不怎么关心，你可能对此不以为然。

你必须与此相干是因为，寻求更高效能和效率的项目交付方法的公司正在越来越多地采纳敏捷及其派生方法。我们需要理解敏捷与其他正在使用的方法的区别：这是一种涉及团队中所有人的方法，包括设计师，也包括开发人员。作为设计师加入敏捷项目团队中的结果，我们完成设计的方法也会有巨大的变化。如果不能掌握这一不同的工作方式，就难以顺应潮流。

不用抱有幻想，就如所有改变一样，一开始你会觉得有点不舒服，可能会有强烈的抵制甚至反叛感，你会想重回你原来所居住的安逸世界。我们自己在抵制、反叛、怀念从前。而围绕着过程迭代之后，我们可以给大家消除疑虑了。作为设计师，我们完成了向敏捷的转换，并且成为了其倡导者。我们有成功的故事，可以证明敏捷和设计可以快乐共存。

3.1 敏捷与设计矛盾吗

设计师注意到的关于敏捷的第一件事情通常是它没有设计阶段。敏捷项目一头扎入开发中，对设计师所信仰的设计是产品开发过程的重要组成部分这一理论完全不给面子。设计师所看到的是许多短得荒唐的最后期限，在这些期限上要交付可工作的软件，并且不对重要的设计活动的工作量和复杂性做任何考虑。结果，许多设计师相信设计会受到严重损害，于是直接就对此很排斥了。

敏捷公开宣称，它反对大量的前期设计，这听起来像是对设计的批评。这样的立场会让对敏捷不太了解的设计师感到不舒服。

让我们加入一些上下文，应用一些观点，并且揭示“敏捷中没有设计空间”这一流言的真相。

争论中大部分都与软件的前期设计有关，所以我们将首先快速了解一下这方面内容，然后探究如何将这些论点用在体验设计上。

3.1.1 软件开发中的设计

我们已经知道，敏捷是由于对软件项目交付方式的不满意而产生的。敏捷离开了离散的、顺序的、功能特定的方法，而采用跨功能的协作和并行工作方式。另一项基本改变是不再在实现任何价值之前将每件事都做得很彻底，包括设计在内。它的思想是只做刚刚好的工作，然后随着了解深入而精益。

这意味着传统上总是事先完成达到第n个程度的系统架构设计，是最先进行根本改变的内容之一。Martin Fowler在“设计死亡了吗？”白皮书中探究了“经过计划的设计”过程这个通常在建筑设计中遵循的做法，并且将其与软件架构进行比较。建筑师将设计绘制出来，在他们做这件事的时候，他们考虑并解决建筑设计的问题。一旦设计完成，就会递交给按设计进行施工的工程人员与建设公司。这也是软件设计的通常做法。在软件构建之前，软件架构师花费可观的时间来定义一个系统，而后才将软件设计规格说明书递交给不同的团队或其他公司来构建，这会造成以下两个主要问题。

■难以解决在设计阶段完成之后出现的设计问题。由于不可能提前想到所有问题，在后来的阶段中出现问题将不可避免，这时系统设计师已经转移到其他项目中工作了。

■软件架构师不再是开发人员。开发人员典型的职业生涯是从编写代码开始的。最终他们会毕业，成为软件架构师，然后就几乎不再写一行代码。考虑到软件开发技术的更新步伐，这就意味着软件架构师很快就会与开发方法脱节，在需要解决一些让开发人员焦头烂额的底层实现问题时不那么有效。

替代大量的前期设计的是演进式设计。一些死忠于这一方法（比如极限编程，XP）的人，相信大量的前期设计不应当存在。他们相信项目应当尽可能赶快开始编码，并且可以按需通过“重构”来解决设计问题。

3.1.2 体验设计的教训

这里的讨论强调在敏捷中对“设计”这个词的使用。在技术社区经常讨论并研究前期技术设计要多少才合适。那么，也可以对体验设计问一些相同的问题：

■与提前做所有的系统设计相比，提前做所有的体验设计是否更合理？尤其当我们知道并且接受这样一个事实：对建立良好体验产生影响的因素会改变。

■试着在产品发布之前让其完美，却延长了初始想法和业务开始得到投资回报的时间之间的间隔，这是否有意义？

答案是否定的。

如果认为体验设计是成功的关键，那么我们不认为项目应当从编码开始，就如我们不应该在建筑的概念得以探明之前就开始施工。

如果是这样，那么建筑工应当从哪个地方入手？砖头、砂浆还是基础结构？要是建筑师将建筑设计成玻璃与钢的结构或者使用圆柱形的形式又该如何？是否要把建筑工人已经完成的东西推倒，从草图重来？

仅创建刚刚好的前期设计做为开始，并且通过测试、学习和精益来完成设计细节是更为有效的工作方式。在前面所提及的那篇论文中，Martin Fowler以这样的建议来表达他对这一观点的赞同：

“为了让软件能工作，演进式设计需要有股能驱动其朝向某一个点会聚的力量。这股力量只能从人而来——团队中必须有人能做出决定，确保设计保持高质量”。

那么敏捷与反设计矛盾吗？它并不与设计相悖，而是反对任何浪费的或者不直接创造价值的东西。于是，我们不会在项目的早期阶段进行所有的设计活动，然后将输出结果扔给墙外的开发人员；而是要看看我们在哪些地方可以将浪费最小化、将价值最大化，并且不需要对设计的质量或者用户体验做出妥协。我们的做法是只做刚刚够建立设计愿景的思考，这个设计愿景可以测试与验证，而后以迭代的方式构建设计细节。

3.2 一个重大的设计挑战

IT负责满足业务对更高效、更有效的软件交付方法的需要并对此给出响应。如今，作为设计师，需要迎接挑战，重新对设计进行设计，将其带回到与数字产品开发一致的、快速的状态，并且将设计注入到敏捷过程中。我们要的是高效的、有效的以及带着愿景出现的设计，但我们也想创建让人为此埋单的、合心意的体验。

本书的任务有以下两个。

■帮助设计师理解自己在敏捷过程中的位置以及如何使自己的优势最大化。

■帮助项目管理者、开发人员和其他每一个参与软件交付工作的人理解设计的重要性以及设计在敏捷开发过程中的位置。

设计，其存在的目的是为了影响用户的感知和行为，在传统上已经落入业务（更具体来说就是市场部门）的范围内。然而创建了敏捷过程的是软件开发人员，所以到目前为止，大量关于敏捷的书籍文章资料都出自软件开发人员之手，为的是达成创建更好的软件这一目标。

提示

在敏捷环境中进行设计的时候，给你的第一个重要提示就是，你需要为产品/服务创建一个有根有据的愿景，随着设计细节在项目剩余的部分渐渐浮出水面，这一愿景将用于指导设计细节方向。

敏捷不是要特别地排斥设计，也不意味着设计和设计师的角色对过程不重要。而是到目前为止（在本书出版之前），还没有人真正讲解设计及其在敏捷项目中的角色。

体验设计就是解决问题，这既需要逻辑的、分析的思维，也需要创造性的设计思维。

当我们将问题解决方法分解开，我们可以看到它由许多组成部分，由许多相关的而且互补的活动组成。这些活动可以因背景、设计师和设计挑战的不同而不同，而过程是可重复的。

我们首先来看业务和最终用户的需求和背景。我们来了解解决问题、获得反馈以及将想法精益成一到两个，从而可以越来越详细地探究不同方法。无论是在瀑布还是在敏捷环境中工作，这个总体过程都是一样的。主要的不同在于，在瀑布中所有上述内容都是在单一的项目阶段中由设计师们独立工作完成的；而在敏捷项目中，这些活动分散在项目中，而且是协作完成的（图3.1）。

敏捷从业者建议直接编码，并且以最快的速度交付可工作的软件。然而，可工作的软件并不意味着结束。如果软件既不能给业务、也不能给最终用户带来价值，那么就只是一堆无用的代码。所以，我们在进入设计细节的开发时，要确认有个有根据的、经过深思熟虑的愿景。

对于正在开发中的产品或服务，愿景是其基础和框架。

愿景不仅指导开发方向，也让开发保持正轨。我们欢迎有根据的改变，但不欢迎随机凌乱的路线。

在敏捷项目中，愿景的创建有时候会被忽视，这经常只是因为许多敏捷项目管理者只有技术背景，但不熟悉以业务或设计角度来看产品开发过程。而这是这一过程的关键部分，只要是用户体验对成功至关重要的项目都必须将其包含。如果没有时间来考虑业务和用户环境，进而使用这些信息来形成设计愿景，那么设计师的交付过程将会十分坎坷。

与能够以独立的小块来开发的故事不同，一小块一小块的设计之间必须完全互相依赖才能创建出全面、一致而且动人的体验。这不是偶然的。在喂饱一群饥饿的开发大军之前，要先把饭菜做好。

再次强调，这不是大量的前期设计。设计愿景只是完成足够打基础并且设置好清晰的方向的工作。即使Martin Fowler也同意：

“人们都认为我是个胆小的极限编程者（XPer），但我对此不敢苟同［关于直接进入编码细节］。我认为得有一个负责广泛的、开始点的架构的角色”。

于是挑战在于，在设计的时候理解哪些工作是刚刚好的，以免又犯了过早创建过多细节的老毛病。我们将在第7章中详细探究这个问题。

3.3 设计的适合之处

以下这张可怕的图片是一位设计师描述的构建一个网站时所需的步骤（图3.2）。

看看上图中创建者给每个活动所定的时间框以及重要性。对于具体的活动，我们没有问题。实际上我们稍后会深入讨论它们。但我们知道对于敏捷者来说，这张图很成问题，因为他们看到只有八分之一的时间花在编码上的时候说不定都会被咖啡呛到。这就相当于，在项目的每八个星期中，只有一个星期用于开发。

没有内容和开发的设计，不比没有价值的抽象概念好多少，除非赋予它生命，供人使用。

设计师可能反对这样的论点：不以以用户为中心的方法来设计，开发人员或许可以构造出网站并且填充其内容；但如果不能吸引用户，那么就等于没有价值。

那么谁是正确的？都正确！但要是结合起来，这两个观点将有力得多。真实的价值是由能够交付以用户为中心的、有效的、可用的、吸引人的、合心意的、体验的可工作的软件来实现的。

大多数设计师在第一次接触敏捷时会提出的问题是，“设计适合于何处？”在任何敏捷项目计划中都没有被称为“设计”的阶段，因为项目中的活动更为集成化。敏捷项目的成功关键元素实际上是集成和协作。

成功的设计并不是在一个单独的阶段中完成，也不是在真空中、甚至由设计师独自完成的。设计需要集成在所有项目的内部要素和外部要素中来考虑。设计也需要是个持续的活动——从项目的开始（甚至在项目启动之前——以后会提到更多）直到整个项目的生命周期，甚至超过这一周期。

敏捷团队是跨功能的：每个团队成员都从其功能领域向项目贡献知识财富。敏捷项目环境使设计师得以利用跨功能的智慧，并将其作为设计灵感的来源。

所以，对于设计适合什么地方这一问题，有两个答案。如果对设计和敏捷有个开放心态，那么这两个答案读者都可以采纳并且为之所用：

■在需要的时候；

■在整个过程中。

3.3.1 在需要的时候进行设计

有适应能力的敏捷，借用精益制造方法来避免在不需要的时候可能造成浪费和物品囤积。

别浪费太多时间来等待设计要求，而应该将自己放在一个正确的位置上，以便在要求真正来的时候能够快速反应。

这意味着要采用诸如“准时制设计”（just-in-time）和“刚刚好”设计这样的原则。准时制设计就是按着罐头盒上标明的来做。我们不会提前数月甚至数年来设计，而是在识别出一个需求之后立即进行设计。我们之所以这么做是因为，在目前，变化是驱使我们寻求在每一个舞台上对市场需求作出响应的方法的持续而残酷的、不可战胜的力量。市场的过去和现在都在要求变化。

用户对于变化的要求是傲慢的、没有耐心的——他们要的是更便宜、更快、更好。

用户不愿意等待任何事情。在对舒适方便的追求上，他们已变得反复无常。他们只忠诚于那些能够马上给予其满足的品牌，而对不能按他们的想法交付产品的品牌会起眉头。在想要却得不到满足的时候，他们移情别恋的速度和改变主意的速度一样快。

方便食品开启了人们追求便利的趋势，但它也影响了其他每一个消费市场。数字产品可能是最无法容忍延期的，因为没有有形的制造过程可以用来作为延期的理由而得到谅解。

这就是我们不去做大量前期的设计的主要原因。在大量前期设计进入市场的时候，市场已经转入下一个热点，不会有人再来买我们的产品了。在对市场的响应方法上，我们必须变得更为灵活、更为敏捷。

“80%准备好意味着可以上市；100%准备好意味着过时”，在最近的一次用户体验会议上，Humana Health Care的用户创新主任Tony Tomazic如是说。

我们当中的许多人在或者为大型公司企业工作，在这样的企业中有许多过程用于保护组织、减少风险，并且让所有的工作协调运行。所有这些官僚作风都会给过程增肥加重，使得完成工作会更费时费力。这时我们要另想他法。我们不能用一只手就想驾驶一艘油轮朝不同方向开，而是要在海洋上放入许多快艇来试水，了解前方的情况。我们需要能够以如刚开始运作时的做法那样来思考和行动的能力，这也意味着需要分清楚什么时候需要设计，而什么时候不需要，以及要设计出多少才合适。如果我们正在启动“我也有”类型的产品，这时市场已经对此深知而且设计模式相当成熟，我们就不需要花费数月时间来研究如何重新造轮子，因为我们已经有一个能够工作得相当完美的轮子了。在这种情况下，我们只需做足够的学习工作来理解设计，然后采用、调整它即可。

对于新市场中的新产品，我们或许可以在设计上多花一点时间，但仍应尽快将产品投入市场，这样我们就可以一边赚钱、一边测试、学习和精益产品。

3.3.2 在整个过程中进行设计

设计不是我们经历的一个阶段。它不应当是执行、然后获得批准，以便继续前进的东西。

设计从项目的开端开始，甚至在项目开始之前就开始，然后贯穿整个项目生命周期，并且在产品发布后很长时间还在持续。

我们将在下面几个章节中对敏捷项目过程以及设计工作在此间的情况进行更详细的介绍。现在，我们将对设计在敏捷项目中的进行方式做个概括性的介绍，尤其要指出最终用户体验对业务成功的关键所在。

以下列出的内容描述了开发产品或服务所需进行的大体活动，但没有考虑阶段和命名规则问题（图3.3）。

■理解为什么我们在做这件事情：查看业务问题/机会空间。

■理解我们为谁做：能从这个问题/机会的解决方案中受益的用户。

■考虑设计的挑战是什么：并且建立多个可能的解决问题或者适合此机会的想法。精益这些想法，按经验公式挑出最适合的候选者。

谋无术则成事难，术无谋则必败。

——孙子，《孙子兵法》

■扎进如何创建这个产品/服务的愿景中，产品的剩余部分将要以此为基础来构建。

■在并发的设计和开发准则下执行此愿景，使用该愿景来指导设计细节，而细节的出现会贯穿产品整个生命周期。

通过确保我们理解产品开发过程中的“为什么、谁、是什么以及怎么做”，我们就有了一个坚定的立足点，可以让我们满怀信心地前进。要记住，我们只需在这些问题上花费“刚刚好”的时间就可开始。

一旦进入项目的开发周期，设计就会与其他项目活动并行前进，而不是按顺序发生，这样可以带来更好的跨功能协作。设计师必须记住，设计会影响项目的其他功能问题中的大多数，反过来设计同时也会受其影响。要想真正获得整体上的成功，必须在开发设计的同时也考虑其他功能（图3.4）。

3.3.3 体验战略

我们了解了体验设计适合于敏捷项目的哪些地方，但我们还需要了解它在大型组织的生态系统中适于何处。在重视用户体验、认为其是一种战略性需要的企业中，它是连结业务、品牌以及体验战略要素的准线。

任何战略都是给出一个游戏计划：首先要展望目的地，要清晰地表达出成功将会带来的价值和利益是什么；而后要了解自己的当前位置，自己有什么样的武器可用；然后创建一个计划——一个能扬长避短的计划，它将带你从当前位置前进并到达目标。历史上的任何一个好领导都会告诉你，成功和失败、赢和输的区别就在于战略。

体验战略必须与整体业务战略对齐，它也应当与其他战略计划紧密互联，包括品牌战略在内。我们来快速看一看这些都代表什么（图3.5）。

3.3.4 业务战略

战略勾画出的地盘是要让一家公司与众不同。

——Michael orter，战略专家有竞争力企业

业务战略是公司的首要愿景，它是业务存在的根源。它的存在是为了确保长期的可持续性成长。业务战略包括核心价值、任务以及组织的目标，它是核心竞争力和奉献（offering）的基础。

3.3.5 品牌战略

品牌战略受业务战略驱动，通过了解潜在用户的需要、期望和动机来创建吸引人的、动人的提案。品牌战略通过品牌标识（名称、图标、颜色、形象）来表达，它既形成和影响组织内部和外部的代表方式、产品和服务。

3.3.6 用户体验战略

公司的品牌就如人的名声。名声得通过试着将难事做好来赢取。

——JefBezos， Amazon.com创始人

用户体验是用户参与的活动、事件和交互之和，它会刺激情感上的响应、形成感知并最终影响消费者行为。

用户体验战略定义组织及其用户之间的关系和交互。这些关系和交互跨越所有的交互、触点和渠道。用户体验是个整体的、跨功能的计划，要求在组织内部得到跨越许多原则的认同和支持，并且与其他战略计划紧密相连。

3.3.7 数字战略

数字战略决定的是，用户通过访问互联网，对企业的数字呈现（digital presence）有怎样的体验。

数字战略包括理解数字用户（会与其他离线用户不同）、公司网站、可移植性和可移动性、数字营销、数字和社会关系管理以及数字渠道的衡量和分析（图3.6）。

本书的大部分探讨在敏捷框架内如何设计数字产品。不过，对于数字战略在更广的环境中适应于何处，我们也想说一说。因为用户并不关心组织结构和渠道，他们会自由地在线上、离线触点等渠道间转换，并且期待有一致和整体的体验。

作为数字设计师或者产品拥有者，理解公司的整体目标，确保所创建的任何东西都在战略上保持一致是至关重要的。所以，考虑在敏捷项目框架中的数字体验设计时，也要考虑如何能够影响组织中的其他战略计划，以及这些战略计划如何影响体验设计。

3.4 谁是设计师

在探讨设计与敏捷的细节之前，我们首先来定义一下“设计”的含义，并且了解一下传统上做设计的都是什么人。到目前为止，我们所指的设计师都是大家常识中的。这很危险，因为非设计人员经常会认为所有的设计师都是一样的，并且每个设计师都可以完成和设计有关的一切。设计师多种多样，有些是全才，而其他人则是专攻一个方向。为了保证大家都说相同的话，我们来探究一下不同的设计角色及其各自的技能集（图3.7）。

■用户界面设计、交互设计和可用性构成我们今天所做的体验设计的大部分基础。它们反过来也都受到人机交互（HCI）的影响。其主要工作是为任务——交互完成性、高效性、错误预防/恢复——的进行设计和衡量。

■体验设计关心的是设计能够形成并影响消费者行为的、用户与产品、服务和系统的交互。体验设计经常涉及用户在使用产品的整个周期中跨越在线与离线的体验，并且不仅限于软件设计。于是，体验设计师经常是如下这些方面的多面手：以用户为中心的研究、交互和信息设计以及可用性。

■用户界面开发人员和前端开发人员要比设计师更接近开发人员，因为他们要花时间写呈现层代码。他们经常在前端和设计师、后端和开发人员之间作为链接，因为他们懂双方的语言。

■信息架构/架构师对数据或信息分类，形成连贯的结构，以便用户能看明白并且找到他们想找的内容。

■视觉设计/设计师关心的是用户界面的观感和品牌元素，与平面设计关系最为紧密。视觉设计师考虑字体、颜色、图标、布局、图像样式和品牌开发。

■设计研究/研究人员将诸如可用性、人种论、人类学以及市场研究这样的原则结合起来。这一组合方法用于研究可能影响用户界面设计并且对其可能有贡献的因素。专于研究的设计研究人员实际上可能根本就不做设计工作。

本书剩下的部分除非特别指出，否则在指设计师的时候，我们的意思是：

体验设计师携带这么一个工具箱，其中包括了人种论、人类学、心理学、创意设计、设计思想、产品设计、服务设计、交互设计、信息设计以及可用性。

这个设计师负责创建用户对数字产品或服务的体验。提供这样的定义，我们希望能够既让设计师也让非设计师对设计有更多、更好的理解。

当前对体验设计的影响

有其他三个设计领域是值得在此一提的，因为它们对我们今天所知的体验设计有着重要影响。

■设计思想出现于数年之前，它将传统设计的创作方法带入业务环境中。其想法是让非传统设计人士可使用设计师的创作方法来激发原始的想法、激发更多创作战略方法并带来更好的产品革新。设计思想有一些伟大的支持者，包括诸如IDEO公司和哈佛商学院这样的组织。斯坦福大学更是创建了他们自己的设计研究院。它帮助人们将创新思想和以人为本的设计带入到会议室中，为更好地理解体验设计价值铺平道路。

■服务设计与创建相关产品、服务、沟通和环境的生态系统有关，它与人们一起建立这一生态系统，并且为那些能共同创建价值的人而建。

比如，用户界面设计对于单个系统而言主要看的是用户交互；而服务设计则考虑跨渠道、跨组织“孤岛”、跨系统的客户提供者链中的所有链接。它影响了体验设计师的思考方法，让思想超越网站的原始范围，对用户体验以及数字渠道如何与离线渠道集成有更全面的思考。

■精益启动将准时制和“刚刚好”哲学应用于业务启动过程，它寻求以闪电般的速度进入市场并测试业务想法。这样的想法要么很快失败——也就是说，在浪费任何时间或金钱来做进一步的开发之前除掉错误的概念；要么快速上规模——也就是对于在早期测试中展现出有成功希望的概念，我们想将“最小可行的产品”放到用户手中以便测试、研究。当然，体验设计总是与尽早测试以及经常测试有关，而精益启动则以测试业务案例来开始。

《设计思想》

作者Deborah Kneeshaw，Sydney Design Thinkers创始人

设计思想是思考和做事的一种方法，它组合了设计者所使用的创作技术和严格的业务准则，与传统方法相比有许多关键不同点。

■设计思想从更高的层面审视每个项目，欢迎复杂性和系统思想，从而提出可持续的解决方案而不是短期的修补。

■设计思想强调客户、最终用户和利益相关者的需求，设计解决方案就建立在他们的需求基础之上。

■设计思想的实践者给出多个原始想法，它们会在早期得到测试。

■设计思想是高度协作和包容的，它为一起创造性地工作的团队提供了一个强大的平台。想法经常在详细实现之前会经过许多精益迭代回合，通常包括用户反馈。

设计思想是个实用的革新工具，可成功地用于改进或开发服务、产品、系统和战略。在需要创作方法时它是有用的，无论是在仅需对微小的挑战更改一下思考方法的微观层次上，还是在解决二十一世纪的“邪恶问题”的宏观层次上。以前从来没有遇到过的新的挑战和情况——比如全球气候变暖——这样的问题需要新的思考方法。

3.5 小结

设计师需要关心敏捷，因为它能给业务和用户带来实际的利益。读者需要花些时间来熟悉敏捷，因为这一过程与您过去的工作方式颇为不同。与您所听说的恰恰相反，敏捷和设计可以和谐共存。一旦理解了其指导原则并对其实践，就可适应它们，确保项目享用到设计与敏捷能够带来的机遇。

作为设计师，我们有机会将设计重新注回到敏捷项目中。我们需要创建设计愿景，用它指导细节。创建设计愿景不是要做大量的前期设计，它是一种准时制方法，用于铺设基础并为项目开发设定方向。

设计原则有许多，但对于本书的剩余部分而言，在我们提到设计师时，我们指的是有多种技能的体验设计师，他们从许多不同的原则中汲取精华，创建出理想的交互体验，从而影响用户的感知和行为。

3.6 接下来

在下一章中，我们将了解项目管理以及在迭代开发中协作的跨功能团队如何更快地产生出质量更好的结果。我们将看看给在敏捷项目中工作的设计师的提示，以及给产品经理、与设计师一起工作的其他团队成员的提示。