如何用故事设计的方法做需求分析？

人人都是产品经理 • 5年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

笔者从写小说、设计故事的思路出发，类比了如何用这一思路做需求分析。

如何用故事设计的方法做需求分析？

故事的起点

平时我会写一些超短篇的小小说来练练笔，因此如何通过设计故事情节来突出我想要表达的思想是我在每次写小说以前必做的事情。我自己的经验是首先定义好核心思想，然后在这个核心基础上根据自身的生活或是所知所得设计一个主线故事，然后再通过主线故事穿插设计一些支线故事来凸显人物性格、提升故事感情等作用。

当我的工作从一个单纯的执行者过渡到一个策划者与执行者的时候，我开始需要去构思一个产品框架，同时为一个从0到1的产品去定义好各阶段要做的事，分清轻重缓急，这也是每一个产品设计人员要做的事了。

需求设计、需求分析与需求管理是一个产品必做且常做的事。我所说的需求，可能是来自上级们的想法，可能是来自用户的反馈，可能是通过自己的思考而得出的想法，此时会有很多很多的想法想要融入到产品中。

那么问题来了：

我应该先实现哪些想法？
需要实现的想法我应该如何划分优先级？

关于这两个问题，都有直接可学习参考的方法论可以使用。不过我在这里并不是想要和你讨论这些方法论的定义和如何做，每个人的工作内容与面临的背景都不一样，在已有方法论的基础上基于我的情况，我是如何做的，是我想要分享给你的。

那么现在欢迎来到我的故事。

怎么设计一个故事

（一）小说主线故事与产品核心功能

在文初我提到，我有时会去写一些很短篇的小说，那么就让我把我所负责设计的产品比喻为一部小说。每部小说都有一个主线故事概要，那么每个产品也有一个故事概要，便是这款产品为谁解决了什么问题。以下我便以国民APP微信举例。

微信的故事概要就是解决了全年龄层用户即时通讯与社交的问题。当我用一句话描述了我的产品，就好似我用一句话概括了我的小说核心。那么现在我要介绍我的小说故事，此时我会告诉你一个主线故事梗概，这个故事会有多个模块组成，通过这些模块中的各个小故事充分的去体现我的思想。产品的主线故事梗概，便是为了满足故事概要所设计的各个核心功能。例如微信的即时语音文字通讯，通讯录管理以及朋友圈等社交功能。

现在我介绍了一本小说的概要，描述了主线故事梗概，让你大致了解了这是一个什么故事。

我说明了一个产品为谁解决了什么问题，描述了为解决这个问题所提供的方案的组成功能内容。

接下去的内容其实你也能想到了。在阅读小说时，你了解了故事的大致内容以后，就会去探索小说中具体发生了什么故事，这一个个小故事组成了一个完整的主线故事，便构成了一部小说。

在使用产品时，你了解了我的产品可以帮助你解决什么问题，接着就去探索产品中是通过哪些核心功能帮助你解决问题，在使用这些核心功能时，你体验到了组成这些核心功能的一个个小功能，从而了解了这款产品。

在此做一个总结，我将一个产品分成了一个四级树状结构，具体如下：

产品是什么，为谁解决了什么问题。
主线故事提供了具体的解决方案。
各个功能模块组成了核心功能，进而提供了完整的解决方案
每个功能模块都由众多小功能组成。

（二）精彩的主线故事与充满魅力的支线故事

在我们阅读一部小说，或是阅读一个故事时，不仅会关注发生在主角身上主线的故事，同时也会去了解与主角相关，但是并不一定与主线相关的支线故事。

主线故事帮助我们了解贯穿整个作品全局的内容，而支线故事更多时候是帮助完善主线故事，丰富因主线故事内容不足造成的角色性格薄弱的问题。有时一个好的支线故事，在回归到主线或是和主线产生关系以后成功让故事得以升华，让人念念不忘。

不妨通过我喜欢的几个故事体会一下主线与支线故事配合的魅力，大家如有兴趣可以详细了解以下几个故事里的支线故事。

火影忍者卡卡西外传

在作品中卡卡西一直是一个慵懒且充满故事的角色，通过卡卡西外传讲述了卡卡西父亲的死因以及带土的死因，从而完整的塑造了卡卡西的性格以及角色。这些支线故事和后期忍界大战带土作为BOSS出现产生了联系，让人不胜唏嘘，伏笔的回收让故事得以提升一个台阶。

仙剑奇侠传4怀朔

怀朔是慕容紫英的师侄，对自己的师妹璇玑十分好。在故事中期，听说璇玑想要夏鸣虫，便去帮她抓。怀朔后来为保护慕容紫英，被同门杀死。故事后期琼华派为飞升提升门派至半空中，致使部分修为低的弟子死去，璇玑便是其中。最终决战中主角团发现了在怀朔房间前的璇玑尸体与夏鸣虫，不由得再次让人回忆起怀朔，让整个悲剧的氛围更加浓烈与感染人。虽然这是一个可以不触发的支线故事，但是有了这个故事让主角的所作所为更合理，同时情感的渲染更强力。

《家》

巴金先生的《家》这部作品描写了高家三个孩子的故事，其中大哥高觉新的故事充分的说明了那个时代家庭的无奈，他与妻子的一切都在家人的安排中，他从无反抗。而可以跟随自己所想而去生活的小弟高觉慧让他羡慕不已。大哥高觉新的支线故事充分的透露了时代的无奈，对比下更加凸显了追逐自由中心思想与作者想要表达的内容。

以上只是我自己比较喜欢的三个故事，你可以带入你自己喜欢的故事去思考。前文我谈到小说与产品的联系，那么通过这个联系我把支线剧情理解为组成产品核心功能但有时并不是那么重要甚至可以没有的功能，而有了这些功能可以为产品锦上添花，提升用户的喜爱程度。

不妨做这么一个类比：

即时通讯、朋友圈、支付与公众号等功能模块组成了微信的核心功能，但是微信还提供了方便的消息记录转移功能，这个功能许多时候用不上，不过微信依然提供了一个使用体验很好的方式帮助用户实现了消息记录备份转移的功能，进一步巩固了这个沟通与社交软件的核心功能。

就好像故事里的支线如果可以回归到主线或是与主线有联系可以帮助读者更加陷入故事中一样，好的支线功能可以帮助用户更加舒适的体验产品，解决更多的问题。那么如何定义产品的主线故事和支线故事呢？以下是我的理解。

主线故事：满足为目标用户解决问题提供的具体功能。
支线故事：大多时候未必与核心功能直接相关，但是可以帮助完善、巩固核心功能的次要功能。

其实主线与支线并非固定不变，例如微信刚加入公众号功能时，未必就是一个主线故事，公众号并没有直接满足沟通以及社交的需求，但是却有效的拓展了微信的局限，成功将微信拓展为一个更加全面的社交工具，从而在后来发展为主线故事。

（三）做个小结

基于故事和产品的联系，以及主线故事和支线故事的关系，我便把产品的功能分成了四个等级，其中顶级的产品是我们的最终目标，而二到四级则是我们要去完成的事，便是——需求设计、需求分析与需求管理。

如何用故事设计的方法做需求分析？

如何评估好故事设计中各个故事的重要程度与优先级

（一）先确定你是否需要这个故事

我每一次构思一个故事的时候，总会先想一个问题，我要把之前想到的一个情节加入进去吗？同样在设计产品功能的时候，我也会去思考一个问题，这个功能是一个需求，我要将其加入到产品中吗？

这个问题换一句话说，就是需求分析了。

关于需求分析，虽然有不少方法论可以参考，但是面对不同产品、不同团队、不同背景的情况下，强行代入方法论往往并不能得到有效的结论。其实从每一个功能确认落地到需求，大致可以分为两类。

从无到有，增加功能

这个分类是最为头痛的。在没有数据验证的情况下，谁都无法保证新增的功能一定是满足用户需求的，此时便陷入了恶性循环：无法确认功能是否可行——不敢第一时间开发——无法满足用户——继续思考功能。最可怕的就是找不到解决问题的方法。

已有功能，完善功能

这是一个容错率较高的需求分类，就算未达预期，因为前提的功能已经满足了用户，那么可以之后继续优化。

第一个分类可以总结为为用户提供了一个待确认的解决方案。这个解决方案可能帮助用户解决了新问题，或者是巩固完善了之前问题的解决方案，我称之为决定性问题。新功能一般承载着拓展产品局限，提升用户好感的重任，如果用户反馈不佳则可视为新功能未达预期，则有可能在之后的迭代中被弱化，以至于成为支线故事。

第二个分类可以总结为为用户提供了提升解决方案效率的方案。这个方案帮助用户可以更加舒适的使用已有的功能更快、更好的解决自己遇到的问题，我称之为效率性问题。效率性问题具象化程度更高，且更容易把握，例如用户界面的优化、操作流程的优化或是加入其他提升用户体验的功能。这一类需求大多在产品步入正轨以后成为产品需求的主力，即从框架建设进入细节雕琢的阶段。

那么我要如何分析提出的功能是否为需求呢？

依然以微信为例。微信的定位是社交通讯工具，那么这个产品的核心则在于社交、通讯这两点。在未加入支付功能之前，微信的定位是十分清晰的，就是一个移动社交通讯工具，而远非现在的工具平台。那么当时的微信加入包含收支的支付功能是否算是一个需求呢？

作为社交通讯工具，加入支付功能其实从表象上与社交与通讯主线故事的关联并不大。因为支付功能无法帮助直接促进社交氛围更好以及提升通讯功能效率。那么为什么依然要加入支付功能呢?

如果微信仅有即时通讯、朋友圈这些常见的通讯、社交功能，那么这个产品依然无法提升差异化程度，容易陷入同质化中。毕竟从当时的情况来看飞信以及米聊也可以加入类似的功能进行竞争。而支付功能除了拓展了工具功能以外，对于微信而言更重要的一点在于加入了收发红包功能。

源于我国特色的红包传统与社交行为相关，而红包的钱从何而来呢？此时支付功能便提供了最佳助力。因此当尚无法定义功能是否未需求之时，可以分析这个功能是否可以回归到主线，有些人会将其称之为闭环思维。

通过以上的分析可以得出结论，加入支付功能是一个可能提升微信社交品质的需求，那么接下去就可以通过灰度测试等功能进行验证了。

增加功能充满了许多的未知性，所以这一点才会让我们望而却步。这些从无到有的功能需要设计者有足够的判断力、经验以及分析能力，但是依然无法完全保证可行性，所以在及时验证通过后方可确认为是一个需求，是否可以列为未来可优化的需求。

针对这类需求的分析，建议如下：

当下需要新增的功能，是否可以回归到主线。如果可以，这个功能对主线的贡献是否显著，若无法确认则可以小范围测试进行验证，切勿盲目大范围开发上线试错，为自己预留调整的空间。
任何人提出的功能需要再次抽象，即问自己两个问题，他为什么需要这个功能，解决了什么问题。因为不同角色总会从当下遇到的情况出发提出一个表象的解决方案来解决当下遇到的问题。而产品设计者需要在这个基础上在提升一下自己的思考维度，发现这个方案之后遇到的问题是什么，比如说当时微信加入支付功能时最佳的辅助对象是发送红包提升社交功能竞争力，而不是建设金融平台。

对于功能完善类的需求，由于已有前提功能铺垫，所以这类需求问题分析起来都会更有把握，试错成本也更低，在此便不多赘述了。

简单的做一个总结，其实以上思路灵感来源于我自己了解了KANO模型后的一些尝试。经常有人对我说，要把问题量化。但是我觉得量化容易让自己陷入一个桎梏，盲目相信数值，忽略使用者的感受，毕竟我们打交道的是人。所以基于KANO模型，对于需求的定义，我整理为以下几个准则：

加入的功能是否能让用户眼前一亮并为他们解决决定性问题。如果是，那么这样的功能需要优先系统性的思考并尽早完善为需求。
加入的功能是否只是帮助用户锦上添花的解决了问题，并未提升效率。如果是，那么这可能并非是需求，只是遇到了一个问题后的感受。如果否，则这是一个较为重要的需求，有效解决效率性问题是产品设计工作中内容占比十分大且重要的内容。
针对不同角色来思考，每次的需求满足范围如何，如果只是解决了极少数人的问题，有必要重新回顾自己的分析历程。

（二）确认每个情节的重要程度与优先级

记得我曾经构思了一个剑侠的故事，我为其构思了精彩的前传，但是前传对于主线而言意义并不大，算是一个补充阅读。后来我便将这个小故事放在了我主线故事之后作为一个补充章节。

不论是产品战略与功能架构设计者，还是以执行为主的执行人员，确认重要等级与优先级是必须要面对的问题。解决这个问题有一个十分有效的方法，就是根据重要程度与紧急程度分为四象限，想必这个方法大家都不陌生了。

但是问题就在于，该如何定义重要程度与紧急程度呢？运营在使用后台时告诉我，现在的编辑器太难用了，影响了她的工作效率，需要尽快解决。用户在使用APP的时候告诉我，为什么APP还不支持信息检索功能，导致她每次搜素通讯录十分费劲。每个人都觉得自己的问题很严重，很紧急，这该如何是好呢？

让我们回到前文的四级故事架构，即需求架构。

如何用故事设计的方法做需求分析？

重要程度的判断

对于产品的定位与核心功能，设计者肯定是十分清晰明了的，主线故事要做什么大家也是知道的，主线故事的各个组成部分大家也是明了的，那么基于这个结构如何定义重要等级呢？

这里的重要程度划分是这样的，主线优于支线，一级故事优于二级故事。

我将支线故事划分在了二级故事，则自然支线故事下的各故事重要程度要放在主线故事的一级故事之后。例如产品的用户界面优化，这个事情非常重要，但是如果同时有其他不论是新增还是完善的一级故事需要设计，都放在其之后。因为一般的支线故事更多的作用的是提升效率、提升体验，并没有帮助产品拓展局限与解决新的核心决定性问题。比如常见的在APP中加入用户反馈功能、提升用户界面的视觉效果以及其他效率性问题，他们很重要，但是并不需要每次都很重要。但是如果某个支线故事的二级故事有助于主线，那么此时需要酌情将其重要等级提升，比如之前提到的微信加入支付功能，对于社交通讯而言支付不重要，但是对于发送红包这个核心社交行为而言，支付的收支功能决定了核心的社交体验是否能够提升。

支线故事的重要等级判断是很清晰的，那么主线故事的重要等级判断就不是那么明显了。组成主线故事的内容很多，但是每个模块对于核心功能的刺激作用是不一样的。例如微信发现功能中的朋友圈与游戏两个功能，都属于社交功能。朋友圈定位的是所有用户，游戏更多的偏向于年轻且喜欢游戏的人，此时在重要等级的划分上自然是朋友圈优于游戏。所以对主线故事刺激作用的显著程度是判断重要等级的衡量标准，刺激作用的显著程度，判断依据如下：