本系列文章一共分为 4 篇。本篇是前言。


图片来自《用户故事地图》

之前读完 Jeff Patton 的《用户故事地图》觉得是一本好书,但是一直没有机会去实践。最近在工作中使用了用户体验地图进行云之家工作汇报轻应用的开发评审,发现在讨论过程中,思路更加清晰、交流更加顺畅了。具体表现在:

  1. 开发人员能够很容易发现产品设计的坑;
  2. 小组成员的参与度更高;
  3. 决策更加迅速,会议更加高效;
  4. 会议结束后,有满意的讨论结果产出。

会后,更加觉得用户故事地图是一个可以提高协作效率的工具,所以,想写一篇“读书笔记&执行思考”,来记录这段时间的收获。

《用户故事地图》不仅仅是讲述什么是用户地图、怎么使用用户地图,也讲了很多团队协作的tips,并且给出了很多实例。我这里直接从这本书的其中一个角度——“ 怎么使用用户地图 ” 为内容,然后结合一些自己的想法,来写这篇读书笔记。

用户故事地图的使用,主要可以分为三个方面(当然,这个只是我自己的一个归纳):

  1. 产品的[0,0.5]:新产品功能规划/发布规划
  2. 产品的(0.5,1]:需求讨论/需求拆解/优先级排序
  3. 产品的(1,+∞):产品优化

下面将根据以上三个方面,详细进行说明。

两点解释:

( 1 ) 我很粗暴的根据“是否需要开发人员介入”这一条件,将产品发版前分为两部分,即产品的[0,0.5],产品的(0.5,1]。在开发人员介入前,更多的是产品经理如何进行产品设计,产品整个的基调和走向都是在这一部分定下来的。当开发人员开始介入后,就具体聚焦于功能的实现方面了。能否实现?如何更好的实现?是这一部分的主要问题。但是要解决这一部分的问题的一个大前提就是,开发人员如何全面的理解这个产品?让大家脑海里的东西是一致的?这个是最艰难的问题。

( 2 ) 上面三点的 “ 产品 ”,其实不仅仅指的是一个完整的产品,也可以是一个组件、一个大型功能。总之是需要进行思考、设计、开发并之后会有维护升级的一个模块。