[toc]
原始需求是什么？需求来自哪里？设计师需要一一满足需求方提出的要求吗？应该如何准确地在纷繁的各项要求中找到关键的需求，且不遗漏任何细节呢？设计方法论中的原始需求分析，将帮助设计师从原始需求的素材中找到其中的逻辑，并合理选择，把握需求方向，做出正确的设计决策。
我们将分析原始需求的流程精炼为一个可适用于大部分场合的表格，它就是设计方法论中的原始需求工作表，这能够帮助我们更快速地掌握一个标准的工作流，并且简化每次分析前的准备工作。原始需求工作表中包含了以下要素：需求方、项目名称、时间要求、原始需求描述、目标用户、设计目的、使用情景、Keyword 注意项等，这些要素我们将会在之后的推送中详细介绍其方法及目的。
原始需求描述
为什么将其命名为“原始需求描述”呢？就是因为它是直接采用客户和干系人的语言，在尽量澄清真实意义的情况下，收集起来但不加分析的原始的需求信息，故称之为“原始需求描述”。我们将从一个实际的项目中抽取例子，以说明什么是原始需求描述，它能够带来怎样的帮助。
项目案例：芦苇Plus-创建官网引导 需求背景：芦苇Plus刚刚推出了一个企业官网编辑器功能，用户可以通过该编辑器自行编辑官网内容，同时将编辑好的官网同步更新到小程序端的芦苇Plus上，让企业介绍更加丰富。但实际用户的使用情况并不理想，因为是新功能，策划团队忽略了其用户学习成本的问题。为解决这个问题，设计者结合了多方收集来的需求，整理了一份原始需求描述文档。
无论是用户还是各方干系人（企业主、 测试团队、老板、 其他团队成员等）向设计者提出的这些要求以及在沟通过程中传递的各种信息，都是设计者设计产品的参考依据，我们在这里把有关“ 新建官网引导” 的要求综合整理，统称为 “原始需求描述” 。 而需求的提出者就是“ 需求方” 。比如在案例中，虽然原始需求描述来自于各方人员，但整份原始需求描述是由项目负责人通过整理后提出，故将需求方统一为“ 芦苇Plus项目负责人”。
原始需求描述一般都包含有几个重要的因素：需求背景、需求来源、需求原因、期望目标等，我们需要在原始需求描述中找到并确认这些要素。
继续来看“ 芦苇Plus-创建官网引导” 的例子，案例中有这样一条：“ 2. 用户在新建企业官网时，界面上有三个功能按钮“插入、保存、预览”，用户不能准确的知晓什么情况下可以使用以上三个按钮，即使用以上三个功能时需要满足的条件。建议未满足条件时（例如必填信息编辑不全）能有相关的提示。（测试团队） 。”
从这条原始需求描述中我们可以提取出以下信息：
需求来源：” 测试团队” 。在案例中我们可以看到，原始需求描述都有记录其来源，比如策划、测试团队、用户反馈等。需求来源有很多，但是不同的来源，重要程度完全不一样，比如老板的需求可能涉及到投资方，此时一定要慎重对待。
需求背景：” 用户在企业官网时…” 。原始需求描述的背景就是用户的使用情景，它能帮我们更好地理解原始需求描述，也能让我们了解到用户是在什么情况下遇到的问题。
需求原因：此处没有需求原因。如果是重要的原始需求描述，可能需要进一步发掘。
期望目标（预期方案/解决方法…）：“建议未满足条件时（例如必填信息编辑不全）能有相关的提示”。 如果提出这个需求的人，暂时没有想好解决办法，设计者可以引导需求方找出解决办法。
那么，一个完整的原始需求描述是如何诞生的呢?
当干系人产生需求时，需求的提出者便成为需求方。同样，设计者也可以去主动发掘需求。作为一名合格的设计者，无论在什么时候，都需要养成记录原始需求描述的习惯。原始需求描述的记录也讲究一定的方法，才能为我们提供更大的帮助。 通常可以从 5 个方面入手，找到需求：
- 产品相关人员：产品经理、产品设计者、UI 设计者、开发人员、运营/商务人员会站在各自工作岗位的角度对产品提出一些想法，这些想法可以提炼出很多有用的真实需求。有时候围绕特定的话题讨论或头脑风暴也可以用来获取需求。
用户调研访谈：通过用户研究的一些方法（问卷调查、用户访谈等）对目标用户进行分析，得出用户需求。
竞品分析结果：分析同类型产品，找出它们的缺点和优点，缺点如何避免，优点如何借鉴。
用户直接反馈：收集用户意见是很重要的需求来源。除了产品内部的反馈入口，还有微信、微博、知乎、贴吧、产品社区，客服和销售在跟用户接触的过程中也会收集到反馈信息，此外在 App store、豌豆荚市场等第三方分发平台中，各软件下的用户评论也是重要的反馈来源。
- 数据反馈信息：通过分析产品各方面的数据来提炼需求。这些数据包括：访客数据、浏览数据、在每个页面的浏览时长、点击率、转化率等等。
下面我们通过实际工作的比较来理解原始需求描述的“ 优越性” ：
通常的“ 设计要求” ：在许多互联网行业的产品设计工作中，通常是由上级或客户直接提出要求，由设计者进行记录和理解。设计者根据自己的理解开始对产品进行设计，然而在此过程中往往会出现设计偏差，有的是超出设计范围，有的甚至是遗漏了重要设计。此类问题的解决办法通常是进行反复的沟通、反复的设计，如此往复，最终得到满足产品需求的设计方案，沟通过程冗长而低效。
设计方法论中的“原始需求描述” ：设计方法论中的“ 原始需求描述” 通常是经过一系列需求素材采集工作后得到的未进行加工的需求，这些素材可能是调研结果，可能是会议录音，也可能是需求方直接提出的原话。
设计者拿到需求方的素材清单后，往往会从素材中一对一的提取未被加工的所有信息，并且制作好一份完整的、结构化的原始需求描述后交至需求提供方签字确认。在需求方确认后，原始需求描述将作为接下来产品设计工作的直接依据。
从以上两种方式的对比中可以看出，“原始需求描述”概念的提出很好地解决了设计工作中的沟通问题，大大的提升了产品设计工作效率，令设计者更专一的将工作重心放在产品设计上面，这恰好也就是“设计方法论” 中记录原始需求描述的主要目的。可以总结为以下四点：
- 标定产品期望：原始需求描述在设计方法论中作为指导性文档，标定了需求方的设计期望，要求设计者在设计产品时不断查看与研究，是开展设计工作的依据。
- 明确设计需求：通过素材清单明确原始需求，并从中提炼需求背景和设计目的、确定目标用户以及主要使用场景等，通过对需求关键信息的记录与确认，使需求方和执行方达成一致认知。
- 节约沟通成本：原始需求描述文档基本涵盖了所有产品设计所需考虑的信息，大大减少了设计者与需求提供方的沟通时间（尤其是需求提供方众多的情况下） ，这一作用在实际的产品设计工作中也得到了明显的验证。
- 形成有效边界：原始需求描述文档经过了设计者、需求方（审核方）的双方确认，在项目中不会轻易修改，形成了有效的设计边界，避免设计方向出现偏差，也能在之后的工作中验证设计是否达到了原始需求描述中规定的标准。
原始需求工作表中其余要素介绍
本节我们将具体介绍原始需求工作表中除了原始需求描述外的其他要素的方法及目的：需求方、项目名称、时间要求、原始需求描述、目标用户、设计目的、使用情景、Keyword 注意项等。
原始需求工作表中每一项在产品设计中都是非常重要，不可忽略的，一个整体部分被拆成了更小的多个部分，每个部分都有对应的目的：
素材部分
需求方*： 即设计该产品的需求提供方， 能够帮助我们了解原始需求的提出者是谁；
项目名称*： 该设计案对应的项目名称， 明确了我们要做的项目是什么名称；
需求素材清单*： 需求方的需求素材，可能是文档，也可能是录音。在满足原始需求表格信息完整的前提下，这部分材料可能为空。
提炼部分
原始需求描述*： 需求原话及对需求原话的未修饰提炼；
目标用户*： 产品的目标使用者， 在这里能够初步确定我们需要服务的对象群体，即目标用户；
设计目的*： ==这是原始需求工作表中最为重要的元素。在设计产品之前，我们首要考虑的就是设计这个产品的目的，即说明“为了什么而做这个”，原始需求描述与目的描述相匹配，有较强的逻辑性和推导性==；
使用情景*： 用户使用产品的环境，包括使用的出发点、使用情况的描述， 使用情景体现了需求方在需求描述中所涉及的情景；
Keyword*： 是从用户使用产品的场景中提取出的关键词，可以在后续设计节点中利用这些关键词进行设计思考。
注意项
时间要求*：完成本设计案的时间要求， 提醒我们需要在这个时间要求下将项目完成；
产品形态*：待设计产品的形态（如独立 App、接入某个系统、独立网页端、独立客户端、某系统组件等）；
优先适配平台*：明确产品优先适配的平台，（如 101PAD、移动手机、 PC 客户端、网页版等） ；
需求方签字确认*：用于原始需求表格制作完成后与产品设计需求方确认， 设计者只有在需求方签字确认后方可依照原始需求开展接下来的设计工作。
设计方法论通过结构化的形式，对原始需求进行合理的记录、拆解，形成原始需求工作表。原始需求工作表能够给设计者很大帮助，主要表现在信息清晰、不易遗漏、可操作等方面。
- 信息清晰：结构化的原始需求将产品设计要求的各个信息点分条目的罗列出来，一目了然；
- 不易遗漏：在分析产品设计要求的时候，只需对各个结构要素一一查看、分析、理解，无需在杂乱的需求素材中筛选信息；
- 可操作：在与需求方沟通产品设计需求的时候，设计者与需求方只需要针对某一些结构要素进行添加与修改，而不会“ 牵一发而动全身” 。
这些结构要素将通过一张表格清晰地呈现在设计方法论使用者的面前，接下来我们可以用它进行设计案的需求记录和整理。不管是对于设计新手还是设计老手，都建议采用推荐的工作表进行填写，表中所要求的各项要素最好都要有记录，这样能方便设计者对原始需求有全面的理解。
原始需求获取
接下来将介绍我们在进行原始需求的获取时需要了解的一些事情：
设计者将从需求方处得到的原始需求进行整理，并归纳成规范的文档，才算正式的获取原始需求。
一个标准的原始需求获取流程情景是这样的：设计者发掘或收到来自需求方的需求描述 → 设计者尽量采用需求方原话对其如实整理，并标注出需求方以及其在不同阶段提出或变更需求时的会议议题时间，将需求素材以时间倒序来排序并标明出处 → 设计者通过分析需求素材资料，把不明确的需求点进行描述，并对需求优先级排序，并整理出完整的原始需求工作表，最后与需求方确认。
如遇到某些只有一句话的原始需求，建议设计者先对原始需求有结构化的思考（如==需求定义、范围圈定、面向群体、解决的问题等==），制作原始需求工作表，通过提交设计者理解的原始需求与需求方确认，根据需求方在此基础上给出的反馈建议进行修正，从而获取完整的原始需求。由于获取到的原始需求主要用来查看和回顾，以及需求的确认，所以原始需求描述一定要如实反映需求方的需求或要求，不得歪曲或编造需求。我们建议尽量保留需求方的原话内容进行整理，尽可能避免断章取义。获取并记录的原始需求还可以修改，需求方对需求变更或补充的，要在原始需求描述中，体现多个需求版本记录及需求情况，并且要把最近的需求放在最前面，并标注时间和需求来源。
整理原始需求时，需要注意四点：
如实记录需求，是正确解读原始需求的前提； 原始需求是未经加工处理的，需求提出方的要求，制作“原始需求列表”的目的是如实记录需求方对产品设计的要求，一般不需要修改原始需求描述。确保准确如实的记录原始需求的步骤有：多次需求沟通→特别留意，记录“目的”或“情景”→保存原始记录材料（如照片、录音等）→初步解读，整理问题，在沟通时向需求方提问并确认。 这些步骤都是为了还原需求提出方最原始的需求描述，减少设计者主观臆断和经验偏好，确保产品设计始终从原始需求出发，做到有迹可寻，避免设计过程中的错误解读将原始需求覆盖。
对比期待和现状的差异，进一步理解原始需求的思考逻辑。 一般情况下，需求提出人不是产品设计者，描述语句不会按照产品设计的逻辑进行输出。不过原始需求描述中，需求方通常会提出自己的期待（或假设的状态）。 设计者通过理解或挖掘这些“期待” ——即与现实中产品与竞品的差异，有助于深入解读原始需求；更多时候，这些“期待”与现状的差异，以需求方遇到的“困难”或“ 痛点”形式描述出来。设计者需要对比这种“差异”，并找到消除差异的可能途径。
聚焦“设计目的”，能帮助设计者较快、较准地切入原始需求。 需求方做这个事情的目的是什么，是产品设计者需要抓住并真正理解的关键点。需求提出人可能讲了大段语句，设计者需要抓住“目的”；或者需求提出人在漫谈需求的时候，设计者也需要引导他说出“目的”。抓住需求方的目的，是理解原始需求的关键。
“需求范围”或“设计边界”的确认。 原则上任何产品的设计都是可以被不停地不断优化的，从纸张的设计、教材的设计，到市场战略的设计、治国方针的设计，人类的历史因此也变得多姿多彩而无限延展。但是对于设计者而言，大部分的产品设计任务都是阶段性的、需要按时提交成果的，因此需求的范围或者说设计的边界就是主设计者需要考量的重点。==客户 A 需要一个秋千以便在下午茶之余可以活动活动，就不能将设计蔓延到过山车和转木马。客户 B 需要一个在直播平台中彰显他 VIP 特权的体验方式，就不需要将设计蔓延到设计一套完整攀比或养成的数值系统==。所以，“需求范围”或“设计边界”是原始需求描述的时候，设计者需要确认的，特别是高级设计者需要决策的。
原始需求分析
设计者在完成原始需求获取后，需要花大量的时间对它进行详细的分析并整理，以达到设计过程不遗漏重要信息、设计结果不偏离需求方期望等目的。接下来将与大家详细介绍原始需求分析，以及“ 设计方法论” 中的原始需求整理方法。
原始需求分析实际上就是一个从要求中找到切入点的过程，具体是如何操作的呢？接下来我们将会展开讲讲
设计者在工作中往往会接到各种各样的设计需求，这些要求可能是上级直接给定的概念性要求，而且内容较零散。同时，从实际经验来看，产品设计者在设计工作中往往会遗漏一些信息，甚至是重要的设计需求信息。为了解决这个问题同时更好地找到要求的切入点，我们建议先在原始需求工作表中将涉及该产品的需求素材形成一个清单，这样能很好地将零散的需求信息归纳总结，帮助产品设计者更好地了解和学习原始需求的来源和背景。
有时候需求素材清单过于庞大，设计者可通过关键词切入，对有效信息定位、筛选，快速对原始需求有全面的了解。同时，在记录好原始需求内容后还需要反复与需求方进行确认直至没有异议，因为原始需求工作表是后续产品设计的重要甚至是唯一的依据，是产品设计过程的一个重要环节。
原始需求整理：判断、挖掘、取舍
一开始整理原始需求，就需要排除明显不合理的需求。在这之后，再来看剩下的看似很合理的需求，从其中挖掘出产品设计需要照顾到的需求，这一步需要产品设计者对人性有深刻的洞察，对行业有足够的经验。得到产品需求之后，再回过头去看看产品定位，将产品需求和产品定位进行对照，会发现有些产品需求是不符合最初的产品定位的，这个时候需要果断抛弃掉这部分需求，得到最终的产品需求。总结起来就是 3 个步骤：
- 判断需求合理性，筛掉不合理需求；
- 深入挖掘，提炼用户产生的需求的真实动机；
- 做出取舍，去掉不符合产品定位的需求。
实例解说
《原始需求篇》的主要内容是要让我们了解什么是原始需求，掌握原始需求工作表，学会如何获取原始需求，对原始需求进行分析，并从原始需求中整理出有用的信息。
下面我们按照原始需求工作表中各项要素的要求，以“ 芦苇Plus-创建官网引导” 项目为例，来学习如何完成一张原始需求工作表。
需求方 填写该产品设计案的需求提供方。 如前述，由项目负责人综合需求，即“芦苇plus项目负责人”。
项目名称 填写设计案归属项目的名称。项目名称是帮助设计者和审核者快速了解设计案内容概要的通道，填写时需要遵循一定的规范，不可随意填写。规范的项目名称可以很好的协助产品模块管理和设计案版本管理。
这个项目背景十分明确，在 芦苇plus小程序的 PC 客户端提供“ 新建官网引导功能。项目名称为：“芦苇plus-PC 端-【新建官网引导】 ” 。
- 时间要求 如果需求提出方有明确规定时间，则直接填写即可；如果需求提出方没有明确规定时间，那么设计者需要在通读、理解需求方要求的基础上对设计案制作时间进行一个预估判断。
例 1：如果需求方要求设计者在两周内完成设计案，那么这里的时间要求填写“两周”即可； 例 2：如果需求方有提到“ 最好在两周内完成设计案” ，那么这里的时间要求则填写“最好在两周内完成”； 例 3：如果需求方没有时间要求，那么需要设计者对该设计案的工作量进行预估并填写。
- 原始需求描述 如实地描述需求方对产品设计的要求，在此填写需求原话或对需求原话的未加工提炼。原始需求描述是原始需求提炼中的最重要的部分。
从获取到的原始需求信息中，通过分析内容，整理出关键信息，并完成原始需求描述，结果可参考下表。
- 目标用户 提炼目标用户时，需要结合需求方给出的信息分析“设计出来的产品是给谁用”，主要的产品使用者即目标用户。需要注意的是，目标用户可能有多个。我们在原始需求中提炼出目标用户的目的在于，对目标用户进行初步分析，简单的描述出目标用户所具备的特征，给出明确的目标用户范围，为后续设计提供了边界。 案例中，原始需求描述4中，针对的目标用户特征是“对官网的认知度不够，需要增强引导”，定位了用户群体范围是“企业行政执行人员”。（负责进行官网编辑操作的人）
- 设计目的 设计目的即设计该产品的目的、为什么要设计该产品，需要从设计目的中体现出用户痛点以及产品的价值所在。在原始需求中提炼出设计目的，可以快速定位产品要解决的用户的核心痛点，分析得出产品的核心价值。 提炼设计目的时，如果需求方有明确的设计目的说明，须如实描述，并通过对需求描述的分析进行加工整合，判断需求方给出的明确的设计目的是否正确、完整。如果有偏差，则需要设计者修正、补充，并标明修正补充的具体内容。如果需求方没有明确的设计目的说明，设计者需根据自己理解描述出来，并高亮标注，与需求方确认。 从原始需求素材中我们将提取出多个目的，参考原始需求描述中的内容，按顺序整理如下：
1.帮助新用户知道新建官网的基本用法； 2.解决用户编辑官网未满足标准时不能正常插入、保存、预览的疑难问题； 3.提示用户保存已修改的官网内容，避免未保存丢失新官网内容； 4.提高行政人员对挂网的认知程度和新建官网的质量；
- 使用情景 根据对需求方提出的要求分析使用情景，在此填写用户使用产品的主要出发点、使用情况、周围环境、用户的痛点与快点等描述。需要特别注意，原始需求中的使用情景与一般的情景存在细微的差别，原始需求中的使用情景是指需求方在需求描述中所涉及的情景，如需求方未提及使用情景，设计者可以根据对原始需求的理解，提出最符合原始需求的典型情景。
企业行政人员会怎样使用 芦苇plus呢？他们在初次使用时会遇到什么样的问题？把这样一个场景还原出来，我们得到： 1.企业行政人员使用芦苇plus做企业介绍，想在小程序新建企业介绍的相关信息，但是他在进入PC管理后台后，不知道该如何创建、编辑官网内容； 2.企业行政人员小 A 在新建官网时，插入案例图片时候由于图片格式不正确无法插入到编辑的案例详情中，但是由于系统未提示错误原因，所以小A不知道自己哪里操作错误了，感到很疑惑。
- 产品形态 产品形态是指明确该产品的输出形态。如果不明确，需要注明并与需求方确认。分析产品形态会帮助我们进行自检，确认产品输出形态是否为最优方案，并考虑产品复用、功能扩展、组件化生产等方面的可能性，以提高生产效率，增强产品生命力。 常见的产品形态有：移动 APP、 VR APP、接入某个系统、独立网页端、独立客户端、组件化、其他形态… 这些分类都是软件产品的形态， 其他类型如：实物、服务等类型的产品形态同样存在。 “新建官网引导”功能是在芦苇Plus管理后台 上的一个功能，芦苇Plus管理后台 在用户电脑上是独立网页端。
- 优先适配平台 优先适配平台是指当前满足原始需求，最优先选择的产品载体。如这一项在原始需求中不明确，需要注明并与需求方确认。“优先适配”， 顾名思义，是指适配平台中优先级最高的平台，可从产品形态、项目现 有平台、开发成本、开发实现难度等维度全面考量后选择。明确优先适配平台，会使设计更加具有目的性，同时为后续的情景分析和功能提炼圈定了范围。如果没有找到优先适配平台，会使设计混乱，出现设计产出的功能适用平台不一致，导致功能无法整合的情况。 常见的优先适配平台类型有： PAD、移动手机、 PC 客户端、 WEB版（同步适配移动端、无须适配移动端）、 VR 设备（需注明具体设备型号）、其他等。 对于本案例，为：PC 客户端。
- 原始需求素材清单 如前所述，整理获得的需求素材，素材形式可以是文档、录音等。 可将文档打包存放在某处，做好文档管理工作。
- Keyword keyword 是指能体现原始需求核心功能和内容的关键词。根据需求方的需求提取功能关键词并填写 keyword，用于对后续设计的指导，对设计起到了提纲挈领的作用，方便设计者在后续设计节点利用这些关键词进行设计思考。如果不提炼关键词则可能导致后续设计节点由于没有纲领性内容的指导而出现偏差。
- 提炼出的关键词并不是越多越好，设计者需要对原始需求进行统览后，归纳出设计方向和最核心的功能点，从而提炼出关键词，数量以 3-5 个为佳*，可根据项目实际要求进行调整。 关键词可以是：官网引导、页面提示、流程引导…
- 需求方签字确认 在设计者撰写好原始需求后反复与产品设计需求方确认，最后可将该表格打印出来，由需求方在此处签字确认。审核方签字确认是为了保证在原始需求阶段对需求提炼的完整性和准确性，保证了后续设计工作顺利开展。一般情况下，原始需求需经过需求方或其授权的负责人确认通过后，才进行后续环节的设计。
通过记录、分析、整理，我们得到了完整的原始需求工作表：
