当用户体验设计遇上敏捷pdf

当用户体验设计遇上敏捷 作者：[英] Lindsay Ratcliffe，Marc McNeill

当用户体验设计遇上敏捷 出版社：人民邮电出版社

当用户体验设计遇上敏捷 内容简介

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

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

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

当用户体验设计遇上敏捷 目录

序

致谢

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

第1章 设计的重新设计

1.1 创新英雄和IT反派

1.2 别朝传话人开火

1.3 在真空中设计

1.4 生活和时间已前进

1.5 敏捷体验设计宣言

1.6 让IT是协作的、迭代的、紧密的

1.7 让愿景成真

1.8 持续开发细节

1.9 让设计有回应

1.10 我们在等什么

第2章 瀑布已经干涸

2.1 现状

2.2 敏捷之解构

2.3 敏捷体验设计

2.4 对完成的重新定义

2.5 小结

2.6 接下来

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

3.1 敏捷与设计矛盾吗

3.2 一个重大的设计挑战

3.3 设计的适合之处

3.4 谁是设计师

3.5 小结

3.6 接下来

第4章 设置场景

4.1 一个敏捷体验设计项目

4.2 敏捷团队结构以及设计师的角色

4.3 敏捷项目环境

4.4 敏捷项目交流

4.5 敏捷项目管理

4.6 小结

4.7 接下来

第二部分 如何设计并快速交付吸引人的体验

第5章 准备出发

5.1 识别问题以及解决方案

5.2 我们如何做

5.3 模型在过程中的角色

5.4 我们需要什么人

5.5 如何给我们的时间定结构

5.6 人已聚齐，然后呢

5.7 小结

5.8 接下来

第6章 敏捷探索

6.1 开始

6.2 协作探索的3个“i”

6.3 业务意图

6.4 洞察用户

6.5 实现

6.6 将这一切组合在一起

6.7 小结

6.8 接下来

第7章 展望成功

7.1 创意的建立

7.2 让它发生

7.3 想法生成

7.4 精益

7.5 探究

7.6 验证

7.7 转变

7.8 小结

7.9 接下来

第8章 精心制作：备妥、稳定、构建

8.1 最低限度的可行产品

8.2 用户故事

8.3 目标与历程

8.4 估算

8.5 小结

8.6 接下来

第9章 进入开发

9.1 迭代：交付的心跳

9.2 以一个团队的形式工作

9.3 设计文档

9.4 与产品所有者协作

9.5 以迭代方式工作

9.6 小结

9.7 接下来

第10章 超越敏捷，持续改进

10.1 发布是什么样子的

10.2 超越发布，进入持续的改进

10.3 倾听与衡量

10.4 数字是否增加了

10.5 小结

10.6 接下来

第三部分 工具箱

亲缘性映射

分析

依原样的体验设计评审

“依原样”/“将要成为”过程映射

将相机作为文档

协作设计

竞争对手评审

环境场景

环境调查

用户体验/历程地图

用户测试

设计评审会议

电梯推销

人种研究

热气球

想法生成

信息设计

洞察

从内部看问题

我和我的影子

人物角色

产品盒子

原型制作

回溯

展示会

站立会议

制作故事板

故事地图

任务分析

折中滑块

当用户体验设计遇上敏捷 精彩文摘

做那些需要埋头干活儿的艰苦任务时，能够一直保持好的心境和充足的能量，难度绝不亚于一场战争。如果你总能在这样的战争中取胜，那么世上便真的没有什么难事了”。

——Thomas A. Buckner

关于数字产品设计，在过去20年里，由于技术处于强势地位，设计师们则被撂在一边。而现在，是我们这些设计师大显身手、重振山河的时候了。

设计的过程受困于过去的印刷世界中：一个超级代理集团、有形的人工制品和最后期限。最糟糕时，设计会落入夜郎自大、固步自封。设计，需要被重新设计。

目前，驱动设计的是最后期限——想法、草稿、蓝图以及原型在这一时刻必须被印刷、制造并发布。我们用最后期限之前的时间来孕育、生产以及精化我们的设计。最后期限一过，我们便松了一口气，宣告设计完成。

这个模型诞生于工业时代，这是一个我们需要大型机械、生产线以及生产计划来生产有形的人工制品的时代（图1.1）。如今处于信息时代，但我们却仍然将这样的思想用在数字产品的创作过程中。比如，我们开发一个新的数字产品或服务，在发布之日就应当是完成之时。当来自用户或市场的新事物出现时，我们会再次从草图开始进行整个过程，用完全一样的方法生成下一代产品。然而我们知道，改变是不可避免的。改变是持续的、能自己生生不息地循环。人类需要改变，技术总在随着社会、环境和政策的改变而改变，使得改变的循环成为一股坚毅的力量。

作为数字工程师，我们必须迎接改变：它是数字产品生存的生命之血。我们不能惧怕改变，而是要接受它、让它成为我们所做的一切工作的一部分。

从前，有家公司认识到设计外包的需要，于是就有了设计简图，邀请了一些项目团队给工作定调。设计师从分析活动入手，然后在书面报告中给出总结。完成了分析之后，真正的设计工作开始了。项目团队隐退到他们的工作室中，创作魔法就在那里产生。一段时间之后，他们带着成熟的设计出现。经过一段简短的反馈和精化，客户满意地离开，设计师们奔向酒吧庆祝。

如此似乎是个颇为美妙的过程，对于设计师而言也的确有效。实际上，在这个阶段，客户也很满意，他们对设计师的创作环境印象深刻、信服于项目团队、惊奇于包含了夜店的鸡尾酒和晚餐的创作预算。

好景不长。设计的蜜月期结束了，设计团队离开了项目。开发工作一开始，痛苦就来了，IT经理解释说，让每个人都兴奋不已的神奇设计实际上无法实现。

客户要是有这样的想法不足为怪：“那些做IT的人都是傻瓜。他们怎么就不能把它构建出来！这能有多难？工作得再努力一些、时间再长一些、快一些！只要有必要就多派人手！如果你的团队干不了，让能干的人来干！”最终，项目交付，但比期望的时间迟了很多，预算涨了许多，最终结果却和设计团队所交付的闪闪发光的展示板相去甚远。

那么，问题出在哪儿了呢？从业务的角度看，出问题的是IT。每个人都知道，要让IT干净、利落并且在预算内交付产品比登天还难。或许曾经的确如此，但IT的情况是这样的：这里充满了善于分析的头脑和花时间尝试将不可能变为可能的人。如果哪儿出了问题，IT人会尝试找出问题原因并给出解决方案。