【设计思维框架】为现代企业重新设想的设计思维(下)

简介: 【设计思维框架】为现代企业重新设想的设计思维

思考(Reflect)

走到一起看看

随着项目的进展,我们不断收集新信息。观察产生关于现实世界的新数据,同时产生新的想法和追求的机会。但是,由于这些信息揭示了我们问题空间的复杂性,它很容易被淹没,失去对齐,或者忽略了我们共同完成的任务。

这就是为什么定期反映团队的重要性。反思将您的团队聚集在一起,使您的动作同步,综合您学到的知识,并相互分享您的“aha”时刻。如果情况发生了变化,那也是重新思考如何向前发展的时候了。

反思时,要有同理心去理解不同的观点,灵活应对变化,以及保持团队价值观的诚信。要诚实地对待你所知道的事情,并对所听到的事情保持开放 - 积极或消极。开始并不容易,但是当你经常反思时,你收到的反馈会产生你最好的想法。

了解对方

通过发现将你团结在一起的东西来培养共同的身份。相互了解彼此,并像对待用户一样建立对他们的同情。评估观点的多样性。承认每个人的优势,并将自己的局限视为他人发光的机会。

调整意图

如果你发现自己偏离了方向,放慢速度并检查你工作背后的意图和动机。了解您的用户,您正在解决的问题以及您共同努力实现的成果。评估您正在进行的工作,并确保它与您团队的全局任务保持一致。

揭开新的见解

当您接收新信息时,要评估您所知道的以及您不知道的内容。综合您的知识,发现隐藏的洞察力,照亮前进的道路。洞察力不是重复观察 - 它是一个清晰的飞跃,重新构思你的观点,改变你对重要事项的信念。

未雨绸缪

随着你的理解的发展,不要盲目前进。一起决定你的下一步行动。你既可以采取另一种循环,也可以放在地上并投入一个想法。无论你做出什么决定,都要确保你清楚自己接下来要做什么。

互相问对方

如果您不知道从哪里开始,请将这些问题视为个人和团队。努力解决您可能发现的任何分歧。

  1. 谁是我们的用户?
  1. 我们的能力是什么?
  2. 谁是我们的利益相关者
  3. 我们能控制和影响什么?
  1. 我们是否一致?
  1. 我们解决了什么问题?
  2. 我们如何定义成功?
  3. 我们的收获或失败是什么?
  1. 我们在学什么?
  1. 我们观察或制造了什么?
  2. 什么工作,什么不工作?
  3. 我们能获得任何见解吗?
  1. 我们的计划是什么?
  1. 我们的路线图是什么?
  2. 我们需要什么资源?
  3. 我们准备好了吗?

行动(Make)

给出具体的形式来抽象思想

我们有时会陷入“分析瘫痪”。推迟制作是很诱人的,因为我们对自己没有足够的理解并不自信。有时我们只是害怕在完全出炉之前分享想法。我们中的一些人有条件保留最后的制作。

但在一天结束时,看到结果的唯一方法就是制作一个。制作抽象概念的形式,让您有机会尝试新的想法,并看到它们在现实世界中生效。你做得越早,你学得越快。召唤好奇心尝试未经探索的想法。勇敢地将你的想法带入世界。你可能错了 - 这并没有错。

当你去做时,要求别人参与并共同构建你的想法。与您的团队成员合作通常是您最好的想法诞生的地方。

探索可能性

不要等到一个想法完美 - 它不会发生。用双手思考,实时发现新想法。找出哪些有效,哪些无效。利用快乐的事故。当你的想法用尽时,邀请其他人回复,重新混合并改变你所做的事情。你永远不会知道你可以向别人学到什么。

沟通想法

我们看到的是同一件事吗?一张图片胜过千言万语,所以不要告诉别人你的想法;让他们看。通过制作表达您意图的内容来获取您的想法。想出你的故事并向他们展示它的重要性。

原型概念

原型是有助于验证或使您的假设和假设无效的实验。尽管将您所做的一切都视为原型是有帮助的,但低保真原型可以帮助您快速,低成本地模拟想法和检验假设。无需使其完美 - 只需使其适合您需要的反馈。

推动成果

一旦你致力于一个想法,将你的意图转化为结果。你不需要知道一切都要动起来。在制定细节时,聆听,学习和修正课程。请记住:一切都是原型 - 甚至是市场上的解决方案。早早失败,快速学习。

考虑这些问题

如果您不知道从哪里开始,请考虑这些问题的答案。如果您遇到一个尚未探索过的问题,请停止说话并开始制作。

  1. 什么可能?
  1. 我们能做什么?
  2. 我们可以结合哪些想法?
  3. 我们怎么能做到呢?
  1. 发生了什么?
  1. 我们的主意是什么?
  2. 预期的结果是什么?
  3. 我们如何向他人展示?
  1. 这是什么概念?
  1. 它的形式是什么?
  2. 它的部分是什么?
  3. 零件如何相关?
  1. 我们如何交付?
  1. 我们如何建造它?
  2. 我们如何部署它?
  3. 我们如何维护它?

关键与我们保持一致

关键有助于团队保持专注,并与用户关注的结果保持一致。

丘陵(Hills)

 

让我们谈谈过程

在实践中,复杂的问题通常需要复杂的团队 - 复杂的团队可能是一个管理挑战。项目管理框架可以帮助管理复杂性。我们可能将团队划分为“小队”或“工作流”,或者我们可能将时间划分为“冲刺”或“阶段”。我们甚至可以围绕团队遵循的共同流程进行标准化。

无论我们如何组织团队,提供卓越的用户成果都需要我们保持专注并始终关注对用户至关重要的事项。

当我们从想法转向结果时,钥匙是我们三种最重要的技术,可以让不同的团队一起反思。它们帮助我们保持一致,保持一致,并与现实世界的需求保持联系 - 即使我们深入工作。虽然他们已经通过我们与最大团队的经验磨练,但我们发现钥匙对各种规模的团队都非常宝贵。

Hills将我们团结在一起

Hills是意图声明,写成有意义的用户结果。他们告诉你去哪里,而不是如何到达那里,让团队能够在不忽视目标的情况下探索突破性的想法。

获得同步

这是事实:在复杂的项目中,事情并不总是按计划进行。永无止境的功能请求和技术障碍可能会破坏进度,延迟发布,甚至使最健康的团队失去一致性。尽管存在这些不确定性,团队如何才能忠于项目的意图?

Hills以清晰和灵活的方式传达我们对项目的意图。它们将问题视为预期的用户结果,而不是预先确定的实施,使团队能够发现突破性的解决方案。它们帮助我们密切关注奖项,即使我们遇到了许多挑战。

 

一个山的解剖

要编写Hill,请从您要提供服务的用户开始。接下来,指定您希望它们实现的结果,以及使您的解决方案值得一试的差异化因素。我们将这些元素称为Who,the What和Wow。

一个好的Hill是与实现无关的。它应该指定用户尝试完成的内容,而不是他们用来执行此操作的工具。如果你读回希尔,感觉它已经描述了具体的实现,请退一步再试一次。

谁(Who)

谁是你的用户?明确你的目标是谁以及你不是谁。

什么 (What)

他们想要满足的需求是什么?将用户需求转化为项目目标。

哇(Wow)

您将如何与竞争对手区分开来?你将如何衡量成功?

例子

 

基于GMU的销售负责人可以在24小时内组建敏捷响应团队,无需管理层参与。

IBM Connections,2012

 

开发人员使用IBM和第三方API构建和运行应用程序的时间不应超过30分钟。

IBM Bluemix,2014年

 

我相信这个国家应该致力于实现让一个人登上月球并将他安全返回地球的目标。

约翰·肯尼迪,1961年

与Hills一起管理

如果您在产品团队中,Hills由产品管理所有,并与设计和工程部门合作定义。如果您是服务团队,Hills由高级客户利益相关者拥有,但与交付团队合作定义。与您的客户合作,以达到明确定义的Hills,您的团队可以在您的限制范围内实现。

不要担心在第一天写完美的山丘。Hills应该根据您对问题的理解而发展。在您进行迭代时,请尽早并经常进行Hills Playbacks。您的Hills可以更改为Playback Zero  - 当您需要真正提交时。

三山,一个基础

你可以做任何事情,但你不能做任何事情。Hills应该反映出对用户最有价值的成果的投资,以及对您的组织最重要的区别。这就是为什么我们强烈建议任何时候项目不超过三个Hills。这有助于您专注于一组可管理的目标。

除了三个Hills之外,您还可以将一部分资源投入基金会,以解决过去发布的问题,或者为项目的未来支付预付款。

提交资源

根据您对用户和组织的相对价值,为Hills和Foundation分配资源。在每个山丘周围组建不同的赋权团队,并为每个人提供独立交付成果所需的专业知识和权威。力争每个Hill至少招募一名赞助商用户。

一旦资源分配给Hill,将其视为线程安全投资。Hills提供了围绕资源进行结果驱动对话的语言。如果希尔需要额外的资源,那么您的决定就是重新分配每项投资的价值。

例如:假设您已将25%的资源分配给三个Hills中的每一个,其余25%分配给基金会。如果基金会出现问题,请问自己:是否值得冒险从希尔转移资源来修复它?

分解他们

有时,希尔必然是复杂的,可能会受益于另一种分解水平,以进一步划分工作。如果您选择编写Sub-Hills,请确保每个人都是一个合适的Hill,如果独立发布,仍然可以为用户提供有意义的价值。

 

回放(Playbacks)

 

回放时间与我们保持一致

专注于用户结果

在回放中,用户是节目的明星。给他们一张脸并按名字介绍他们。让您的受众体验成为用户的体验。您的受众对用户的同情心越多,他们的反馈就越有价值。

回放将利益相关者带入安全空间的循环中,以讲述故事和交换反馈。他们揭示了错位并衡量了你正在解决的大局问题的进展。

保持同步

实际上,并非每个人都有时间参与每个项目的循环。如果您是项目的利益相关者,可能会觉得团队随着时间的推移而偏离了轨道。如果您在团队中,可能会觉得您的利益相关者与您的团队对问题和解决方案的了解不一致。您如何让团队和利益相关者保持一致?

回放是让利益相关者进入循环以反映在一起的时间。他们是讲述故事和交换有关工作反馈的安全空间。持续播放可以使团队和利益相关者保持一致并在项目不断变化的情况下保持同步。

 

回放的解剖

播放有各种尺寸的形状。您可以将它们与一对一或更大的组保持在一起。您可以展示低保真草图或抛光演示。在需要利益相关方的反馈时随时保留它们,但考虑在常规里程碑上安排它们。

1)邀请利益相关者

考虑您打算分享的工作以及它可能影响的利益相关者。如果您是一名软件团队,那么您的法律顾问可能需要知道您正在使用新的开源库。也许您的销售团队需要知道路线图中的下一步。

如果你不确定邀请谁,那么就误入歧途。回放将利益相关者聚集在整个组织孤岛和层次结构中,为对话带来不同的观点,并促进透明和包容的文化。

2)讲述你的故事

功能和要求被遗忘。故事持久。

故事显示背景。他们有角色,关系和情节。故事揭示了构成用户体验的整体情况,并帮助受众以超出项目项目的方式理解赌注。换句话说:故事让我们关心。

3)听取反馈和错位

无论他们是实习生还是高级副总裁,都可以从任何人那里获得良好的反馈。让每个人都有机会听取他们的意见。无需判断即可捕获您所听到的

回放显示团队的对齐或错位。如果播放顺利,祝贺 - 您向前迈进了一步。如果出现分歧,请不要惊慌。现在是时候围绕问题采取另一个循环,然后再试一次。

 

使用里程碑回放进行管理

您可以在需要反馈时随时进行播放。但是,当您的团队和利益相关者需要聚集在一起并就如何向前发展达成一致时,在项目的关键时刻安排里程碑回放是有帮助的。虽然每个团队都有其独特的里程碑时刻,但这里是典型软件产品团队如何设置其里程碑的示例。

 

Hills Playbacks

在你的工作中

尽可能早地进行Hills Playback。在精炼您的山丘时,请根据需要继续按住它们。而不是试图在第一次尝试时使你的Hills正确,向前移动并在你了解更多时重复它们。

在项目开始时,团队安排Hills Playback以确保所有利益相关方就项目的预期结果达成一致。

该团队通过分享他们对用户的了解,他们的产品当前用户体验不足以及所涉及的内容来打开Hills Playback。他们讨论了项目的Hills,Foundation和建议的资源分配。

在成功进行Hills Play后,球队分解成了他们的子队。每个子团队都会探索对其指定的希尔采取的潜在解决方案。

Playback Zero

在你的工作中

团队达成共识需要时间。不要等到Playback Zero才能从利益相关者那里获得投资。保持播放播放(“播放-2”,“播放-1”等)导致播放归零。迭代直到你达到对齐。

 

一旦团队认为他们已经为每个Hill达成了一个建议的解决方案,他们就会安排他们的下一个里程碑:Playback Zero。回放零点是团队和利益相关者就团队实际承诺提供的内容达成一致的时间。

在Playback Zero期间,团队专注于他们提出的用户体验。他们讲述了一个逼真的,引人入胜的故事,讲述了他们每个Hills的完整用户旅程,在中保真度下可视化建议的解决方案:低到足以留出精致的空间,但足够高以获得有意义的反馈。它们以高帧率穿过解决方案,以用户可能穿过它们的方式穿过每个屏幕。

在成功播放Zero后,团队将他们提出的解决方案分解为敏捷的史诗和用户故事,并开始提供真实的生产代码。

Delivery Playbacks

在你的工作中

在重要的交付里程碑之后保持交付回放 - 例如,在每个冲刺结束时,或在您达到希尔之后。

 

在每个sprint结束时,团队都会进行交付回放以审核整体用户体验并衡量他们对Hills的进度。

该团队不依赖于模型或原型,而是使用真实的工作解决方案运行Playback。但是,与简单的sprint结束演示不同,Delivery Playbacks通过解决方案告诉用户端到端的故事,帮助团队确定他们优先排序所需的重要用户体验差距。

成功交付播放后,团队负责人会讨论产品是否已准备好发布给真实用户。

 

Client Playbacks

在你的工作中

在进行客户端播放之前,请确保您已签署必要的法律协议以共享机密信息。

随着解决方案的发展,该团队与已同意签署保密协议的重要客户进行回放。在客户端播放中,团队展示了他们的产品路线图,他们的三个Hills以及他们打算提供的用户体验。作为回报,客户为团队提供反馈,以不断改进他们的产品。

 

资助者用户

赞助商用户将我们与现实联系起来

赞助商用户是真实用户,定期向您的团队贡献他们的领域专业知识,帮助您在整个项目中与用户的实际需求保持联系。

保持联系

尽管我们付出了最大努力,但同理心仍有其局限性 如果你正在设计一架客机的驾驶舱,但你不是飞行员,你根本就不知道降落飞机的感觉。如果没有第一手的经验,很容易与用户的现实失去联系,并允许偏见和个人偏好蔓延到我们的工作中。

赞助商用户是真正的用户或潜在用户,他们将自己的经验和专业知识带给团队。他们不是被动的主体 - 他们是与您一起工作以获得良好结果的积极参与者。虽然它们不会完全取代正式的设计研究和可用性研究,但赞助商用户将帮助您打破移情障碍,并在整个项目中与实际需求保持联系。

资助者用户的剖析

优秀的赞助商用户代表您的目标用户,他们会投入到结果中,并且他们可以定期与您和您的团队合作。

  • 1)它们代表您的目标用户吗?

优秀的赞助商用户反映您打算提供的实际用户。尽管您的客户,客户或经济买家可能会对您提供帮助,但他们通常不会是最终从您的产品中获取个人价值的用户。

  • 2)他们是否亲自投资于结果?

一个好的赞助商用户会像你一样关心你的项目结果。寻找具有特别严格的使用案例的候选人 - 严重依赖您的服务成功的赞助商用户将对您项目的成功产生既得利益。

需要注意的是:不要将要求严格的用例误认为是“极端”用例。如果你在一个涉及家庭小型货车的希尔工作,赛车手可能不是赞助商用户的好选择,无论他们对你有多大兴趣。

  • 3)他们可以合作吗?

一个好的赞助商用户是开放的,愿意与您的团队分享他们的专业知识和经验。

虽然作为赞助商用户不是一份全职工作,但这是一项承诺。设定期望,但要尊重他们的时间,并在他们的日程安排上保持灵活性。重要的是听取他们的见解和想法。

 

资助者用户合作

如果您是产品团队,赞助商用户关系归产品管理和设计所有,但值得与您的销售和营销团队联系以提供候选人。如果您是服务团队,您的客户将与您组织中的赞助商用户候选人联系,但产品团队负责向客户传达赞助商用户标准。

虽然赞助商用户不会取代正式的设计研究和可用性研究,但您与他们的每次互动都会缩小您的假设与现实之间的差距。将他们视为团队的一部分。作为合作者,他们将在项目上留下重要的印记。

资助者用户和Hills

在尝试招募赞助商用户之前,请务必写下Hills并了解目标用户。当您优化Hills并澄清目标用户时,您可以开始招募其用例最适合特定Hill的赞助商用户。我们建议每座山至少有一名赞助商用户。

通过他们的眼睛观察

让赞助商用户向您展示他们的世界。帮助他们以清新的眼光看待他们并让他们与您分享他们的见解。分享您的见解。你可能会发现他们不会看到的故事的一面。

一起反思

仔细聆听赞助商用户的意见。将它们包含在您的播放中并让它们帮助您完善您的山丘。像任何其他团队成员一样,他们并不总能得到他们想要的东西。但如果他们告诉你,你没有解决他们的问题或者你的生活增加了复杂性,那么你可能会走错方向。

合作

在您制作时,请让您的赞助商用户成为您的指南。经常咨询他们。更好的是,鼓励他们通过为他们提供表达自己和与你并肩作战的工具来贡献他们自己的想法。

相关文章
|
6月前
|
设计模式 算法 C语言
技术进步与个人成长:从代码到思维的演变
技术不仅塑造了我们的工作方式,更深刻地影响了我们的思维模式。本文探讨了在编程实践中,个人技术能力和思维方式如何相互影响和提升,重点讨论了一些关键的经验和感悟,以及这些经历对职业发展的深远影响。
64 0
|
4月前
|
程序员
软件设计与架构复杂度问题之战略编程与战术编程的主要区别如何解决
软件设计与架构复杂度问题之战略编程与战术编程的主要区别如何解决
|
5月前
|
敏捷开发 算法 搜索推荐
软件测试的演变:从传统方法到敏捷实践
本文深入探讨了软件测试领域的发展轨迹,从早期以代码为中心的测试方法,到今日强调快速迭代和持续集成的敏捷测试实践。文章通过分析历史数据、行业报告以及权威研究,揭示了测试自动化、跨功能团队合作以及质量保证在现代软件开发中的重要性。进一步地,本文还讨论了如何将科学严谨性融入测试过程,包括采用基于证据的测试策略、利用统计方法评估软件质量,并提出了逻辑严密的测试案例设计原则。
|
5月前
|
测试技术 UED
软件测试的科学与艺术:从数据导向到逻辑严密的实践
本文旨在探讨软件测试领域中数据导向和逻辑严密性的重要性,并分析如何通过科学严谨的方法提升测试效率和质量。文章首先概述了软件测试的基本概念和挑战,随后深入讨论了数据在测试设计和结果分析中的关键作用,以及如何利用逻辑推理来构建有效的测试案例和识别潜在缺陷。最后,本文提出了一系列实践建议,旨在帮助测试人员更好地整合数据驱动和逻辑推理方法,以实现软件测试的最优化。
48 0
|
架构师 UED
【设计思维框架】为现代企业重新设想的设计思维(上)
【设计思维框架】为现代企业重新设想的设计思维
|
设计模式 消息中间件 Dubbo
设计模式 - 漫谈软件编程背后的系统化思维
设计模式 - 漫谈软件编程背后的系统化思维
125 0
|
安全 数据可视化 测试技术
【设计思维框架】框架 :为现代企业重新设想的设计思维(下)
【设计思维框架】框架 :为现代企业重新设想的设计思维
|
架构师 UED
【设计思维框架】框架 :为现代企业重新设想的设计思维(上)
【设计思维框架】框架 :为现代企业重新设想的设计思维
|
设计模式 消息中间件 架构师
如何成为更好的软件架构师?
如何成为更好的软件架构师?
|
敏捷开发 架构师 算法
重新审视演进式设计
重新审视演进式设计
重新审视演进式设计

热门文章

最新文章