第二章对于用户卡的描述，其实是在界定描述细节的界限。如果界限界定过于细致，在描述和理解方面则会造成很大的阻碍，也会给工作前期带来更多的工作量。我觉得，用户卡需要描述功能的大概并给读者适当的引导则以。
开发人员缺少领域和技术知识将会造成开发人员不能理解故事。没有领域知识将没有具体的解决方案，不能讲故事分解为小的故事，问题将得不到解决。
第三章阐述的用户角色的例子让我了解到了用户群体的多样性。人们各自不同的心理和需求导致他们对于产品的依赖是不一样的。这让我想到了起一阵子经常玩的游戏，因为某些设计理念的原因，游戏角色的AI设计并不是很完美。在我看来，这些AI只要上代码就可以轻易实现，所以觉得卡片AI低十分气人。但有的人却不这么认为。每天泡在游戏上10个小时以上的玩家会因为一点小错误而耽误半个小时以上时间，而偶尔逛逛的玩家发现游戏闪退之后可能今天就没上过游戏。这样理解，哪些东西需要解决，急需解决，心里就有数了。
我看到了头脑风暴的这一块，我很理解在气氛和思路的互相影响下，每个人都会有着超越平常的思路和观点，这很有利于解决问题。令我耳目一新的是，角色卡片的重叠来表示某个人适合两种角色的方法。这很有效果。刚觉得很不错的表达关系，却是用来在整合角色时删除用处小的角色的方法。可以用其他角色代表角色删掉了，每个卡片都独立存在。后来又谈到了虚拟人物和极端人物，读着的时候，我就问自己，这样节约的时间有可能还没有耗的时间多呢，果然，作者有了解释，这可能会带来一两个灵感。这种态度非常可取。
作者将需求比喻成了鱼，将捕获需求的行为比喻成捕鱼。需求像鱼一样，会死亡，也会产生，没有捕到鱼，却捕到了残害则是需求膨胀的缩影。
捕捉需求，询问用户时，询问的方式也很有讲究。其实，生活中很多交流也符合书中的定义和症结点。不要用封闭式的询问方式。询问是与否，虽然回答的权利在用户，回答的也是自己更倾向于选择的，但只针对于这个问题，而不是用户自己在所有情况下的真实想法。所以，不管在交流还是在询问需求，应当尽可能的多描述一下不同情况的优缺点，要让对方在利弊之间抉择，而不是在是否之间。