体验画布是由Atlassian这家公司实践一种团队协作工具，了解到体验画布其实是一件非常偶然的事情，但是在网上关于体验画布的资料非常少，所以我仔细研究了一阵，也在团队中做了一些小范围的实践，借此将这块的经验做一个记录，希望后续能够更好地应用，提升团队协作效率。

什么是体验画布？

体验画布是什么？下面就是一张体验画布的示意图：

体验画布包含以下几个部分：

（1）假设（Hypothesis）

团队认为这个项目可以给客户带来的改变，一般会表述为：“我们觉得……会带来以下这些效果……”

（2）问题（Problem）

是什么出发了假设？清晰地列出挑战问题和根本原因

（3）用户角色（Customer Personas）

谁有这个问题？他们的动机是什么？他们想要完成什么？

（4）利益相关者（Stakeholders）

哪些人支持这项工作？哪些人有可能妨碍这个项目？哪些人也有一些要求？

（5）团队（Team）

建立这种成功经验需要什么经验和技能？

（6）价值（Value）

什么是可能的用户利益和业务利益：

• 预期客户收益；
• 商业上的利益；
• 技术上的利益。

只列出可度量的内容，并根据顾客感知价值把他们视为一个集合。

（7）创意（Ideas）

什么可以解决客户角色的问题并满足利益相关者的要求？

（8）最低可行经验（Minimum Viable Experience）

你的创意的最小、最简单、最速成版本，它能够可靠地证明该假设。

（9）衡量标准（Metrics）

定义与该经验的期望值直接相关的成功指标，用于证明或反驳假设。指标常常被忽略或不被执行，早期确定衡量它们的时间、方式和人员。

另外，你希望具有指标不仅是为了最终价值，还是为了能提供早期成功或警告指标的里程碑。

（10）端到端演示（End to end demo）

从客户的视角讲述一个完整的故事，重点描述解决的问题、使用的解决方案以及获得的价值。把主要情节用角色扮演、略图或线稿的形式列出来，之后可以将这些改编成高保真的模拟旅程。

一个从开始到结束的完整用户体验地图，会给整个团队一个可以期待的最终目标。

以上就是Atlassian对体验画布10大板块的定义，图片中还给出了以航空公司低价航空旅行产品的示例。

从体验画布这个名称及各个板块的设置上，我们其实会比较容易联想到另外两个工具——精益画布（lean canvas）和体验地图（Experience Map）。

精益画布来自《精益创业实战》这本书，作者是美国的Ash Maurya。在原书中，作者将精益画布定义为一个可以随身携带的商业模式单页图表，主要用于团队思考和讨论可能的商业模式，确定从哪里开始第一步，还可以用来记录持续的学习过程。

精益画布的图示如下：

体验地图也是我们做产品设计时常用到的工具，下图是体验地图的图示：

那么，体验画布跟精益画布、体验地图有什么区别和联系呢？

从我的理解上来说，精益画布、体验画布、体验地图之间是一个从粗到细，从宏观到微观的递进关系，它们分别服务于不同的产品的不同环节：

• 精益画布主要用于确定产品的商业模式，基于精益画布，团队可以非常直观地看到产品的全貌，包括产品解决的问题、服务的客户、盈利的方式、竞争力所在等等；
• 体验画布则主要用于帮助产品、设计、研发团队间协作一个具体的问题，弄清楚某个特定问题应该以何种方式验证和解决，让团队以最快的方式了解问题的全貌并达成一致；
• 体验地图则服务于产品理念的最终落地，将产品与用户之间互动的方式放到显微镜下，探究在各个不同的场景下，产品是如何帮助用户最终解决问题，并创造良好的体验。

由此，我们可以很明确体验画布的价值：

1. 体验画布以一种直观且简洁的方式，帮助团队理解产品规划人员提出的假设、问题、场景，以及对应解决方案的核心思路；
2. 体验地图建立了清晰的用户场景，在后续的产品设计中，设计人员能够据此作出对用户诉求和预期更合理的推测；
3. 体验地图能够提前定义好针对问题解决的MVP和衡量标准，使得研发工作以更精益的方式推进，避免资源浪费。

体验画布怎么来做？

就和精益画布、体验地图一样，要实践好体验画布，在填充各个模块的内容之前，我们也需要提前做大量的实际调研、用户访谈等工作，确保我们获取的素材是真实的、符合产品与用户互动的实际情况的。我们提出的假设是可能成立的，用户的问题是确实存在的。

根据Atlassian官方的指导，我们在做体验画布时可以分为以下步骤：

• 在准备阶段，我们可以先提出一个粗略的假设，而不一定要将所有模块都填满，并将体验画布呈现在白板上，以便于团队进行头脑风暴和及时记录。
• 第一步，与团队一起建立讨论的规则与基调，引导大家重点关注用户、问题及更好的解决方案。需要注意的是：所有人都应当参与到讨论中，而不能以旁观者的心态参与，且大家要避免在这个阶段陷入到实现细节中。
• 第二步，开始填充画布。在进行这一步时最好能有一个主持人来控场，管理好大家花费在各个模块上的讨论时间及会议的推进。我们应当尽量按照顺序标识来推进，并不时停下来询问团队成员的意见，看哪些地方可以优化，或有所遗漏。
• 第三步，在完成体验画布后，需要为MVE和假设的验证定制文档，并指定执行者，并确保项目推进的每一步都附带有截止日期，避免只是做一个看起来不错构想最终不能落地执行。

在我们的团队是如何来实践体验画布的呢？

目前我们的团队基本上是按照Atlassian官方指导的流程来执行，在执行的过程中，我们也发现官方的指导及相关说明中有一些不够清晰的部分，或是我们认为可以优化的部分，我们在实践时做出了更细化的规定或进行调整，主要涉及的点包括：

• 用户角色的细化：因为我们主要做的是B端的产品，在我们实际的产品使用场景和设计的过程中，我们的用户天然存在多种角色。所以我们会要求产品人员将用户角色尽可能的细化，为其建立详细的角色名片，需要列举的信息包括但不限于名字（模拟）、行业、职位（模拟）、技术背景、日常工作的方式、与产品交互的能力等，有时还会附上真实客户的非常具体的反馈内容。这样的角色我们会尽量多列一些，以避免遗漏重要的用户。
• 利益相关者的细化：从我们的理解上来说，利益相关者是指的非产品用户的第三方，可能不一定指具体某些人，例如：某些需求涉及的一些法规限制，我们也会视为利益相关者。在描述利益相关者时，我们不仅会像示例中一样列出利益相关者是谁，而且会更细化到他可能如何促进或者妨碍我们目标的达成。
• 团队的细化：和利益相关者一样，我们不仅会列出有哪些相关的团队成员，并且会尽量写清楚要实现目标，团队成员应当具备哪些能力、了解哪方面的情况、完成哪些事情、以及做哪些预研等等。
• 在填充价值模块时，我会直接要求团队成员提供一句话的文案，讲清楚解决当前问题的价值，来打动用户。
• 端到端演示我们会先定义清楚多个用户角色的不同使用场景，然后基于这些细化的角色场景开始创建体验地图。当然，因为这些体验地图是基于未完成的服务流程，且对于我们的产品来说，涉及的场景和角色非常多，我们通常不会直接在体验画布的会议中完成，而只是列出场景与角色，待会后完善再组织单独的讨论。这期间也会根据实际需要进行用户调研，以便更准确地理解用户的预期，并在做体验地图时，对整个流程中相关的交互体验做出更合理的推测。

以上就是我们团队对于体验画布实践的总结，在此进行简单的记录与分享。

未来我们也将基于团队实践的实际情况，结合团队的一些创意，不断进行完善和改进，以不断提升团队协作的效率。

#专栏作家#

不知，微信公众号：不知，人人都是产品经理专栏作家。B端产品人，擅长产品规划、产品设计等

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议