《用户故事地图》是一本由Jeff Patton著作，清华大学出版社出版的平装图书，本书定价：59.00元，页数：260，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。

《用户故事地图》读后感(一)：《用户故事地图》读书摘要（未完待续）

使用故事地图的必要性 边讲边记，在讲故事的同时，通过写卡片或便签来具体化你的想法。 先努力了解业务成果，而不是具体要开发什么功能:为什么要开发？人们能从中得到什么收益。能解决什么问题？ 刻画用户:不同类型的用户，使用的功机，使用的方式，具体功能 “软件开发的目标从来不是开发所有的功能，而是开发尽可能少的功能” “想做的功能，总远远超出你来得及开发的” 一个用户一个卡片，卡片上写上有诉求。 使用用户故事地图可以提前识别产品创意中有哪些坑” 从左到右是大故事的步骤 先确定宽度:有哪些大的故事。 从上到下是细化

拆分的细节分别放在大故事的下方。 大故事的停留:这一步做什么？其他选择？优化？故障处理？ 为了能够到某个截至日期前使用，通常并不需要开发所有这些功能。 聚焦于系统外的预期成果来决定系统内需要什么功能。 如果不知道目标成果，那么排优先级将无从谈起。MVP最小可行产品是为验证假设而做的最小规模实验 把第一个产品当作试验品，其后的版本是不断实验的结果，直到证明产品是对的。 迭代直至可行: 先向核心用户提供比最小可行更小的产品，每个月添加一点功能，收集并听取反馈，慢慢为产品增加功能和提升既有功能。当核心用户可以自如使用并向他们推广时，便可以放心地推向市场。 开发的迭代过程应该是像画画一样不断的打磨产品。而不是像盖房子那样每一步都计划好了，不容更改

如何创建故事地图 用户任务就是构建故事地图的基本模块 任务就是做的事情，大任务可以细分成更小的任务。 海平面在中间，而其他层级在海平面之上或下。 海平面级别的任务，是指我们会连贯完成的任务。完成后再做别的。 按发生顺序从左边到右边。 细节、替代、变化和异常，构成了故事地图的主体。请将这些内容放在同一列海平面下方。 如果考虑真实的用户如何使用软件产品解决问题的场景，通过故事地图的路径几乎是无穷多的。 在海平面上方，请放置活动。

活动:一群相似的人在相似时间完成的任务组成，旨在达到特定的目标。这些活动也组成叙事主线。 活动构成故事地图的主干 用切分地图找出达到一个具体结果需要完成的任务目标请放在最左边。海平面下方再画出来一条海平线2号。在这之间就选出达成目标直接关联的任务卡片。其他卡片放到海平线2号下方 痛点:没有收益、令人讨厌的事情 乐趣和奖励:有趣、值得做的事情 问题:人们为什么会这样做？做的过程是怎样的？ 创意:人们所做的事情或者我们开发的功能，能够消除痛点和提升乐趣 故事地图六步法(P98） 1、问题:用户是谁，带来什么价值 2、构建全景图。广度优化 3、探索。向深度拓展 4、制定发布策略。 5、制定学习策略。 6、制定开发策略。 同一份文档不同人阅读得到的信息也是不同的 最佳的方案需要开发团队和用户一起协作 团队聚集在一起对用户故事地图进行充分讨论，才是运用用户故事的正确方式 要对解决的问题达成一致的理解。 一个或许可行的模板结构:作为某某某，需要什么特性，以便解决什么问题。 提高讨论效果的检查单(P115): 1、讨论用户角色 2、讨论要做的功能 3、讨论为什么 4、讨论软件之外的东西 5、讨论异常情况 6、讨论问题和假设 7、讨论更好的解决方案 8、讨论方案如何实现 9、讨论开发周期

待续……

《用户故事地图》读后感(二)：初读《用户故事地图》

这本书买来放了快半年，这两天拿出来较快地看了一遍。讲一下初览的感受吧。 此书名《用户故事地图》，当初买的时候本来是想着学习一下如何具体的学习绘制完整的用户故事地图。但是，看过之后，发现并非是全讲故事地图的，对于讲述创建故事地图，单纯地说只有第五章的内容。所以，如果有和我一样的想法的人，可能要出乎你的意料。 但是，尽管我是较快阅读的，特别是最后好几章内容看得是只认字不识意的境地，这本书还是值得看一遍的。看完后，我的整体初步理解是作者以故事的方式讲述自己对产品开发，特别是诸如软件、网站、APP等互联网产品的开发过程与流程。这里的“故事”一词，我有两层理解： 一是运用讲故事的方式进行产品整个开发流程。这样使得产品设计中的用户研究，需求发现归纳，原型设计，开发，上线后的维护等整个流程始终有一条线连着，既有整体，又有部分，从整个产品分析部分，思考部分又要时刻关注整体，相互联系着，从不不会在某一个流程跑偏而浑然不知，避免上线后才发现问题而造成更大的时间、人力、资源、资金等方面的损失。用作者的话就是要对产品有全景把握，对产品全貌保持健康的理解和讨论。

二是在产品设计开发中应该用讲故事的方式进行团队成员沟通。作者认为人都是有自己的思考的。面对尽管相同的需求文档，但是不同职位的人员对相同内容的理解是不一致的，甚至会有非常大的差异。而讲故事的方式中，各成员聚在一起，面对相同问题，各抒己见，表达看法，通过交流，辩论，图片，视频等多种具象的形式才会真正的地形成认同。这样才会让不同职位的人员齐心协力解决共同的问题而不会出现大的偏差。

对于想我一样的设计新手来说，实践经历偏少，所以对于书中的许多内容理解的并不透彻，更多的是让自己对未知的知识有了解。

初步最大的感触与收获是作者的三个观点。一是产品设计中始终始终要有全局观。对大项目拆解中，在小项目的实际开发中都要始终记住整体与部分的联系，否则就会跑偏，导致项目失败。二是对于一个产品，必须要弄清楚用户、解决的问题以及相应的原因这主要因素。只有弄清楚之后才会使项目更具针对性，有目标，踏实。并且，在项目推进过程中，也要时不时将自己进行的工作和三要素比照，以防走偏。三是要始终思考并关注根本上的，更深层次的问题，也就是要多问问自己为什么，而不是而不是流于表面。而设计中往往也会有许多人将某阶段性的成果当做最终的结果。就像作者所说，上线的软件并不是我们要的结果，我们要的是用户使用并乐于使用自己开发的软件解决自己的问题，为用户创造好的体验，这才是团队成员最应该关注的。就如之前在造就talk上江南大学辛向阳老师的演讲中所提到的一样：他说学生在做服务设计中，经常提到的就是顾客旅程，商业画布，然后做系统并推广。他强调这并不是服务设计，这些只是接触点和工具，是过程和方法，用来帮助理解利益相关者并不是结果。

书中许多内容还是结合作者的工作案例讲述的，虽不完整。但行文过程中提及了许多实际工作中有用的小方法以及应避免的坑，有空多浏览几次，加强一下印象常用运用在工作中也是不错的。

由于此书作者采用了先总后分、先略后详的编排形式，所以在看书时，前半部分已经将整书总体概述了，后面的便是详细阐述，以便用户深入理解，会觉得前后经常重复，感觉比较啰嗦吧。

此外，我觉得这本书所讲述的设计流程应该还是一定的理想性的吧，只是在国内大多公司应该是如此的。很多都是一份需求文档，有的还是很简单的百来个字的扔给设计师，行业状态吧。

最后，个人觉得这本书还是值得看几遍的，里面的许关观点和方法还是很有价值的，理解记忆他们能在潜移默化中改变自己在设计中以及生活中思考问题的方式，这才是最重要的。这是初次快速看一遍之后的感受，之后还会抽时间在看一遍，新的感受到时补充。

《用户故事地图》读后感(三)：冲着作者的背景，也要看看哟

好吧，算是我“老”不正经，被作者的幽默带坏了。

作者挺可爱，笔触很风趣。一口气读下来是值得的。

本书有很多产品开发的启示。从全局观到细节，无所不包。

也许，因为他幸运地遇到很多好的专业团队，职业岗位介绍于目前初级阶段产品研发的我而言，是有一点点多元化的，大致能明白，但他说到的故事全景图，真的有点令我着迷。

如果你需要开发一个大型网站产品。

如果你需要开发一个改变世界的软件。

如果你需要研发产品，希望知道产品是否适合你的目标市场。想知道怎么做。

如果你需要组建研发团队。

如果你需要精进研发团队的沟通，希望创意落地。

如果你需要很有魅力地讲述一个故事。

如果你需要知道如何迭代产品。

....等等等等。

这本书，你都该看看。只不过，坦白说，内容丰富到爱上，可还是有些凌乱的，这也是为什么它没有在我心目中获得五颗星。

请用微信扫添加公众号