用户需求陈述：设计思维中的“定义”阶段
综述：用户需求陈述，也称之为问题陈述或观点（POV）陈述，是一个强大的基础工具，用来定义和调整你正在解决的问题。
在设计思维以及任何产品开发过程中，在花费时间和资源产生可能的解决方案之前定义你想要解决的问题是十分重要的。针对错误问题生成的最佳解决方案终将会失败。这种方法可以最大限度地利用资源，并降低原型设计，测试和实施阶段产生摩擦和分歧的可能性。
用户需求陈述，通常也称为问题陈述或观点陈述，是设计思维第二个阶段定义阶段的主要工具；在进入下一步创意动脑前调整不同的观点。你选择使用哪个术语（用户需求，问题或者观点）并不重要，重要的是你可以在整个系统中始终保持一致。
定义：用户需求陈述是一个可操作的问题陈述，用于汇总特定用户是谁，用户需要什么以及为什么这个需求对用户非常重要。它定义了在你继续生成潜在解决方案之前要解决的问题，以便 1）浓缩你对问题的看法 2）提供在整个设计思维过程中用到的衡量成功的指标。
更为重要的是，用户需求陈述的目的是我们想从我们的设计中捕捉到什么，而不是如何捕捉。它们有助于推进我们从特定的功能（如按钮或其它UI实现）到深入了解用户需要解决的问题的解决方案。简单地说就是，用户需求陈述鼓励我们将用户的需求视为动词（即目标和结束状态），而不是描述解决方案的名词。例如，用户不再需要一个下拉菜单（名词）；他们需要看到他们可以做出的选择并选择其中一个（动词）。他们不需要一个仪表板（名词），他们需要在一个地方消化不同的信息（动词）。名词是用户需求的可能解决方案，但不是唯一解决方案。如果我们专注于这些名词，我们就要冒险以不理想的设计结束。整个创意动脑的目的是探索想法，因此不要过早的选择解决方案来锁定自己。
格式：3部分
传统的需求陈述有三个组成部分：1）用户，2）需求，3）目标。这三个部分遵循以下模式：【用户】需要【需求】来完成【目标】。
例如，【Alieda，一个任务繁多，精通技术的母亲】需要【快速而自信地比较选项而不离开她的舒适区】，以便【花更多时间做真正重要的事情】。
用户应该对应你已经研究过的特定角色或真正的终端用户群体。包含一个简短的标语对于提醒每个人用户是谁非常有用，特别是如果需求陈述被一个大型团队使用或者被已经从研究中剔除的利益相关者使用时。
- Alieda，一个任务繁多，精通技术的母亲
- Carol Ann，一位热衷冒险的研究员
- Sam, 这个城市中的Youtube用户
需求应该是真实的，应该属于用户而非团队，也不应该被称为解决方案。远离功能，界面组件和特定技术。例如，可能的目标是：
- 快速，自信地比较选项而不离开她的舒适区
- 与他人会面和交往，同时保持家庭平衡
- 在做出重要决定时从其他人那里获得验证
切记：用户并不总是知道他们的需求是什么，即使他们说知道。亨利·福特有句名言：“如果问顾客想要什么，他们会说要一匹跑得更快的马。” 了解用户的真实需求是你的任务。
洞察力或目标是满足这种需求的结果。它应该植根于同理心。超越显而易见的东西：这个解决方案将允许用户完成什么？例如，考虑用户的希望，恐惧和动机：
- 花更多的时间做真正重要的事情
- 有信心结交新朋友吃饭
- 追求一个永远退居二线的终身梦想
优点
制作用户需求陈述和完成陈述本身的认知和协作过程对你的团队和组织具有重要的好处：
- 捕获用户和需求
需求陈述将你对用户及其需求的了解提炼为单个句子。在寻找解决方案之前，它特别有助于缩小研究和见解（调查结果，用户访谈脚本，同理心地图），从而提高明晰度和时间分配。
- 团队沿着简洁的目标保持一致
用户需求陈述是一种简洁，表达清晰的方式，可以在多个团队成员和利益相关者之间传达用户及其需求。一旦创建，它应该充当指导力的角色，在整个项目中调整你和你的团队以寻求解决方案。
- 确定成功的基准和衡量标准
用户需求陈述，如果设计得当，可以在构思，原型设计和测试开始之前在提供成功指标上增添益处。使用洞察力或目标，并问自己：我们如何知道我们是否实现了这一目标？然后，在创建需求陈述时，建立相应的成功指标。这种方法可以减少过程中的摩擦，为你的团队或组织设定一个明确的标准。
过程
1.设置范围
用户需求陈述可以应用于不同的范围。你可能会在一个项目中拥有多个需求陈述：一个全面的，总括陈述和从属需求陈述，用于表达该用户类型的较小目标。你应根据当前项目需求确定需求陈述的范围。
当你的目标是以下几点时，从创建一个“总括”或“母体式”（广阔范围）需求陈述开始：
- 建立长期愿景或路线图的一致性
- 在产品概念开始时定义问题陈述
一个“母体式”需求陈述可能会有一个广泛的目标，它将超出项目的每个组成部分。例如，上面的需求陈述可以被视为母体目标：
【Alieda，一个任务繁多，精通技术的母亲】需要【快速而自信地比较选项而不离开她的舒适区】，以便【花更多时间做真正重要的事情】。
相反，如果你的目标是如下几点，那么以“子”（小范围）需求陈述开始较为有益：
- 通过需求陈述提高你的舒适度和流畅度
- 为个人从业者或UX团队创建个人成功基准
- 使团队在更大的产品或服务中满足用户需求
- 设定为期一周的冲刺目标
“子”需求陈述将具有特定需求以及在1-2个版本中可以获得满足的目标：
【Alieda，一个任务繁多，精通技术的母亲】需要【安排安装预约】以便【提前协调她家人的日程安排并防止额外的负担】。
2.进行（或收集现有的）定性研究
收集你将使用的研究，以加深你对用户及其需求的理解。诸如用户访谈，实地研究，日记研究或定性调查等定性输入可以深入了解你的用户。另请查看你的团队已经制作的地图，例如同理心地图，旅程地图或服务蓝图。
3.生成，组合，匹配
使用你的研究，在你的需求陈述中生成3个变量的候选者：具有标语，需求和洞察力的用户。不要担心从一开始就创造完美的陈述; 相反，单独考虑每个变量，然后开始组合和匹配。组合不同的配对，直到你有一个能代表用户真实需求的陈述出现。
初次实践者经常担心在他们的需求陈述中包括任何非研究发现的文字内容。但是，重要的是要记住，我们的用户通常不会直接说出，甚至不知道他们具体需要什么或为什么需要。相反，我们作为用户体验专业人员的工作就是利用研究并结合我们的专业知识来获得洞察力。正如Airbnb的Rebecca Sinclair提醒我们“你是设计师。你的工作是成为一个深刻的，善解人意的倾听者并设想出解决问题的方法。负责创造比客户想象中更好的东西。他们是灵感，但你是创造者。”你需要通过继续问自己为什么来实践这个目标：
- 用户关心什么？
- 为什么这对用户如此重要？
- 什么情绪会驱使用户的行为？
- 用户将获得什么？
4.审视你的陈述
一旦你有了工作陈述，就开始审视和迭代它。组合和匹配，改变语言使用并组合不同的内容输入。用这些问题挑战你自己：
- 你是否将用户的需求视为动词，而不是名词？
- 这份需求陈述是否会将你带入创意思考阶段?
- 这份陈述是否捕获到了解决此需求对你用户生活意义的细微差别？
5.添加衡量方式
在最后的需求陈述尘埃落定时，要确定如何衡量其成功与否。你如何知道你满足了用户的需求？常用的衡量方法如下：
- 消费者满意度
- 退货数量
- 更新政策或继续使用
- 重复购买或订阅
- 推荐该产品的可能性
用户需求陈述实例
必须在整个产品开发周期中使用用户需求陈述，以便团队获得全部收益。下面是创建和引用用户需求陈述的有效时机和原因的示例：
示例1：研究
何时：分析和分享用户访谈中的关键发现。
如何做：完成个人研究分析后，自行创建用户需求陈述。将此用户需求陈述与同行研究人员生成的陈述进行比较。组合并重新混合各种需求陈述，直到你有一个能代表你的访问洞察力的最佳用户需求陈述。
为什么：帮助你将研究中的必要内容浓缩为易于消化，共享和分发的单一可操作的陈述。
小提示：直接比较不同用户的需求陈述，以阐明用户群之间的差异。
示例2：项目启动
何时：在开始新发布周期或设计冲刺时确定目标。
如何做：在一个为期一小时的协作式研讨会中创建用户需求陈述。要求参与者产生需求，然后为特定用户提供洞察力。提示他们组合，匹配和重写，直到他们就一个陈述达成一致。
为什么：在一个清晰，明确的陈述中强制统一和优先排序多学科团队以保证团队成员可以团结起来; 同时也是为了减轻发布周期后期的异议或担忧。
小提示：让每个团队成员签署或初始化陈述，以表明他们已经一致认同发布目标。
示例3：回顾
何时：在实施后查看添加的功能或性能是否成功。
如何做：通过返回在项目开始时创建的用户需求陈述开始回顾。要求参与者根据陈述对他们对成功的看法进行排名。
为什么：对比已经实现的内容与最初目标的有效性。（用户需求陈述应该附有对成功的明确定义，例如，更高的点击率，更多的回头客等。）
小提示：将成功的自我评估与新功能或性能的分析及用户数据进行对比。确定关系和主题，并使用下一版本的洞察力。
用户需求陈述与开发任务，故事和史诗
一目了然，用户需求陈述似乎和其它产品开发中的常用结构相似。开发任务，用户故事和用户史诗通常都有相同的格式：“【用户】需要【做某事的方式】。”
为了更好地突出差异性，让我们将需求陈述与开发陈述进行比较：
需求陈述：
【Alieda，一个任务繁多，精通技术的母亲】需要【快速而自信地比较选项而不离开她的舒适区】，以便【花更多时间做真正重要的事情】。
开发陈述：
用户需要一个对比表格才能看到不同的价格。
需求陈述为我们提供了一个特定的用户，用户需要做的事情，以及对Alieda有这种需求的明确的、具有同理心的洞察力。开发陈述提供了一个通用用户和一个解决方案的对比表格，其中洞察力是用来解释解决方案将支持哪些内容的，而不是基于研究的。
两者都有自己的使用时机和场景。如果你处于设计思维过程的早期阶段，那么你应该迫使自己生成质量需求陈述，这些陈述可以作为整个创意思维和原型制作的支柱。一旦知道要解决的问题以后，就可以使用开发陈述作为实现机制。
如果你目前正在使用类似于用户需求陈述的史诗，故事或任务进行工作，请返回并挑战自己：你能否让用户更具体？如果你要将名词变成动词，那需要如何改变呢？更深刻的洞察力是什么？
总结
顾名思义，用户需求陈述清楚地阐明了我们将要解决的最终用户问题，以及为什么值得解决。它们是一种可以帮助我们停止将用户的需求视为名词，并开始将它们视为动词的工具。如果以协作和正确的方式完成，它们可以作为你希望作为团队或组织实现的事物的单一事实来源。
（编译完）
英文原文：地址
原文作者：Sarah Gibbons
原文译者：Twitter / Linkedin / 微博
以上译文仅代表原作者观点。如需转载请遵循CC版权协议正确标明出处。
image
