发布时间：2019-2-18 分类： 电商动态
最近，用户体验地图被用于审查云家庭工作报告灯应用程序的开发工作。结果发现，在讨论过程中，思路更清晰，沟通更顺畅。
具体表现是：
开发人员可以轻松识别产品设计中的问题。
团队成员更多参与。
决策更快，会议更有效率。
会议结束后，讨论取得了令人满意的结果。
会议结束后，我觉得用户故事地图是一种可以提高协作效率的工具。因此，我想写一篇文章“阅读笔记和执行思维”来记录这次的收获。
《用户故事地图》这不仅仅是关于用户地图是什么，如何使用用户地图，还有很多团队合作的提示，并提供了很多例子。我在这里直接从本书的一个角度来写这个阅读笔记——“如何使用用户地图“对于内容，然后结合我自己的一些想法。
用户故事地图的使用可分为三个主要区域：
产品的“0,0.5”：新产品功能规划/发布计划。
产品“0.5,1”：需求讨论/需求拆卸/优先排序。
“1，+∞”产品：产品优化。
基于以上三个方面，将详细说明以下内容。
两个解释：
根据“开发者是否需要参与”的条件，即产品的“0,0.5”和产品的“0.5,1”，我非常粗鲁地将产品分成两部分。在开发人员介入之前，产品经理设计产品的方式更多。产品的整体色调和方向在本部分中确定。当开发人员参与其中时，他们会专注于该功能的实现。可以实现吗？如何实现它更好？这是本部分的主要问题。但解决这部分问题的一个重要前提是，开发人员如何完全理解这个产品？让每个人心中的事情保持一致吗？这是最困难的问题。
以上三点的“产品”不仅是一个完整的产品，而且是一个组件和一个大功能。简而言之，它是一个需要考虑，设计，开发，然后维护和升级的模块。
1.产品的“0,0.5”
当产品或大型模块设计用于功能时，用户故事地图可用于对所有功能点进行排序并规划迭代周期。
新产品功能规划的产品全景
1.目的
使用全局视图建立产品/模块的全局印象，然后整体规划产品/模块。
2.适用场景
产品经理（可能与交互设计师合作）梳理产品框架。
3.所需资源
2-3名参与者（包括产品设计师和产品决策者）。
卡/便利贴，笔。
4.操作方法
在讨论时，在卡上写下所需的功能。
在讨论时，将对功能进行分类，x轴为模块名称，并为模块下的功能安排y轴。
在讨论时，调整当前布局（可以删除/添加卡片，调整卡片位置）。
5.说明/描述/提示
1）为什么2-3人？
对于某些项目，产品设计师和产品决策者是一个人。你为什么需要2-3个人？因为在我看来，一个人的想法不可能是完美的，但如果是两个人，你可以避免90％以上的产品漏洞，就产品功能规划而言，它超过2人（当然，如果你遇到奶牛，思维上没有漏洞，为一个人创建产品全景没有问题）。如果你不建议超过3个人，那是因为有更多的人对这个产品很傲慢。它只会变得越来越混乱，产品设计水平应该越来越精细。
2）如果您只想管理产品逻辑，为什么不使用脑图：
从操作模式还可以看出，这是一个需要团队合作的过程。大脑地图更像是一个人的思维，这不利于多人团队合作。卡片化的优点是：
每个人都有权调整布局。
没有屏幕限制来支持高度复杂的产品架构。
删除和备注可能更方便。
用于后续操作。
大家都在寻找新的产品功能规划（功能点设计）
1.目的
对于关键功能点或有争议的功能点，你可以拿出每个人讨论，然后清除功能点的具体操作过程，减少踩到坑的可能性。
2.适用场景
确定一个有争议的特征点的设计。
3.所需资源
3-4名参与者（包括产品决策者，产品设计师，用户体验设计师）。
产品全景。
角色卡和日程卡。
不同的颜色卡/粘滞便笺，钢笔。
4.操作模式（以功能点A的设计为例）
在A周围，每个参与者都站在自己的视角，思考A在过程中可能遇到的情况和问题，挑选和发现错误。
围绕A，基于获得建议，优化流程或提出更好的方法。
将讨论结果写在不同的色卡/海报上，并将其贴在功能点A旁边。
5.说明/描述/提示
一定要围绕A，问题太可怕，降低会议效率，实现目标。
一定要获得结果，更好的解决方案/保持当前计划不变。
发布计划
1.目的
优先排序并划分释放路线图。
2.适用场景
产品经理（可能与交互设计师一起）确定产品发布。
3.所需资源
2-3名参与者（包括产品设计师和产品决策者）
产品全景
4.操作方法
根据产品的长期目标确定功能的优先级。
制定产品发布计划以确保每个版本都是MVP。
5.说明/描述/提示
如何优先排序？
我认为书中有一句话可以完全回答这个问题：
关注结果，即用户在产品发布后可以使用和感知的内容，拆分发布计划应该以结果为导向。 ——《用户故事地图》P56
如何划分发布周期？
它还关注结果，每个版本希望实现的效果是什么，然后确保每个版本都是当前情况下的MVP。
2.产品的“0.5,1”
确定产品形式和功能后，进入需求确认阶段。此阶段是产品的所有参与者的参与，但主要基于开发人员，以确认产品功能的可实现性。
需要讨论——每个人都在寻找茬
1.目的
与开发人员准确有效地确定需求。
2.适用场景
产品的迭代需要确认要求。
3.所需资源
7个项目参与者（包括产品设计师，用户体验设计师，开发人员），开发团队负责人必须参与，其他开发人员尝试参与（如果人数超过7人，则可以使用金鱼坦克协作模式）。
产品全景。
迭代函数的更详细文档（可能是word文档，可能是设计草案，可能是更具体的故事图）。
4.操作方法
参与者站在他们自己的角度，思考每个功能点过程中可能出现的情况和问题，挑选和发现错误。
根据评论优化流程或建议更好的方法。
将讨论结果写在不同的色卡/海报上，并将其贴在功能点旁边。
5.说明/描述/提示
1）为什么需要产品全景图？这样做有什么好处？
产品全景图可以帮助开发人员构建整个产品表单，充分了解当前的整体开发内容，便于构建体系结构，代码模块化/重用等。
2）需要注意的一点是：在此过程中，您需要控制，尽量不扩展新功能，并且不要在很宽的范围内修改功能。如果大规模修改功能，则不建议直接使用会议结果作为最终结果。因为最初的计划经过深思熟虑，并且在会议上，人们太兴奋了，不能冲动，冷静下来，想想该计划也会发现会议结果可能存在很多漏洞。
故事的细分——故障下的故事
1.目的
将当前故事分解为开发人员可以接受和开发的故事。
2.适用场景
当产品的故事太大时，开发人员需要进一步完善故事。
3.所需资源（与要求中讨论的资源一致）
7个项目参与者（包括产品设计师，用户体验设计师，开发人员），开发团队负责人必须参与，其他开发人员尝试参与（如果人数超过7人，则可以使用金鱼坦克协作模式）。
产品全景。
迭代函数的更详细文档（可能是word文档，可能是设计草案，可能是更具体的故事图）。
4.操作方法
在多方讨论中，根据发展需要分割大故事。
在卡片/海报上写下拆分故事并将其粘贴在相应的大故事旁边/旁边。
5.说明/描述/提示
产品经理不应过多干扰技术人员的拆卸。如果他们不参与原则，他们如何与他们一起发展？
优先化
1.目的
开发人员在一次迭代中对开发内容进行排序。
2.适用场景
在“需求反汇编”之后，输入优先级顺序是很自然的。
3.所需资源（与要求中讨论的资源一致）
7个项目参与者（包括产品设计师，用户体验设计师，开发人员），开发团队负责人必须参与，其他开发人员尝试参与（如果超过7人，则可以使用金鱼坦克协作模式）
产品全景
迭代函数的更详细文档（可能是word文档，可能是设计草案，可能是更具体的故事地图）
4.操作方法
在多方讨论中，对已拆分为粒子的故事进行排序。
3.产品的“1，+∞”
产品发布后，后续工作得到优化和更新。用户研究可以在这个阶段进行，那么如何处理研究数据以反映更多问题？这是一种在用户故事地图中将其称为旅程地图（也称为体验地图）的方法，但在此基础上，进行了一些调整。情感版本的使用被叠加在其上。
旅行地图
1.目的
用户调查数据处理以确定产品优化点和优化需求。
2.适用场景
用户研究数据处理。
3.所需资源
目标用户的评估数据
3-7名参与者（包括产品设计师，产品决策者，用户体验设计师）
贴纸/不同颜色的卡
4.操作方法
用户操作路径，并且每个联系人分步写在便利贴上并且布置在x轴上。
评估数据写在便利贴上，并根据经验水平排列在y轴上。
对每个联系人的评估数据进行整合和评分。
根据分数调整联系人卡片的y坐标。
以上是用户故事地图的七种用法，它们对应于产品“0,0.5”，“0.5,1”，“1，+和infin;”的三个主要阶段。我希望能帮助大家。
