为什么设计师要懂皮克斯的「故事法则」？
为什么设计师要懂皮克斯的「故事法则」？
故事正在成为电影、游戏、数字产品当中的重要内核。《黑神话悟空》的制作人冯骥曾说，「中国故事不是说中国传统故事……是中国人讲的故事。我用我的视野和价值观，来看你，我甚至比你理解的还深刻。」
《哪吒之魔童闹海》票房破百亿，这座中国影史上的里程碑并不只是电影的成功，同样是故事的成功。我们在同一个叙事之下，协同共鸣。因此，故事，很重要。
「世界上最有影响力的人是讲故事的人。讲故事的人为下一代树立了愿景、价值观和议程。」——史蒂夫·乔布斯
当产品经理和用户体验设计师在与他人交流时，他们实际上是在讲述各种各样的故事。这些故事包括：
- 向工程师讲述如何打造出令人惊叹的产品
- 通过营销故事向潜在客户传递引人入胜的信息
- 向顾客讲述激励他们追求目标的故事
- 向高管和董事会讲述证明产品投资回报率的故事
艾玛·科茨在皮克斯工作期间，曾在推特发布一系列讲故事的基本技巧。这些技巧后来被称为「皮克斯讲故事的22条规则」。她分享了来自我们这代最伟大故事工厂的宝贵经验。
艾玛在皮克斯的所学所感，启发了作者反思自己作为产品人员和故事讲述者的经历。在过去几十年的软件开发过程中，作者讲过许多结构糟糕的故事，也学会了如何讲好故事。作者见证过优秀的产品经理如何通过故事让客户满意，也见过没有故事支撑的功能，最终无人问津的局面。
这里作者消化了艾玛提出的相关规则，并重新精炼出产品经理和用户体验设计师的七个讲故事的习惯。
明确故事的目的
我们运用用户故事、场景叙述、故事板和旅程地图等技术。我们很好地描绘了用户与特定产品功能交互时发生的情况。然而，我们经常规定应该构建什么，以及如何使用它们，但是相应的，忽略了根本的目的。
这个故事的潜在信息是什么？就像克莱顿·克里斯滕森所说：「人们不想买四分之一英寸的钻头，他们想要四分之一英寸的孔。」问问自己：我是在规定钻头的特性吗？还是在解释用户如何钻孔？而非阐明用户为什么需要在墙上打孔。
在开始撰写故事之前，我们需要知道为什么要讲这个故事，以及故事的目的是什么。用艾玛的话来说：
规则14——故事的核心问题：为何必须由「你」来讲这个故事？内在驱动力是什么？
展现角色的困境
在好故事里，同情和钦佩源自看到某人面对困难时经历的挣扎。如果不分享主角（我们的最终用户）面临的困境，观众（工程师）就不会产生足够同情，也不会付出额外努力解决问题。艾玛提醒我们，人类天生就喜欢优秀的弱者故事：
规则1——角色胜过情节：观众更欣赏角色为目标的努力，而非简单的成功或失败。
设定角色的目标
每个人都想为英雄加油。给我一个理由，为什么应该关心故事中的英雄角色，你又为什么希望她达成目标？如果她不能通过我们的产品达成目标，最终会发生什么？
如果故事里的英雄无法克服困难，她会失去什么？会丢掉工作吗？项目会失败吗？会损失数百万美元吗？艾玛建议我们在构建故事时，必须考虑失败的可能性：
规则16——赌注与风险：角色失败会失去什么？高风险会增强故事张力。
确保故事的可信度
故事中的每个场景都需要可信。我们都听过充斥荒谬情节的故事，然后我们就失去了对英雄的关心。
如果我们的故事缺乏可信度，就会失去受众——无论是用户的目标、风险还是他们克服障碍的过程，都必须可信。与其让开发工程师被动地接受产品验收的高标准，不如借助好故事，让他们主动支持英雄，也就是我们的用户。
规则15——换位思考，代入角色体验：如果你身处故事世界，你的真实感受会如何？
结构清晰的故事
每个故事都有开头、中间和结尾。好故事的中间部分结构清晰。就像精彩演讲那样，讲述产品功能时采用「讲述-展示-讲述」结构更有效：先说明即将发生什么，展示你是如何理解用户的需求；接着演示事情发生的经过和结果；最后解释为什么要关心这个结果。如果目标未达成，又会有什么后果。
「讲述-展示-讲述」的方法常用于售前演示，也适用于产品管理和用户体验设计。要将其提升到皮克斯水准，我们可以应用艾玛推荐的 Kenn Adam 故事框架：
规则4——故事结构的万能公式
「从前有个____，每天____，直到有一天____，正是因此____，最终____。」
可汗学院关于这种叙事方式，专门开设过课程来进行分析和讲解，并且证明这种叙事结构具有强大的表现力！对于购买产品的人而言，维持现状的痛苦必须大于改变的痛苦。在这个框架中：「每天」是现状，「有一天」是打破平衡的事件，「因此」陈述的是通过采用这一产品获得的好处，「最后」是长期价值的延伸。这种叙事格式实在是非常实用！
创新与迭代
谁想听软件供应商重复相同的故事？你的故事又有何不同？你可能想要同样的「从此幸福生活」结局，但故事过程当中又有哪些创新？艾玛建议，不要害怕更迭，要做多次迭代：
规则12——第一直觉给你的想法可能是陈词滥调：否定首个出现的创意，深挖第二、第三层甚至更多层次迭代后的灵感。
从结局开始
规则7——先写结局：结局明确后，中间的故事发展会自然成型。
当所有事物都被准备就绪摆在眼前时，我们往往因为信息繁杂千头万绪，而不知道如何衡量，怎样抵达成功。做产品的时候，功能已构建好、交付、然后发布……那么接下来应该看什么？你的目标又是什么？预期的关键结果又是什么？倒过来，从结局开始规划，反而可能是更好的策略。
这种方法提供了校准的基准，让我们在变化发生时，可以重新评估决策，并驱动我们去迭代故事，调整范围。
停止编写用户故事和验收标准的条目清单吧，停止演示功能和罗列优势声明。讲个好故事，你终将拥有充满激情的团队，他们会打造出客户喜爱的产品。