【本文翻译自 Design Thinking 】
设计思维在SAFe框架中的位置
通常，优秀的设计比糟糕的设计更难被注意到，部分原因是优秀的设计很好地契合了我们的需求，融入我们的生活，难以被察觉。相反，那些糟糕的设计因为自身的不完善，而更加引人注目。
——唐纳德·A.·诺曼（Donald A. Norman），《设计心理学》（增订版自序）。
设计思维
设计思维是一个以客户为中心的开发过程，它能创造出理想的产品，并在产品的生命周期内实现盈利和可持续发展。
它超越了传统上对规划中产品特性和功能的关注。相反，它强调了解要解决的问题，解决方案的使用环境，以及该解决方案的演进。
注：本文重点介绍与实施设计思维相关的工具和实践。它应该与以客户为中心一文一起阅读，该文主要介绍了以客户为中心的思维方式和影响。
详细介绍
传统的瀑布式产品开发方法是按顺序进行的：先确定需求，然后设计、构建解决方案，最后交付市场。这些流程的重点往往放在最浅显的问题上。通常情况下，成功取决于是否实现了一个满足需求（requirements）而不是满足用户需要（needs）的解决方案上，这会导致产品和服务的功能无法使用或被忽略，这些功能使用户感到沮丧，并且无法满足企业的业务目标。
设计思维(图1)代表了一种截然不同的产品和解决方案开发方法，在这种方法中，采用了发散（divergent）和收敛（convergent）的技术来理解问题、设计解决方案，并将该解决方案提供给市场。
图1.设计思维的活动
设计思维还激发了衡量工作成功与否的新方法：
- 可取性（Desirable） – 客户和用户是否需要这个解决方案？
- 方案可行性（Feasible） – 我们能否通过构建、购买、合作或收购的努力/活动的组合来提供正确的解决方案？
- 价值可行性（Viable） – 我们构建和提供解决方案的方式是否创造了比成本更多的价值？例如，在一个营利性企业中，我们是否能够盈利？
- 可持续性（Sustainable） – 我们是否在积极主动地管理我们的解决方案，以满足预期的产品-市场生命周期？
如图2所示，设计思维的连续应用推动了解决方案在其自然的市场生命周期中的不断前进：
图2.通过设计思维推进解决方案在其生命周期内的发展
问题空间和解决方案空间
在图1中，设计思维的核心流程在视觉上显示为“双菱形”。这代表着在创建解决方案之前，要着重于彻底探索问题空间。与探究问题相关的活动如下：
- 发现（Discover） – 发现阶段旨在通过参与市场和用户调研来了解问题，从而识别未被满足的需求。这会创造驱动创新的新观点。与确认或反驳假设的调研不同，与发现阶段相关的调查是在没有关于用户应该如何工作的先入为主的观念下进行的。相反，它专注于用户的工作方式。一项重要的调研技术是Gemba，也就是所谓的“到工作的地方去”。
-
定义（Define） – 定义阶段侧重于对发现阶段收集的信息，使用
收敛技术生成对具体问题和/或未被满足需求的见解。这些定义为企业和新产品开发创造了机会。该阶段的结果通常包括用户画像（personas）和同理心地图（empathy maps）（后续章节会做详细介绍），这些结果使产品团队专注于客户希望看到的各种解决方案。史诗（Epics）和特性（Feature）捕获了现有产品和解决方案所需感知的变化。
对目标市场及其所面临的问题有了清晰的认识后，企业就可以着手设计解决方案，这是设计思维的第二个菱形。包含以下步骤：
-
开发 – 开发阶段使用
旅程地图（journey mapping），故事地图（story mapping）和原型设计（prototyping）来快速且经济高效地设计问题的潜在解决方案。本文稍后将全面地讨论每种技术。开发阶段也要拥抱SAFe原则#3--假设可变性；保留选项，使用设计技巧以负责任的方式保留选项。 -
交付（Deliver） – 交付阶段会生成适合创建解决方案的工件，并且会根据环境而变化。它们通常从原型开始，在
项目群待办事项列表（Program Backlog）中表示为一组经过验证的特性（Feature），以便通过持续交付管道（Continuous Delivery Pipeline）进行持续交付。
请注意，每个菱形都专注于发散思维（理解，探索选项），然后是收敛思维（评估选项并做出选择）。
使用用户画像专注设计
定制解决方案为设计人员提供了直接和频繁地与少数目标用户交谈的优势，允许他们参与设计会议、PI计划（PI Planning）、系统演示（System Demos）和其他SAFe活动。在一些组织中，这些目标客户被认为是团队的一部分，所以通常不需要创建一个代表他们的用户画像，但当组织高度分散时，单独的用户画像可能也会有所帮助。
相比之下，在B2C这类常见的间接客户市场的解决方案中，产品团队需要一种与目标客户保持联系的方法。因此，他们开发出了用户画像（personas），即从客户调研中总结出的虚构的消费者和/或用户。 [2]他们描绘了可能以类似方式使用产品或解决方案的不同人群，从而深入了解了实际用户将如何使用解决方案。用户画像还通过提供具体的设计工具来加强市场细分战略，以加强为人们创建产品和解决方案的能力。用户画像驱动着产品开发和一些SAFe的实践，如图3所示：
图3. 用户画像如何推动SAFe中的关键活动
除了用户画像，买方画像还将设计思维扩展到了授权购买决策的个人和组织。它们有助于确保设计涵盖整个产品的购买体验，包括售后服务、支持和运营等。
通过同理心地图建立同理心
以客户为中心的企业在整个设计过程中都使用同理心。广义上讲，同理心设计摒弃了先入为主的想法，并利用客户的视角为解决方案的开发提供信息。
同理心地图[1]是一种设计思维工具，它通过帮助团队对他人形成深刻的、共同的理解来促进客户认同（图4）。它们帮助团队想象特定角色在使用产品时的所思、所感、所闻、所见。团队对客户的同理心程度越高，团队就越有可能设计出理想的解决方案。
图4.同理心地图画布
通过旅程地图设计客户体验
客户旅程地图（customer journey map）展示了用户与公司的运营价值流（operational value stream）、产品和服务互动时的体验。如图5所示，旅程地图是用于运营价值流的强大的设计思维工具。它们使团队能够确定如何改进一个或多个开发价值流的具体交付物，以创造更好的端到端体验。
图5.运营价值流和客户旅程地图
通过特性实现收益
旅程地图通过运营价值流捕捉客户的高层次体验，而产品特性（Features）则管理满足利益相关者需求的具体交付物。特性通常通过特性和收益矩阵（features and benefit matrix）的简短的短语来描述，这些短语提供了用户体验的环境和收益假设（hypothesis benefit）。
设计思维实践促进改变我们考虑特性-收益假设（Feature-Benefit Hypothesis）要素的顺序。它们帮助敏捷团队探索更好更快的方法来交付期望的收益（图6）。
图6.传统的“特性和收益”矩阵变成了“收益和特性”矩阵
通过故事地图设计用户工作流程
特性（Features）通过一个或多个故事（Story）实现。SAFe中有2种类型的故事：
-
用户故事（User Stories）是表达所需功能的主要方法。它们可以用角色格式或用户画像格式编写：
角色格式：作为<用户角色>，我想要<活动/目标>，以便<某种原因，比如创造业务价值或个人价值>。
用户画像格式：弗兰克（Frank，一个具体的用户画像）想要<活动/目标> ，以便弗兰克获得<价值>。 - 使能故事（Enabler Stories）捕捉系统、架构或基础设施的需求，例如建立改进措施以支持持续交付管道。
团队待办事项列表（Team Backlog）包含源自项目群待办事项列表（Program Backlog）中的用户故事和使能故事，以及来自团队自身的故事。与所有待办事项列表的工作一样，团队待办事项列表是有优先级的，故事是按优先级顺序实施的。
捕捉工作流的功能对敏捷团队提出了独特的挑战：工作流是为了完成更高层次的用户目标而必须完成的一系列步骤。待办事项列表的线性顺序会让敏捷团队很难理解步骤之间的关系。通常，一组给定的步骤可以被改进，但是团队在改进这组特定的步骤之前，还必须平衡产品整体的完整性（必须支持所有步骤）。当开发解决方案的发散阶段设想改进机会，而设计思维的收敛阶段则关注下一个版本的基本内容时，潜在的冲突就会出现。
解决方案包含大型和小型工作流程。考虑到一个商务人士将信用卡账单导入费用报告系统进行处理的小型工作流程。用户必须：
- 从银行下载信用卡对账单
- 将信用卡对账单上传到费用报告系统
- 将信用卡对账单中的交易与费用报告系统中存储的费用收据进行匹配
- 删除不可报销的交易
如前所述，这些故事中的每一个都可以在工作流中得到体现。此外，每个步骤都可以随着时间的推移而改进：例如，我们可以想象银行和费用报告系统之间的直接连接，或者一个自动化的AI代理来管理匹配交易的任务。
表示工作流的特性是通过故事地图（story maps）[3]捕获的，故事地图根据用户实现其目标所需的任务来组织一系列的故事（图7）。
图7.故事地图示例
故事地图使团队能够了解团队待办事项列表中的故事是如何支持用户目标的（图8）。
图8.故事地图和团队待办事项列表之间的关系
故事地图还阐明了质量和价值之间的关系：
- 质量 – 待办事项列表中的每个故事都必须高质量地完成。
- 价值 – 必须完成“故事地图”中所有选定的故事才能创造价值，因为如果遗漏了一个故事，用户就无法完成其工作流程。
通过原型增加设计反馈
原型是我们希望构建的功能或产品的功能模型。它有助于设计团队阐明他们对问题的理解，并降低开发解决方案的风险。原型为产品团队提供了无数的好处：
- 快速反馈。根据定义，原型比完整的解决方案成本更低，且生产速度更快。这可以更快地从用户和客户那里得到反馈，提高对解决方案需求的理解，并对最终的设计更有信心。
- 降低风险。原型可以使开发团队将最初的精力集中在与最高风险相关的解决方案方面，从而降低技术风险。
- 知识产权/专利申请。原型可以用来满足在开发过程中尽早管理知识产权的战略要求。
- 需求模型。原型可以比成页的文档更清晰地说明所需功能或解决方案的要求。
原型有很多种，每种原型都经过优化以提供不同类型的见解：
- 纸质原型（Paper prototypes）通常是预期解决方案的手绘草图。作为用户故事地图的补充，它们可以自动说明工作流程。
- 中保真原型（Medium-Fidelity prototypes）是以软件为中心的解决方案的视觉上的完整表现，但通常没有功能集成。
- 高保真原型（High-Fidelity prototypes）是视觉上完整的交互式模型，用户和客户可以直接探索。
- 硬件原型为开发团队提供了有关形状、尺寸和操作要求等方面的关键反馈。例如，在探索形状以了解新的平板电脑如何适应现有的背包、公文包和汽车时，硅谷的一家公司只是从单张塑料片上切割出众多的塑料模型。在这个设计过程的后期，这个团队发现他们需要重新设计电源，以免对WIFI信号造成过度干扰。
为了帮助他们获得可行的反馈，产品团队应该努力利用成本最低、速度最快的原型设计形式。通常情况下，纸质原型设计是最佳选择。[4][5]
了解更多信息
[1] https://medium.com/the-xplane-collection/updated-empathy-map-canvas-46df22df3c8a。
[2] [美] 艾伦·库伯 / [美] 罗伯特·莱曼 / [美] 戴维·克罗宁 / [美] 克里斯托弗·诺埃塞尔，About Face 4: 交互设计精髓。电子工业出版社，2015年。
[3] Jeff Patton，用户故事地图。 清华大学出版社，2016年。
[4] Snyder, Carolyn. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann, 2003.
[5] Jeff Gothelf，精益设计：设计团队如何改善用户体验。 人民邮电出版社， 2013年。
网友评论