当前位置: 主页 > 资讯动态 > 行业动态 >

超全面!关于用户故事地图的7种用法

时间:2017-10-09 14:54来源:港网整理 作者:港网整理 点击:
最近在工作中使用了用户体验地图进行云之家工作汇报轻应用的开发评审,发现在讨论过程中,思路更加清晰、交流更加顺畅了。

 

  最近在工作中使用了用户体验地图进行云之家工作汇报轻应用的开发评审,发现在讨论过程中,思路更加清晰、交流更加顺畅了。

  具体表现在:

  开发人员能够很容易发现产品设计的问题。

  小组成员的参与度更高。

  决策更加迅速,会议更加高效。

  会议结束后,有满意的讨论结果产出。

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

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

  用户故事地图的使用,主要可以分为三个方面:

  产品的「0,0.5」:新产品功能规划/发布规划。

  产品的「0.5,1」:需求讨论/需求拆解/优先级排序。

  产品的「1,+∞」:产品优化。

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

  两点解释:

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

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

  一. 产品的「0 ,0.5」

  当产品或某一个大型模块在进行功能设计的时候,可以采取用户故事地图的方式来梳理所有的功能点,并进行迭代周期的规划。

  新产品功能规划之产品全景图

  1. 目的

  建立产品/模块的全局印象,有全局观,进而可以整体规划产品/模块。

  2.适用场景

  产品经理(可能搭配交互设计师)梳理产品框架。

  3.所需资源

  2-3名参与人员(需包涵产品设计者、产品决策者)。

  卡片/便利贴,笔。

  4.操作方式

  一边讨论,一边将想要的功能写在卡片上。

  一边讨论,一边将将功能分类,按照x轴为模块名称,y轴为所属模块下的功能进行排列。

  一边讨论,一边调整当前的布局(可剔除/添加卡片、调整卡片位置)。

  5.解释/说明/tips

  1)为什么是2-3个人?

  对于有的项目,产品设计人和产品决策人是一个人,为什么还需要2-3个人呢?因为在我看来,一个人的想法是无法做到完善的,但是如果是两个人合作则可以避开90%以上的产品漏洞,所以在产品功能规划的方面,更建议2人以上(当然如果遇到牛人,思维无漏洞,一个人建立产品全景图也是没任何问题的)。不建议3人以上,则是因为对产品指手画脚的人多了,只会越来越乱,产品设计层面,要少而精。

  2)如果只是理个产品逻辑,为什么不用脑图:

  从操作方式也可以看出,这是一个需要团队合作的过程。脑图更像是一个人的思维梳理,不利于多人的团队合作。卡片化的优点在于:

  所有人都有调整布局的权限。

  没有了屏幕的限制可以支持高复杂度的产品架构。

  可以更方便的删减和备注。

  为了后续的操作。

  新产品功能规划之大家来找茬(功能点设计)

  1.目的

  对于关键的功能点或有争议的功能点,可以拿出来大家一起讨论,进而明确功能点的具体操作流程,减少踩坑的可能性。

  2.适用场景

  确定某个有争议的功能点的设计。

  3.所需资源

  3-4名参与人员(需包涵产品决策者、产品设计者、用户体验设计师)。

  产品全景图。

  persona卡片 及 scenario卡片。

  不同颜色的卡片/便利贴,笔。

  4.操作方式(以功能点A的设计为例)

  围绕A,各参与人员站在自己的角度,思考A在流程中可能出现的情况与问题,挑刺与找茬。

  围绕A,根据刚刚点意见,优化流程或提出更好的方式。

  将讨论结果在不同颜色的卡片/便利贴上写出,贴在功能点A的旁边。

  5.解释/说明/tips

  一定要围绕A,跑题太可怕,降低会议效率且达不到目的。

  一定要得出结果,更好的方案/保持当前方案不变。

  发布规划

  1.目的

  优先级排序,划分发布路线图。

  2.适用场景

  产品经理(可能搭配交互设计师)确定产品发布内容。

  3.所需资源

  2-3名参与人员(需包涵产品设计者、产品决策者)

  产品全景图

  4.操作方式

  按照产品的长线目标,对功能排优先级。

  制定产品发布计划,确保每一次的发布内容都是 MVP。

  5.解释/说明/tips

  如何排列优先级?

  我觉得书里面有一句话能够很充分的回答这个问题:

  聚焦于成果,即产品发布后用户能使用和感知的东西,切分发布计划应该以成果为导向。 ——《用户故事地图》P56

  怎么划分发布周期?

  同样也是聚焦于成果,每一个发布的版本希望能够达到什么样的效果,再就是,保证 每一个版本都是当前情况下的 MVP。

  二. 产品的「0.5 ,1」

  当产品形态及功能确定后,则进入到需求确认阶段。这个阶段是需要产品的所有参与者参与其中的,但是主要以开发人员为主,确认产品功能的可实现性。

  需求讨论 —— 大家来找茬

  1.目的

  与开发人员准确、高效地确认需求。

  2.适用场景

  产品的某一个迭代,需要确认需求。

  3.所需资源

  7名以内项目参与人员(需包涵产品设计者、用户体验设计师、开发人员),开发团队负责人必须参与,其他开发人员尽量参与(如果人数超过7人,可以采用金鱼缸协作模式)。

  产品全景图。

  迭代功能的较详细文档(可能是word文档、可能直接是设计稿、可能是更具体的故事地图)。

  4.操作方式

  各参与人员站在自己的角度,思考各功能点在流程中可能出现的情况与问题,挑刺与找茬。

  根据刚刚点意见,优化流程或提出更好的方式。

  将讨论结果在不同颜色的卡片/便利贴上写出,贴在功能点的旁边。

  5.解释/说明/tips

  1)为什么需要产品全景图?这样做有什么好处?

  产品全景图可以帮助开发人员建立整个产品形态,能够完全清楚当前的整体的开发内容,利于架构的搭建,代码模块化/复用等等。

(责任编辑:港网科技)
------分隔线----------------------------
推荐内容
Top

客 服 热 线

0763-3339822

您好,港网科技采取QQ热线,如果QQ没回复才,请拨此号码, 其他问题请提交工单或在上班时间联系,谢谢支持!