第五章 设计冲刺(1)-第一天:理解

设计冲刺

第五章 设计冲刺(1)-第一天:理解_第1张图片
开始冲刺

除了一些小的意外,每个设计冲刺有5个阶段。如在第1章和第2章所提到的,在5天内完成所有的5个阶段是达成设计冲刺价值的最佳方法。在这一章中,我将解释每个阶段背后的逻辑,以及为什么按这个顺序练习效果最好。

01.理解

02.发散

03.汇聚

04.创建

05.测试

第五章 设计冲刺(1)-第一天:理解_第2张图片
设计冲刺的5个阶段

阶段1:理解

专业建议-推荐时间表

相关介绍、议程,角色 —— 20分钟
列出假设和事实 —— 30分钟
回顾背景研究与发现 —— 1-2小时
需要,想要和欲望或真实痛点 —— 1小时
用户旅程或关键路径 —— 45分钟
发表”问题声明“ —— 45分钟
回顾 —— 15分钟

概述

设计冲刺的第一天是关于减少假设的噪音和建立为什么我们应该解决这个特殊问题的明确信号。团队将回顾背景研究,找出认知上的差距,揭露最危险的假设。

相关介绍、议程角色 —— 20分钟

我建议主持人应该在设计冲刺开始之前就将团队成员做完相互介绍。视频会议可以很好地解决这个问题,让每个人都能看到谁会在那里,并开始适应在一起。

对于一些分散团队的大型企业,人们可能在第一天时才会碰面。所以,要计划一点额外的时间来进行社交和简短的介绍,必要时可以使用姓名标签。

让每个人从一开始就分享他们的担忧也是一个好主意,利用希望VS恐惧的练习来提供这个机会,让个人的期望公开化。这个完成后,主持人应该分配角色并带领每个人进入议程。

列出假设和事实 —— 30分钟

今天的第一个练习是在白板上或每个人都可以看到的空间上列出假设。主持人会问这样的问题:我们对客户的假设是什么? 我们假设当前的购买体验是否适合用户? 我们确信顾客能清楚地表达我们产品的价值吗? 我们问过客户他们想要什么吗?

主持人使用这些问题作为团队成员之间对话的提示,所以将它放置在可见的地方。在每个假设旁边写下如何测试假设,以及有效和无效的结果是什么。虽然这个过程主要是在理解阶段完成,但是当团队在冲刺过程中发现其它时,可以继续添加假设和相关的测试。

第五章 设计冲刺(1)-第一天:理解_第3张图片
假设清单

企业会固守基于过往多年的习惯经验(甚至取得成功的)而得出的制度层面的假设。但是,在当今瞬息万变的商业环境中,这些假设可能是极其危险的,尤其是如果它们是错误的或者建立在过时的信息之上时。

回顾背景研究与发现 —— 1-2小时

在设计冲刺开始前几天收集、组织和分发背景研究是很重要的。但很难确保团队在到达之前会对其进行审阅。所以最好第一天就开始研究。对于复杂的问题,回顾研究将占用一天的大部分时间。但必须这样做。如果没有背景知识,团队将很难做好接下来的练习。

专业提示 - 停车区
在讨论假设和研究的过程中,这些团队还会产生一些可以作为未来解决方案的想法。在这个阶段,重要的是关注问题的定义,不要被潜在的解决方案分散注意力。不要压制任何解决方案的想法,简单地将它们添加到”停车场“或后备板,在那里可以记录想法,这些点子通常在发散和汇聚阶段会很有用的。
研究评审的目的是确保团队对业务挑战、客户当前的期望和业务或产品所提供的价值主张有坚定的把握。这种理解将比使用竞争性的比较更基于事实,更不容易受到意见或假设的影响。(如果还没有产品,而这个设计冲刺被用来发现一个新的产品机会,你可能还没有一个明确的价值主张。)

需要,想要和欲望或真实痛点 —— 1小时

识别客户的需求可能是一天中最重要的工作。在用户需要什么或他们想要什么之间进行排序,将帮助团队更好地理解问题。例如,用户可能需要从位置A到位置B,但是他们选择的方式可能不同。一个用户可能想骑自行车,而另一个想开豪华轿车。在这两种情况下,需求都得到了满足,但方式截然不同。

用户旅程或关键路径 —— 45分钟

绘制用户旅程可以让每个人看到客户和产品之间的接触点。主持人要求参与者在与产品交互时映射客户所采取的步骤。每个参与者通过添加、编辑或澄清诸如“客户在购物网站上搜索照明解决方案”或“公司向用户的智能手机/应用程序发送通知”等活动来做出贡献。简单地映射接触点,并对每个接触点所发生的事情进行简单描述,就足够了。高保真的插图不会给这个练习增加任何额外的价值,所以保持简单。

我发现这是在设计冲刺中最有趣的练习之一。公司如何视觉化描述客户旅程,很大程度上解释了团队对客户需求的理解。团队围绕客户在旅程图怎么走的达成一致越多,他们对问题的理解也越多。作为一名主持人,如果你注意到关于旅程触点有很多不同的意见,那就有必要回过头来讨论驱动这些交互的假设。

发表“问题声明” —— 45分钟

做完背景调查,确定了客户的需求,找出需要解决的问题是很重要的。识别问题并以语句的形式编写,它也可以作为对未来的展望。把客户的问题和产品愿景看作是同一枚硬币的两面。

我建议团队中的每个人都使用下面的格式编写自己的问题陈述版本,然后与团队中的其他成员比较版本。小组讨论和共识了彼此的不同之后,主持人可以在白板上写下最终版本。

创建问题陈述,请用您自己的解决方案愿景替换括号中的单词:

专业提示 — 创建问题陈述声明

今天,当【细分客户】想要【渴望的活动或结果】时,他们必须【当前的解决方案】。这是不可接受的,因为【当前解决方案的缺陷】。我们设想这样的世界【缺陷得到解决】。我们正通过【高层次的方法】来改变这个世界。

清楚地识别问题很重要的,所以不要害怕重写这个语句多次,或者添加一个更长的解释,如果它有助于理解的话。您还会注意到语句的最后两句话,这两句话表明解决方案的结果可能是什么。你不太可能在头脑中有一个清晰的解决方案,所以把注意力放在你想要创造的结果上。例如,如果我们使用共乘交通工具的例子,我们可能会说:“我们设想这样一个世界,拥有一辆汽车可能不再是一种负担。我们通过智能手机为这个世界带来了一种新型的共享交通解决方案。”

确定是否存在问题与理解问题是否可以解决,以及是否需要解决同样重要。问题陈述是回答以下问题的第一步:这个产品是什么?它有用吗?

回顾 —— 15-20分钟

在第一阶段完成之前,重要的是团队要圈起来讨论当天的工作,并提前计划第二天的工作。 我喜欢问团队问题和寻找问题共识。 这些问题是对一天工作的总结:谁是产品或功能的最终用户? 在什么情况下用户会使用这个产品或特性? 由这个产品或功能引起的他们的痛点是什么? 影响他们使用这些产品或特性有哪些触发点,或内部动机或外部压力有哪些? 用户期望从这个产品或功能的接触中得到什么结果?

这些问题可能一开始不是很清楚,没关系。 讨论它们并围绕接下来的阶段需要做什么来调整团队,比具体的答案更重要。

你可能感兴趣的:(第五章 设计冲刺(1)-第一天:理解)