用一句话的敏捷用户故事让你的观众成为英雄

从前，有一个行业濒临崩溃。

其成员始终如一地完成老板要求的工作，但有一半时间它与客户的需求脱节，以至于毫无用处。返工猖獗。项目失去了控制，可怕的延迟和荒谬的超出预算。在新千年到来之际，采取严厉措施的时候到了。

行业是软件开发。其中一个激烈的措施是通过使用一个被称为用户故事的强大工具来彻底改变开发者和软件使用者之间的关系。

从那以后，用户故事被证明在软件世界之外同样有用。

当用户故事在内容营销环境中正确配置和应用时，它们将观众需求置于内容生产的中心，支持高效的团队合作，并鼓励部门间的交流。

什么是用户故事？

不要被“故事”这个词误导了。用户故事不是任何传统意义上的故事。其实应该只是一句话。这是一个工具，可以帮助团队根据对受众及其需求的共同认识来调整他们的工作。

术语“用户故事”是由极限编程的早期先驱Kent Beck创造的，他将它们描述为“关于软件做什么的故事”，这些故事“在听众的头脑中产生能量、兴趣和愿景。”

如果肯特是一个内容营销者，他可能会把用户故事描述为关于一个组织能让人们做什么的故事，在你的头脑中产生能量、兴趣和愿景的故事。

Kent认为，与其将软件建立在大量的规范文档上，开发人员应该听人们谈论他们希望软件做的很酷的事情，比如当他们输入邮政编码时自动填写城市和州。

自早期以来，软件开发的用户故事已经发展成一种标准格式:

作为一个[用户角色]，我想要[某个特性]，这样我就可以[实现这个结果]。

用户故事也可以为内容营销者修改。没有一个正确的结构。它可能看起来像这样:

作为一个[角色]，我喜欢[这种内容]，这样我就可以[完成这件事]。

在我最近在智能内容会议上举办的敏捷营销研讨会上，我举了一个用户故事的例子:

不要让这个填空模板束缚了你。改编它，并以任何方式使用它，帮助你的团队产生内容想法，这些想法将引起共鸣并导致转化。重要的是你能从用户故事中获益——观众的关注和目的的清晰。不要罗列一堆SEO友好的事实，称之为内容营销，而是创建用户故事，引导你思考你的内容将如何帮助人们。

你不需要在敏捷团队中使用这种类型的故事。这些故事可以帮助任何营销团队确定要讲述的正确故事。

这是另一种方式来看待内容营销用户故事中包含的内容——使用四个核心元素:

1. 一个简短的标题
2. 内容面向谁(受众或角色)
3. 观众在寻找什么(通常是内容类型或频道)
4. 为什么受众关心消费这些内容(他们希望解决什么问题)

根据需要创建尽可能多的用户故事来覆盖您的受众范围， 内容类型、渠道、人们希望解决的问题。

用户故事中应该有哪些细节来跟踪内容创作？

您可能想更进一步，向您的用户故事中添加细节，使您能够在制作内容时跟踪进度。

让我们看一个例子。想象一下，你在一家公司工作，该公司开发了一款应用程序，帮助人们更有效地度过充满压力的早晨。您的内容团队希望创建一系列博客文章，以吸引人们下载该应用程序。这些帖子的目的是提供如何拥有一个更好的早晨的见解。

在这种情况下，您可以为每篇博客文章创建一个用户故事。如果您在索引卡上写下每个用户故事，它可能看起来像这样:

四个核心要素——标题、谁、什么和为什么——帮助团队关注受众。添加的细节——重要性、地位、大致尺寸、创建日期和作者——将卡片转换成 制作每篇博客文章时跟踪进度的工具。

下面是添加的细节(元数据)如何将用户故事卡转化为跟踪内容本身进度的工具。

• 重要性: 黄色/橙色/红色连续体表示这个职位相对于你可能正在做的其他工作的重要性。你可以给你的连续体贴上“高/中/低”的标签，或者使用其他术语。目标是快速传达该帖子在团队优先列表中的位置。

• 状态: 用一个小便笺，标明文章的制作状态:集思广益，创作，编辑，出版，等等。您可以随时轻松更新状态。

• 粗略尺寸: 这张卡用的是简单的小/中/大秤。您还可以提供创建这段内容所需的估计时间或天数。

• 创建日期: 记录您创建这个用户故事的日期。这些信息可以帮助你避免白费力气。例如，如果有人有了这个想法已经六个月了，你可能想在你创建内容之前确保它仍然是相关的。

• 作者: 您可以将作者定义为编写用户故事的人或最终产生所描述内容的人。您可能希望包含这两个名称。

虽然用户故事不需要这样的元数据，但我建议包含它。捕捉任何细节，这将有助于您绘制和监控整个团队的内容流。

在卡片的背面，如下所示，你可能想记下相关故事的想法。您可以列出要交叉链接或交叉推广的内容，或者您希望在创建阶段避免重复的主题。记下你想到的任何相关的片段，以便有人日后参考。

用户故事从哪里来？

你当然可以坐在办公桌前想出用户故事，就像你想出一个普通的博客创意一样。但是如果你能让内容团队参与编写用户故事，你会惊奇地发现你的内容变得更有凝聚力了。

例如，如果你假设的团队在开会，有人说，“我们应该做一个关于早餐想法的博客系列”，每个人都可能点头同意。

他们在点头，但是——没有书面声明——这就是实际情况:

图片来源:杰夫·巴顿的

作家、平面设计师和编辑都对这个系列将如何发展有不同的愿景，但他们没有花时间让这些愿景同步或讨论它们如何与观众相关。

你可以想象一下，当作者在一个正方形上工作，而图形人员贡献了一个圆时，会发生什么。我们都曾经是这样的编辑，当她期望得到一个三角形时，她的办公桌上却放着一个正方形的初稿。

通过召集整个团队，将一般概念推进到书面的用户故事中，您可以避免这种类型的不一致。

图片来源:杰夫·巴顿的

图片来源:杰夫·巴顿的

内容团队花费更少的精力，并且观众基于对如何满足他们的需求的多方面理解而获得有凝聚力的内容。

结论

虽然用户故事是作为敏捷软件开发运动的一部分开发的，但是你不必进行一个完整的敏捷转换来有效地使用它们。传统的(非敏捷的)营销团队可以将用户故事整合到他们的过程中，并获得几乎所有的好处。即使看不到看板或Scrum大师，更强的观众焦点和更好的内部一致性仍然是可以实现的，这要感谢敏捷用户故事。

你团队的用户故事是什么样的？