发布时间：2020-12-10 分类： 电商动态
作为一种常用工具，用户故事地图已经进入了每个人的视野。但是你可以用经验图解决什么样的问题？你如何使用它？许多学生可能不理解它。这种分享主要是为了总结我们在各种渠道中学到的关于用户体验地图的各种陈述，并结合我们在工作中的实际用途，为一些有兴趣了解该方法的学生提供。见解和意见。
本文内容来自蚂蚁金融体验技术部的“经世会”。
关键词：中后台，蚂蚁设计，故事地图，需求分析。
本文将分为5个部分：
怎么做
提高效率
值
总结
相关材料
大多数中端和后端产品都使用产品化工具来提高用户的性能。随着用户应用程序场景开始扩展到在线和离线的各个角落，设计人员也开始考虑如何从时间和空间维度关注完整的用户体验。
用户发现，您提供的产品的真实价值，如封面背景图片，通常会经历一段旅程，而且不能是平面。通过我们的专业知识，见解和见解，我们可以确定用户在旅程中的位置以及如何填充它们以使用户变得更好。帮助用户更轻松地获得产品价值，帮助项目团队取得成功。
I.怎么做？
虽然用户故事地图是一种熟悉的工具，但要知道何时联系并不容易。有许多要点需要注意，并且可以找到许多模型，这会导致复杂的方向，这可能会导致适得其反的用户故事地图，或者什么都没有，所以我们应该怎么做？它。
在支持项目的过程中，我们将首先选择使用“故事写作研讨会”的形式来整理产品的用户故事地图。它通常是项目团队成员共同创造的一种形式。参与者包括：技术开发，产品经理，项目经理，设计师，用户和产品负责人。
重要的过程分为四个步骤：产品定义——梳理骨干故事——分裂故事——沟通确认。
下面我简要介绍一下这四个步骤需要做些什么。
第1步：产品定义
一般来说，在故事写作研讨会的准备阶段，PD首先引出输出，有几个要点：
产品的目标用户
哪些问题已经解决
用户目标
产品目标
将这些内容记录在黑板上，与您讨论达成共识，最后确定产品定义。简单来说，你需要明确“为什么我们这样做？”和“用户为什么要使用它？”明确的业务需求和用户申诉不仅在讨论过程中，而且在讨论过程中为后续设计提供指导。它还避免了设计细节的纠缠。基于商业诉求和用户诉求，实际上是为了避免初衷，以澄清设计的初衷。因此，在进行交互式设计之前，您必须问自己这两个问题：“这会给我们带来什么价值？这可以为用户带来什么价值？”这一步可以使项目团队中的每个人和用户清楚地了解整个产品范围。
第2步：对骨干故事进行排序
为了方便每个人的理解，我在这里举一个例子来说明每个人的生活。故事的整个范围：起点是起床——最终目的是到达公司。闭上眼睛，想想今天早上起床的过程。把这个故事分成几个阶段，起床—— wash—— dress—— out out——去工作——到达公司。
在实际项目的过程中，每个人都可以在这一步中编写一个不同粒度的故事，设计师需要控制故事的大小。这个故事可以进一步梳理成具有更小粒度的故事。例如，当你起床时，你可以把它拆开：警报响了 - ——挣扎——关掉闹钟——起床了。其余的故事卡可以继续拆分和排序。
通过这种方式，我们的骨干故事有两层：第一层故事和第二层故事。故事从左到右作为叙事流。
这里应该注意的是，在实际业务中，故事流程不能流畅，情况变得复杂。我们可以将故事卡与流程图的图例线连接起来。
总而言之，我们在这一步做了什么。首先，我们将尽可能在第一步中尽量完成故事，以确定产品的整体范围，例如我们的例子，起床——洗—— dress—— going——上班— —到达公司。这样，我们项目团队中的每个人都可以对整个产品产生全局印象。其次，我们需要注意完整的故事，但它必须是广度优先，而不是深度，宽度为1千米，深度为1厘米。例如，在刷牙的故事中，找到牙刷和挤牙膏的故事在这个阶段不需要注意。不要太早沉浸在细节中。在此步骤中，让每个人都执行产品的状态并查看没有树的森林。
第3步：拆分故事
在这一步中，我们需要停下我们刚刚整理过的每个次要故事，以分割次要故事以获取更多细节。如果第二个故事是海平面，那么第二个故事高于海平面故事，那么现在我们需要关注海平面以下的更多隐形故事。项目团队将围绕这个故事撰写大量细节。我们可以按照以下方面对细节进行分类：故事细节，想法，痛点，机会，情感。情绪可以通过固定的问题获得，也可以通过用户思想和用户痛点进行主观判断。
在这个过程中，让每个人在一定时间内按照自己的想法写作，每一个都写在一张卡片上，以免互相干扰，然后每个人都会发出自己的卡片内容，让每个人都知道并且附在墙上。
当项目团队写出一个想法时，它相当于头脑风暴的过程。在这个时候，一些问题可以用来刺激每个人的大脑爆炸更多的内容，例如：
用户在此步骤中做了什么？
用户还有其他选择吗？
用户可以做些什么来改善它？
如何处理这个问题？
其他用户应该怎么做？
回到我们的例子，当我们洗澡时我们有一个正常的过程，但是当没有热水时这个过程会改变。同样，在实际业务中，这种情况会更普遍地发生，所以在这一步中我们将尽可能地关注所有场景的故事。
在这一步之后，我们已经获得了足够的细节，整个项目团队将能够看到森林和树木的状态。
第4步：通信确认
在这里，我们的故事变得非常充实甚至臃肿，因此沟通确认变得非常重要。我们需要在这一步中花费相对较长的时间。每个人都会对内容进行基准测试，充分讨论，并消除公认的无用的内容。同时，可以优先处理要完成的故事的细节。
通过类比，当所有故事都已整理出来时，完成了这样一个完整的用户故事地图。
结论。首先，我们需要对所有人写的卡进行基准测试，以消除无效故事。其次，由于我们的一般项目时间不够，开发资源紧张，不可能一次吃一个胖子，所以就要优先考虑的问题达成共识尤为重要。最后，并非所有故事卡都需要同时完善。在实际业务中，某些模块故事无法从一开始就进行整理，因此您可以先写一个占位符，然后在合适的时间进行拆分。 。
通过这种清晰一致的故事地图，我们让项目团队获得足够的信息，使项目有一个明确的开发过程。
回顾过去，我们通过这四个步骤整理了产品的故事地图。中间仍有许多细节，我们将在未来进行总结和分享。这次我们不会描述太多。
当真正的业务下降时，会发现因为一般项目时间非常紧张，这样一个完整的过程会相对繁重和耗时，所以我们一直在思考如何改进。
2.提高效率
我们目前以三种方式工作，分为事前——在事件——然后。
1.事先
我们创建了Excel故事地图准备模板，可以在故事编写研讨会开始前一两天发送给参与者，这样每个人都可以以相对结构化的方式进行整体梳理和思考。增加研讨会产出的数量和质量。
2.事件
如果它是需要优化的产品，我们可以打印设计草案演示或在线产品截图，这可以增强您的替代感并提高输出质量。
3.之后
我们创建了Axure的体验地图整理模板，以快速组织电子版并有效地传播我们的讨论内容。
最后，我想谈谈这个方法的价值，你可以自己判断一下哪种商业方法适合这种方法。
三。值
1.共识
我们的设计师在过去有两种方式同意：一种是文档，当您浏览它时，那些格式化的语言将成为世界上最好的摇篮曲。阅读仍然如此，写作者会怎样？编写文档的PD大脑肯定会回答一个问题：这件事是否真的写了一个人？
有文件看看还是不错的，有更多情况下PD直接拉你跟你说话，手绘几个线框，即使切换需要，这两种方式都可以用于下一个界面设计，但你是确定你收到了真正的需求吗？这里的共识是点对点或单点到多点，信息传输也会导致信息内容的丢失，甚至是错误的信息。
这里提到的共识有什么不同？
用户故事地图过程中的多角色和多视图，尤其是中端和后端产品，不仅仅是对用户需求的简单估计。
项目的不同参与者有不同的需求，PM希望跟踪进度，开发人员想要实现，产品具有理想的功能，产品老板有更高的视角，用户想要一个可用的系统。在这些相互矛盾的观点中，很难做出每个人都支持，快乐并继续保持平衡的决定。整个项目团队就像一个四轮驱动。角色的力量相当于车轮转得太快。这是产品的损失，导致汽车的方向发生变化。通过一起构建产品全景图的方式，让项目团队所有者，包括站在800米的用户，忽略了产品。这种在同一空间内的多点到多点共识自然而然地完成了。这种共识应该是空前的。的。
再举一个例子，在很多情况下，我们通过文档进行沟通，并认为我们理解它。我想我想的就是你的想法。
但如果我们说，写，并绘制我们自己的想法，我们可能会发现你认为这不是我的想法。
故事地图的方法是通过讨论就每个人的想法达成一致。
我认为最后的理想状态就是你的想法。
2.移情
当我们实际支持后端产品时，设计存在很大问题。这是不合理的。面对业务中的许多适当条款，它将非常薄弱。即使是来自同一项目组中不同模块的人也不会理解对方的专有名词。 。
故事地图如何解决这个问题？
这是一个例子。如图所示，我们所有人都可以快速了解用户想要的内容和原因。通过这种简单明了的场景缩减方法，每个人都更容易理解。每个故事我们都站在用户的频道上并与人交谈。
3.参与式设计
与参与式设计相反的是经验设计。新产品的设计是在各种情况下，设计师可以观察未来的用户和产品的各种效果。经验设计高度依赖于早期用户研究，包括用户访谈和用户观察，但用户不会成为产品设计的真正参与者。后面的阶段基本上是基于设计师的经验，用户很少。
用户故事地图是吸引用户设计所需产品的便捷方式。我们所有的原型设计阶段都来自用户故事地图，因为故事地图是用户的完全参与，所以我们在整个设计过程中都有用户。
用户故事易于阅读和理解。我们可以在谈论故事的同时绘制页面框架，这样我们就可以激发用户的热情，成为产品设计的参与者。同时，随着用户逐渐掌握如何口头表达故事以描绘他们的需求，项目团队成员与用户之间的关系变得更加亲密和活跃，这种良性循环使所有人受益。
4.记录
我们过去记录的方式只有几种：文档记录，备注或聊天记录。大多数此方法是单点到单点或多点，并且记录的内容是有限的。
用户故事地图的记录方式有何不同？
为方便大家，这是另一个例子。每个人都看到下面的照片。这张照片传达给大家的信息是什么？大多数人可能会得到非常高兴的信息，海滩的风景如此美丽，等等。但这张照片向照片中的人传达了更多信息。例如，当我看到这张照片时，我记得我们不得不开车一小时来到海滩。我脱掉鞋子走了进来。老板没有过来。休息之后，我们找到了一位当地导游来拍摄我们的照片以及在此期间发生的许多其他细节。
对于照片中的人来说，这张照片不仅仅是一张照片。出于同样的原因，故事地图中的每张卡片不仅仅是卡片上的内容。它记录了每个人在卡片周围讨论的时间段的所有信息。记录的信息量甚至更大。
当我们回顾这些卡片时，就像照片一样，它会很快唤起那段时间的回忆。
总结
我们梳理了用户故事地图的四个值，即共识，同理心，参与式设计和记录。
加上我们的故事地图四个步骤：产品定义— —梳理骨干故事— —分裂故事— —沟通确认
我想用这种方法来保持范围层的稳定性，这样我们就可以更好地进行原型设计。
我想强调的是，在复杂的产品中，不要试图在项目开始时做出一套保罗的决定。相反，故事总是伴随着产品生产周期，我们必须将决策分散到项目过程中。为此，我们希望确保获取信息的过程方法，这是一个良性的用户故事地图。
这里再次是一个比喻，一个捕鱼过程的良性用户故事图像。
首先，不同大小的网络用于捕捉不同大小的故事。我们第一次可以使用大型网状网捕捉故事池，以获取所有重要故事。通过大故事，产品的整体感觉形成，然后网眼略小的鱼网有一个中等大小的故事，暂时不考虑小的需求。最后一个是最小的需求。
其次，捕鱼表达了另一层意义。这个故事会像鱼儿一样长大，会有新出生的鱼，可能会死亡。有些需求在某个阶段并不重要，但它们会像鱼一样生长。随着产品阶段变得越来越重要，我们曾经认为的一些要求很重要，但随着产品阶段的变化，这些要求将逐渐变得更加重要。减少，有时甚至减少我们的使命，这些要求都是无效的。
最后，就像钓鱼一样，捕捉这个地区的所有鱼是不可能的。我们无法捕捉到所有需求。此外，钓鱼时可能会产生一些废物和碎屑。这不是一个故事。
从上面的比喻中可以看出，在项目的早期阶段不可能正确地捕捉和写出所有要求的所有故事。用户故事地图方法无法在单个阶段捕获所有用户故事。用户故事不是两个维度的产物。它应该是三维的。它需要添加时间维度，以便随着时间的推移和产品的不同阶段向产品添加新的用户故事。捕捉故事的渔网网格也将发生变化。
通过用户故事方法，我们不仅可以帮助我们了解哪些坑，如何填充它们，更重要的是，首先填充哪些坑以及填充哪些坑？如何填写更好？这种仁慈的判断要求我们总结使用经验。
