我是一名 UX 设计师，对来自敏捷开发项目的用户故事有一些经验，这些项目用于在表单上记录功能需求：
作为 [type of user] 我想 [goal] 这样 [reason]
在与一些同事讨论后，我们确定了对 [type of user] 应该是什么的三种不同解释。
谁是对的？如果我们所有人都是正确的，这难道不是一个常见的混淆来源吗？
用户故事是从产品最终用户的角度用语言编写的。
所以用户就是这样：他们是系统的用户。
示例包括：
尽可能简短地回答：这个人是“利益相关者”。
现在那个利益相关者是什么？它是对要执行的故事任务有（最大）好处的人。
还有更多。只要它从这个故事中受益就可以完成。
（旁注：我从不喜欢这种写故事的方式。太多样板，但我们的敏捷教练也敦促我们以这种格式写故事）
1和2在使用中很常见。我与许多团队合作过，他们为他们的产品创建了许多角色，比如老太太简、用智能手机做所有事情的时髦达芙妮和让所有事情都由他的私人助理安排的行政人员约翰。
这些角色对一个软件有非常不同的要求，即使他们可能在系统中执行相同的功能或从相同角色的角度进行操作。
一个人的价值陈述甚至可能与另一个人的价值陈述发生冲突。Jane 可能想要大字体并且只需要与她当前操作相关的信息，John（的助手）可能想要更广阔的视野，并且不介意可视化和小字体，如果这意味着她可以在相同的内容上塞入更多信息屏幕。
因此，将角色视为进一步缩小特定角色范围的一种方式，并通过远离严格范围的角色使您的用户故事更加“人性化”。请记住，用户故事旨在真正讲述用户的故事，以及该功能将帮助他/她完成什么以及会给这些人带来什么。“管理员”、“客户”、“黄金客户”这些角色往往没有情感，而且往往不会引发正确的讨论。
我记得在一些团队讨论中，人们在讨论中评论道：“虽然约翰会喜欢这一点，但我们会在 3 步前失去简”。这会导致提议的功能发生变化。
至于选项 3，我看到不少团队这样做，对于某些角色来说，这可能是有意义的……作为一名运营工程师，我需要全面的日志记录，以便快速分析生产事件。可以是一个例子。但是团队将其作为需求分析师，我需要故事 27 的需求，这太过分了。这些项目通常属于非功能性需求类别，不提供真正的最终用户功能。对于这些类型的产品待办事项，您可能需要检查用户故事是否是描述它们的最佳格式。
用户故事最好用于描述产品积压的需求，以便最终用户或利益相关者如何从他的角度看待和使用产品。而 PO 应该是能够评论用户故事正确性的最佳人选。如果 PO 正在从团队中获取用户故事开发的意见，那么他们应该更多地可视化产品的使用情况，而不是简单地对用户类型进行分类。用户类型虽然很重要，但需要强调使用，例如，1.访问医疗网站的医生知道药品的内容和制造商，那么需要给他什么样的访问权限另一方面 2. 如果药剂师正在寻找特定药物、可用数量、发货时间，则需要提供相应的访问权限和工作流程。
从上面给出的用法中，我找到了第一个合适的，即角色及其从他的角度来看的系统用法。对于系统的每次使用，都可以创建用户故事，并相应地开发工作流程。
TL;DR 所有都是有用的，没有一个是错误的，没有一个是唯一的方法。阅读我为跟进此答案而写的博客文章的更多信息。
您描述的 3 个细微差别均有效并提供有用的信息。考虑尝试每种方法，看看哪种方法最适合您。我的建议是避免限制“用户”的含义，因为它可能会使您无法获得有用的洞察力和对您正在构建的内容的更深层次的意义
用户故事的目标（最初，肯特贝克希望它们被称为“故事”）不是写更好的用户故事；而是写出更好的用户故事。它是超越要求，进入真正的理解。为此，您需要了解该软件是为谁服务的，它正在为他们解决什么问题，以及为什么该问题值得解决。
将此视为一个实验，以了解您是否拥有正确的用户类型。回答这个问题，“我知道我正在建造的这个东西将如何改变那些将要使用它的人的世界吗？” 如果没有，你可能还不明白它是给谁的。
第一个和第二个是对的，但它们没有区别，而是互补的。
用户类型可以是：
在简历中，您可以为一种类型的用户使用任何上下文，因此您可以使用其中一个或混合使用。
希望我的英语可以理解 =)。