产品构思的头脑风暴框架

编者按：头脑风暴需要思想开放奔放没错，但是缺乏组织的头脑风暴往往很难得到既有创意又有可行性的点子。Jonathan Courtney介绍的这个框架是一个不错的头脑风暴框架。

头脑风暴以结构松散而且往往无法操作著称。大家聚到一起贴点纸条画画白板然后指望好点子就会出来。问题是即便里面诞生了一些好点子，但也没有一目了然的办法来确定应该执行哪一个。

实用用户故事映射的诞生

大约 1年 前，我和同事 Michael（AJ&Smart 创始合伙人）参加了 Adrian Howard 的一个大师班，主题是确定敏捷开发的功能优先级。说得具体一点，就如何去确定接下来的发布的时候要先做什么功能。经过课堂练习之后，我们突然灵机一动：这种颇为枯燥、系统化的办法说不定也可以用来组织我们的产品发现探讨。于是 1 周之后，我们做一件每每想要试验新技巧时都会做的事情：在未经太多准备或者考虑的情况下在一个高风险的客户身上进行试验。

结果非常完美。研讨时采用用户故事映射的结构可以把注意力高度集中在构思和发现上面，这正是我们想要的。自此以后我们就一直沿用这种技术，并且推广到了一个个的 workshop。现在我们称之为实用用户故事映射法（applied user story mapping，USM）。我们发现这种方法不仅是催生出无人能想到的点子的很好方式，而且也是客户或者利益攸关者协调一致的完美工具。下面我们就来介绍一下它是怎么做的。

需要准备的东西

\n
• 3 种不同颜色的便利贴
\n
• 彩色标签
\n
• 记号笔
\n
• 一堵墙或者一个平面
\n
• 一位主持人
\n

总用时估计

10—15 人计划用时为 45—50 分钟。每增加 10 人需多安排 10 分钟以及多增加 1 位主持人。比方说：

\n
• 10-15 人：1 位主持人，50 分钟
\n
• 15-25 人：2 位主持人，60 分钟
\n

步骤 1：故事

本过程的主干是故事。故事就是你设计的希望用户在特定时间段内执行的步骤或者动作列表。

故事当中用户可能会采取的一些步骤示例

比方说，如果我们是在讨论专门针对体育迷的新闻阅读器的设计，我们可能会基于比赛日设计一个故事。或者我们会针对飞行常客设计一个新的高级服务，我们也许会有一个更先进的故事扩展，从第一次预定开始一路上延伸到开始飞行。

如何创建故事

\n
• 所有参与者都应该有一堆便利贴以及一支记号笔
\n
• 让参与者写下能想到的用户在选定时间段可能会采取的尽可能多的步骤（人均可能会消耗 10-25 张便利贴）
\n

一名参与者正在写步骤

\n
• 步骤的颗粒度因人而异，没关系。
\n
• 一旦时间到，每个人都应该把便利贴帖到指定墙上，并且开始建立步骤的时间线。最终步骤应该只有一条水平排列的时间线。许多人可能会写出类似的步骤，没关系，叠在一起就行了。
\n

时间线要水平排列，不要出现任何纵向的步骤。后面我们会需要那些空间。

步骤 2：对动作分组

为了保持整齐，我们将对时间线上的动作进行分组。如果故事很长、时间跨度有几天的话这种做法尤其有用。到后面我们可以利用这些故事分组很方便地找到应该聚焦在故事的哪个部分。这一步很简单，而且应该由主持人来执行。

进行分组

如何对动作分组

\n
• 主持人查看时间线后确定分组，比方说 “早晨准备”、“上班通勤时间”、“工作”、“下班通勤时间”、“晚饭” 等等。
\n
• 主持人换一种颜色的便利贴写上分组名字，然后帖在每组的开头
\n

分组多少随你定，但一般 5 组就 OK

好看吧？

步骤 3：头脑风暴！

接下来是有趣的部分了。对于时间线上参与者认为重要的时间点他们应该试着提出尽可能多的想法。也就是说看看时间线上的某一个步骤（比如 “起床”）然后想出在这个点上你的产品或者服务可以如何影响或者与用户的生活进行交互的办法。比方说对于新闻阅读 app 可以像下面这样：

头脑风暴时间（设想用户起床时可以提供早间新闻摘要或者把头条新闻做成音频的形式）

这一步参与者只有 15 分钟思考，不过这个时间对于迸发一堆创意来说已经绰绰有余了。重要的是主持人必须告诉参与者这一步重量不重质。想法是否可行或者合法都没关系！大家只需要在给定时间范围内先出尽可能多得主意就行。

如何进行头脑风暴

\n
• 所有参与者均应有一堆的蓝色便利贴以及一支记号笔
\n
• 参与者应该围着故事时间线站在一起，手里拿着便利贴，随时准备写东西
\n
• 让参与者在 15 分钟内写出尽可能多得想法
\n
• 便利贴应该放在相应步骤的正下方
\n
• 任何与时间线无关的想法都可以单独放在时间线左边的位置
\n

讨论的结果如果不是像这样的话一定是搞错了，大错特错

\n
• 我建议为了让大家才思泉涌此时应该播放点音乐什么的，如果你不想找音乐可以参考我的播放列表\n
\n
• 一旦 15 分钟到了，参与者应该坐下来，主持人应该读每一张蓝色便利贴。这样每个人都能听到其他人的想法。如果有人写字特别糟糕的话这种做法尤其有用。
\n

看看大家的想法有多丰富

步骤 4：投票与整理

现在每个人都理解时间线上有哪些的想法了，接下来就是投票和找出受欢迎的想法了。这样的话我们就能很快在每一组里面选出趋势想法并且对下一步需要开发的东西进行优先级排序。

决定时刻到了

如何投票

\n
• 给每位参与者发 6 个圆点。颜色无所谓除非你想突出某位利益攸关者
\n
• 给参与者 8 分钟时间对想法进行投票。最好不要让参与者随心所欲地进行投票，因为这样会太主观。相反，要给出具体的目标，比方说 “一周内可以做出原型的是哪个？” 或者 “什么能让这个人的一天好 10 倍？”
\n

投票

• 一旦所有参与者投票完毕主持人应该把所有贴上投票圆点的便利贴收集起来并且按照投票多寡进行垂直排排列

投票

投票

关于优先级排序

有了一个按照优先级排序的功能和想法清单当然很好，但是这个还不能决定哪些功能应该进一步开发。有些功能想法未必可行，比方说可能需要数月时间开发。这就是为什么此时我们通常会考虑蓝色便利贴的投入产出系数的原因所在。这样能够很好地让那些想法疯狂但是因为不能马上实施而被取缔提案的人心里平衡一点，同时还能让我们把注意力集中在可行的想法上。

影响 / 投入评估，高影响低投入是目标

重要的是要明确 “影响” 的确切含义，因为功能影响的对象可以是用户、企业或者特定的待解决问题。

实用 USM 的使用与采纳

正如我所说那样，我们把实用 USM 用到了每一位客户身上，但是下面是一些具体案例。

\n
• 我们帮助 eBay 的新服务 e Bay Plus28 想出新颖的受欢迎的补贴办法。尽管服务本身面向的是卖家，我们还是从买家的角度出发创建了时间线来考虑 Plus 服务提供为他们提供哪些优势。
\n
• 我们替德甲联赛映射了球迷比赛日和非比赛日的活动，从而帮助他们找出如何改进球迷的体验。这意味着我们需要创建两条独立的时间线进行研究。
\n
• 我们利用这个过程去替 Number2630 思考未来银行的样子，然后用所得结果建立了多个原型来进行测试。本案例的时间线从睡醒一直延伸到睡觉，里面考虑了很多细节，甚至包括用户去哪里吃。这让我们可以考虑颗粒度很细的通知和特别功能。
\n

更大的应用背景

至此，你应该已经有了一堆大家想出来并且投票选出来的的想法、功能建议或者解决方案了。当然，我还省掉了一堆应用用户故事映射前后的步骤。通常实用 USM 是在我们对用户知之甚少之时考虑的，所以我们一般会对用户角色有一个基本的假设之后但是还是还没有草绘出具体界面或者想出服务想法之前运用 USM。典型的 1日 产品发现研讨会一般是这个样子：

\n
• 一般性的介绍和产品 / 服务目标讨论
\n
• 创建精简的用户角色
\n
• 应用 USM
\n
• 对优选解决方案进行故事串联（Storyboarding）
\n
• 草拟潜在的产品 / 功能
\n
• 确定进行原型和测试的范围
\n

何时使用实用 USM

实用 USM 是一种非常通用灵活的做法，可以用到任何产品或者服务的迭代过程。实用 USM 操作成本很低并且容易尝试。同时你也可以在大范围推广之前先在一两只团队小范围内进行试验。我建议先在一些非关键性的事情上面试试，比方说产品的用户账号部分的升级，或者聚焦在现有用户流当中提高用户参与的机会（比如每周我们可以在什么地方给用户发送有用的通知）。

希望你有机会可以试试这个头脑分风暴的办法，最好把你的试验效果跟大家分享一下！