设计师如何分析需求？

编辑导语：需求分析可不是产品经理一人的工作，设计师在日常工作中除了要对产品进行设计以外，更要参与到需求分析里面，了解用户的真正需求，从而做出更加全面优秀的产品；本文作者分享了关于设计师应该怎么进行需求的分析，我们一起来看一下。

01 关于需求

1. 什么是需求

这里的需求指业务需求，即现状无法满足需要，从而为达到某种目标而制定的；需求主体未必只有用户，也可能是企业、产品、运营、技术。

2. 需求的分类

需求可以大致分类两大类，内部需求和外部需求：

什么是内部需求？

内部需求即由企业内部发起的，基于企业、产品本身商业（产品、运营）、体验（设计、技术）等层面的诉求而提出的。

• 产品的需求：由产品侧发起，最为常见，通常基于对产品发展目标、商业目标、竞品动向、行业变化等层面考虑的需求。
• 运营的需求：由运营侧发起，通常基于运营活动、玩法等层面考虑的需求。
• 设计的需求：由设计侧发起，通常基于对体验、视觉等层面考虑的需求。
• 技术的需求：由技术侧发起，通常基于对产品技术体验、性能优化等层面考虑的需求。
• 领导的需求：由公司上层发起，一般与产品经理发起的需求类似，但有时也可能临时想法。
• …

什么是外部需求？

• 外部需求即所有在企业以外发起的，基于对企业产品的诉求、要求得不到满足而提出的。
• 用户需求：主要来自 C 端产品，用户对于产品的反馈，或企业对用户的调研而得出的需求。
• 客户需求：主要来自 B 端产品，客户对于产品功能、性能等层面考虑的需求。
• 政策需求：主要来自相关政策法规，通常基于对产品合规性、用户隐私权限等层面进行规范要求而整改的需求。
• …

以上列举的是常见的需求类型，可以发现需求类型其实是多样的，设计师对于需求类型的鉴别也需要有一定的认知。

3. 产品经理与设计师的需求分析

在互联网公司中，常见的职能角色主要有：产品经理、交互设计（主要分布在中型、大型互联网公司）、UI 设计、研发、测试；但除了产品经理之外，设计师对于需求分析的了解也有很大的必要性。

上面提到，产品是需求的主要发起者，所以理所应当有很大一部分工作量就是需求分析。设计师的工作，最常见的就是对接需求，然后将需求转化为设计。而这个流程中的关键点，就是作为交互、UI 设计师，应该如何正确的分析需求。

有人说，分析需求不是产品经理的事情吗？交互设计师只要会画框架框架不就行了？如果这么想，那是还没有对“分析需求”本身有足够清晰的认知。

如果从用户体验五要素的层面对需求分析进行划分，可以发现：

• 战略层告诉我们“什么是产品目标、用户需求”
• 范围层告诉我们“什么方式、内容、功能可以满足需求”
• 结构层告诉我们“如何分布这些满足需求的内容、功能”
• 框架层告诉我们”如何设计这些满足需求的界面框架、信息呈现”
• 表现层告诉我们“如何设计符合产品定位、风格、需求特征的最终展示外观”

结论：

产品经理的需求分析：侧重于从商业维度考虑产品目标，考虑用户的需求是什么，以及用什么样的东西去满足用户需求。

设计师的需求分析：更侧重于基于对产品需求的正确理解，从用户、商业的层面考虑，并采用合适的设计形式来实现。

02 对齐需求：正确沟通

在体量较小的公司，产品经理会肩负需求分析、交互设计等工作。而在体量较大或者更重视用户体验的公司，设计师则可以更加聚焦于如何权衡商业与用户体验。

这时，摆在产品经理与设计师面前的会有 2 道鸿沟：

1. 需求理解的鸿沟

产品经理是设计师最常见的需求对接者，基本上是产品经理发起需求，设计师执行；这个过程是先后关系，大部分情况下也是单向传递的。

当产品经理比较强势时，即使设计师对需求有疑问，也只能当成意见补充，而是否接受很大程度上是产品经理决定；这里面的沟通很关键，因为这条鸿沟决定着设计师是否能够正确理解需求背后的本质，理解本质需求就是跨越这条鸿沟的桥梁。

正确的沟通姿势是理解需求的第一步，而这一步基本定义了整个交互、UI 的设计走向，需求目标会影响设计师的思考方式；当没有将需求目标透彻理解时，会使思考方式严重受限，比如产品需求是让设计一个弹窗，设计师就原原本本的设计一个弹窗，而不去思考为什么要设计这个弹窗。

我们该如何正确理解需求？

关注本质：

产品输出需求文档的时候，大多会输出初步的交互框架想法或者视觉设计建议，但在需求沟通时，最关键的一点是关注本质需求，避免一开始就陷进具体的需求细节；这里并非说产品提供的方案不好，事实上，有时交互方案与产品提供的方案一致，这是不可避免的，当目标相对清晰的时候，不需要为了特地设计而设计。

但是，如果沟通需求时，过于关注细节，容易导致看不清需求的本质。所以，当与产品经理沟通时，可以多问问为什么要做这个需求，是为了达到什么目标，满足什么需求，然后从交互体验、创意性等角度出发，思考更好的交互方案。

甄别需求：

无论是内部需求还是外部需求，一般都会汇总到产品经理，再由产品经理与设计侧以及其他职能同事对接；需求来源多样，特别是用户需求，我们都知道用户表达或反馈的需求未必是用户的真实需求，所以在沟通时，应该甄别哪些需求不合理。

设计师有用户体验的立场，站在不同立场上，往往可以发现不同的问题，将问题在需求阶段暴露出来，避免执行过程反复调整。

2. 意见冲突的鸿沟

产品经理与设计师职能不同，所以立场、关注点都会有差别。

首先，我们需要接受产品经理与设计师的意见是一定会产生冲突的，所以不要觉得为什么与产品经理怎么总是意见不合。

其次，站在双方的共同目标都是让产品变得更好的角度，我并不认为意见冲突是不好的；相反，这是在前期基于双方不同立场对于需求本身合理性的充分讨论，达到双方都认同的意见，然后共同将产品做好。

如何跨过产品经理与设计师意见冲突的鸿沟？

理解目标：

要看清这个问题，需要回归到产品经理与设计师立场的差异上，设计师习惯性的会站在用户体验的角度上思考问题，也往往需要为体验负责；而产品经理需要考虑更多产品策略方面的问题，有业务的 KPI。

在沟通需求时，双方意见不合主要是关注的目标不一致。这时，设计师不该只从体验好与不好、这么做好不好看的角度出发思考问题；而是需要基于用户体验并在理解商业目标的基础上进行沟通。作为设计师，不能盲目接受需求，更不能盲目拒绝需求。

提前介入：

不同企业的产品流程会有一些差异，但大部分是产品需求过了几轮评审之后，流转到设计。此时就算设计师对需求有不同意见且产品也同意调整，在某些情况下也可能造成项目延期的风险。

如果条件允许，设计师可以提前介入到需求评审阶段，即在需求评审初期可以表达设计侧对需求的看法，而需求评审可以充分进行需求讨论。此外，某些产品需求（比如要求较多的设计创意发散）可能会强依赖于设计、动画等职能角色参与，提前介入可以在需求前期有充分表达设计观点的机会。

03 拆解需求：5W1H 法

5W1H 分析法也叫六何分析法，是一种思考方法，也是工作方法；可以帮助我们避免只关注某个细节或者具体的需求方案，而是从顶层开始思考的方式。

大部分人都听过这个方法，但是日常工作中不太知道应该如何使用，个人理解，这个方法在很小的需求方面不太适合；但是在处理比较中型/大型的需求、设计师对需求本身疑惑时、甚至与产品经理意见分歧时，有很大的用处。

原因（ Why）：

需求的背景是什么，产品在当前遇到了什么问题，比如数据差、体验反馈差等。

想要达到什么目标，是商业需求还是用户需求？

产品所在行业的竞品情况如何，市场趋势如何？

对象（ What）：

需求的内容是什么，基于需求的背景、目标，产品即将做什么事情？注意不能局限于做某个具体形态的事情，可以尝试描述这件事情如何满足需求。

场景（ Where）：

什么场景出现这个需求？

需求的最终产物会在什么场景/页面/模块出现？

时间（When）：

什么时间节点出现这个需求？

需求的最终产物会在什么时间节点出现？

用户（Who）：

产品的用户是谁？这个“谁”不是只某个个体，而是产品的某类典型群体。

用户需求是什么？用户遇到了什问题？可以将用户需求枚举出来，但是需要注意用户需求不一定等于产品需求。

方法（How）：

需求所要做的这件事情，实现方式是怎么样的？

有没有其他可能的方式可以更好的实现这件事情？

思考产品提出的需求建议方案，与需求目标是否一致；设计师理解并同意以上拆分的结论，那就证明需求本身层面是没有异议的，接下来就是需求实现层面的问题了；此时设计师的工作，就是思考是否还存在更好的实现方式能够满足这个需求。

如果以上问题不够明确，那么可能需求本身可能有值得商榷的部分。

以需求目标为导向，是判断方案是否可行的最直接方法；这种沟通方式，可以帮助设计师与产品经理构建相同目标、场景等变量信息，帮助产品经理与设计师对齐设计目标，减少后续方案返工的情况；我们通过梳理这些信息，尽管未必能够马上思考出方案，但是能够初步判断哪些方案可能不太合适。

以上是对于 5W1H 的基本拆解，下面我会尝试举一个虚拟例子进行解释。

某天，产品经理提了一个需求：

需求内容：

优化用户取消订单的挽留弹窗。线上的样式是底部弹窗，但是底部弹窗容易点击“取消订单”按钮，且文字提示不够清晰。

初步方案是将弹窗样式改成居中弹窗，对于用户提醒层面会更加明显，如下图：

你觉得很奇怪，把弹窗从底部改为居中样式，尽管提示更明显了，但是真的能够降低用户的取消率吗？实际上，你甚至不清楚这个弹窗对于用户是否有帮助，也不清楚是否能解决需求的问题。你可能会思考，假如你是用户，会因为这个弹窗就不取消订单吗？

很多产品都会设计页面退出时的挽留弹窗，常见的如“确定退出页面吗？ 退出/取消”，但这经常是一种为了做而做的挽留弹窗；对于这种弹窗，是否可能不仅不能带来目标效果，反而容易引起用户的反感。

我们在分析需求时，可以尝试简单拆解一下这个需求：

原因（Why）：

需求的背景：行业内，用户下单之后都有取消订单的操作，本平台的订单取消率处于行业中的平均水平，基于对产品的优化，希望可以降低订单的取消率。

对象（What）：

通过某种方式，降低订单取消率。目前比较合适的方式是优化取消订单的挽留弹窗。

场景（Where）：

我的订单页，目前其他场景无法取消订单，所以场景比较明确。

时间（When）：

用户已经下单（已支付/未支付）之后，点击【取消订单】按钮后触发挽留弹窗。

用户（Who）：

目标用户：已经下单的用户。

用户需求：枚举用户遇到的问题，如：点错了、忘记支付密码、不想买了、收货地址填错了、其他原因。

方法（How）：

初步想法：把底部挽留弹窗改成居中挽留弹窗。

其他想法：是否还有其他方式降低取消率？

你会发现，这个需求其实是可以被拆解的。在这个需求里，你会发现，尽管原因（Why）很清晰，但是用户（Who）是推导出来的结论方法（How）是有些问题的；当从用户角度出发 ，仅仅一个居中挽留弹窗是无法解决用户需求的。

这里需要警惕一个点，即设计“挽留弹窗”这件事情，先不管最终产物是不是一个弹窗的形式，但是不能一开始就陷入“我要设计一个弹窗”的思维，可以先思考下，我需要通过什么方式降低用户的取消率？

但是我们如何发现潜在的更优方案呢？

可以尝试多几个问号：用户为什么会取消订单？设计挽留弹窗，是否就真的对降低取消率？设计挽留弹窗，能否解决用户在这个场景遇到的问题？是否可能不用挽留弹窗降低取消率？

通过上面用户需求列举，你可能会发现部分取消订单原因，是不需要用户取消了订单才能解决的，比如“地址填错了”，并且这部分用户在本平台订单取消率中占了一大部分。

这时需求的解决方式，可能变成：

通过向用户提供修改收货地址的入口降低订单取消率。此时弹窗的动机不再是为了“阻挡”用户，而是推测用户操作意图，帮助用户解决问题。

相比于单纯的阻挡弹窗，这种处理方式的好处是：通过找到并解决部分操作的根本原因，以减少负向操作，帮助平台更好分析用户取消订单的原因以改善产品体验；

如果填错地址的用户占了订单取消率的很高比重，是否可能尝试优化下单流程？比如将让用户更明确感知订单地址，避免用户选错地址；从而通过优化本质的问题，减少用户取消订单的比例，也减少弹窗出现的频次。

最后你会发现，设计出来的方案可能会以弹窗作为表现形式，也可能通过优化下单流程降低取消率；这个方法主要是将需求梳理清楚，让我们明确这个需求的来龙去脉，减少遗漏的问题。

04 发现真正需求：双钻设计模式

2005年，英国设计协会（the British Design Council）首次提出这种双发散—聚焦设计模式，被称作双钻设计模式（double-diamond design process model）。

英国设计协会将设计过程分为四个步骤：“发现”和“定义”，确认正确问题的发散和聚焦阶段；然后是“构思”和“交付”，制定正确方案的发散和聚焦阶段。

迄今为止，我们其实可以看到许多设计方法，这些方法可以让我们避免从初始问题直接思考解决方案，避免因为忽视真正的、根本的问题而设计价值不大的设计方案。

双钻设计模式，与上面的 5W1H 分析法都是属于设计分析方法，也同样可以帮助我们如何分析需求、拆解需求、解决正确的问题。

设计师在需求分析过程中，要明确需求是某种方案，但未必是最终结果；尽管从效率层面看起来像是在倒退，因为明明产品经理已经提供了方案，而设计师还要重新思考。

但实际上，这种思考方式，恰恰可以避免局限于某种职能视角思考问题。

为什么称为双钻模型？

• 设计师会先质疑问题，接着扩大问题的范围，思考问题之下隐藏的根本原因，接着聚焦于其中某一个问题的描述。
• 在思考解决方案阶段，会先扩展可能的方案，再进行一次发散思考。最后，将这一切重归于某个合适的方案。

拿到问题——发散——聚焦——发散——聚焦，看起来像是两颗并列的钻石，所以称作双钻模型。

发现问题：

对现状进行深入研究。包括了解用户特征、产品当前状况、用户如何使用产品以及用户对产品的态度、竞品现状等，此时我们不会将聚焦于某一个问题，而是穷举尽可能多的潜在问题。

定义问题：

确定关键问题。这一阶段，我们关注的焦点是：用户当前最关注、最需要解决的问题是哪些，需要根据团队的资源状况作出取舍，聚焦到核心问题上。

构思方案：

寻找潜在的解决方案。在方案发散阶段，我们不需要过多考虑技术的可实现性。

交付方案：

把上阶段所有潜在的解决方案，逐个进行分析验证，选择出最适合的一个或多个方案；我认为在这个阶段，设计师可以尽可能地发散想法，但是就绝大多数国内企业、产品现状而言，很难将多种想法一一尝试，因为开发成本、项目时间等问题，可能导致投入产出比不高的情况，所以设计师应该提升对好方案的判断能力。

我们该如何使用双钻设计模式，同样在此我会举一个虚拟例子进行解释。

你们是内容资讯类产品，某天，你接到一个需求：

需求内容：

优化某应用 App 首页搜索栏，包括将搜索栏高度加高、设计颜色更加明显，以提升搜索栏的点击率。

需求背景：

对比了同行业竞品，发现竞品的搜索栏点击率比我们高了20%。我们的搜索栏点击率为 5%，而竞品为 20%；同时，通过对比发现，竞品搜索栏高度更高，搜索栏颜色更加明显，除此之外，页面其他信息区别不大。

初步分析：

这个需求问题很明确，就是我们搜索栏点击率比竞品低。但这个问题归因真的全因搜索栏高度、设计样式的影响吗？

其实未必是这个原因，搜索栏的点击行为本身更倾向于目的性点击，也就是说有相对明确的目的去点击，而目前高度虽然不高，但是足够明确。

采用双钻设计模型分析：

通过双钻模型“发散——聚焦”的分析和验证，我们发现最终解决方案不仅仅是最初的方案，这四个阶段不是孤立存在的，而是彼此联系。

当然这种举例是为了更加便于理解，实际项目中一定会遇到很多问题是很复杂且很难顺利解决的；但是这种设计模式帮助我们减少用局限性的眼光进行设计，发现正确的问题，发现正确的解决方案。

06 分析思维：结构化思维

1. 什么是结构性思维？

有人这么解释：以事物的结构为思考对象，来引导思维、表达和解决问题的一种思考方法，逻辑框架像金字塔结构，以上统下，归纳总结。

我理解中的结构化思维，是灵活可变的。比如上述提到的的 5W1H ，就是结构化思维的一种，因为这里体现的是一种结构，并非必须 5W+1H ，在合适场景也可以演变成 5W+2H 等。

当我们面对一个需求时，我们是如何进行分析的？出了方案应该如何和其他人描述？如何判断方案的合理性？

一种人看了需求，了解需求概况，然后开始找参考找灵感，找到相同页面类型的，然后看看有没有什么可以借鉴（抄）的，开始发散思考表现和形式，提出的方案不清楚优劣性。这是不是像许多人平时思考需求、思考问题的方式？

而使用结构化思维的分析方式是：

1）仔细推敲需求产生的原因、背景，而不是单纯只看需求，然后结合需求得出初步的改进目标。

2）分析需求的相关用户群体。不同产品的相关用户群体不一致，比如电商产品相关用户群体是普通用户、商家；网约车相相关用户群体是用户和司机；B 端产品相关用户群体有客户（负责购买）和用户（负责使用）

3）结构化的分析竞品，而不是单纯找灵感。如看竞品是如何做的，而看竞品如何做并不是为了单纯只看表象，也会从不同维度进行分析：竞品为什么这么做，结果是什么？如果竞品做得不如我们，他们的不足之处在哪里？竞品这么做对我们有没有参考意义？分析竞品有助于我们通过别人的方案，帮助我们更清晰地分析目标的意义；围绕目标，再发散思维，此时的方案会比第一种人更加紧密围绕需求和目标，而不是单凭感觉去发散。我们提出的方案，相对而言也会更加具备理论、数据、分析的支撑。

4）分析方案的意义，方案对产品本身、对团队等方面是否有更多的意义。举个例子，你做的方案是否考虑到团队其他成员的复用性？是否考虑到对当前业务的数据变化以及后续维护？更甚于，对自己的意义，是否能从中学习更多内在方法？

一个需求可以拆解成多个点进行解析，比如：产品问题+产品目标+产品定位+竞品分析+相关用户群体+体验地图+ … + 需求类别特性（不唯一）；但是，并非每个需求都需要把产品定位、体验地图拿出来遛一遍，这样子就变成了生搬硬套，我们需要根据具体需求思考不同的分析点。

我们在需求分析中，最常用到的是以下几种，当然还有一些其他的拆分点，根据不同产品类型，分析的结构也不一致。

问题：我们产品当前遇到什么问题？

目标：针对当前的问题，我们期望达到什么目标？

竞品分析：竞品分析几乎做需求前必做的，关键在于参考其他产品的设计思路，以及别人能够做到什么样的程度。基于目标，侧重于从交互、UI 的设计层面进行分析、类比。

相关用户群体：最基础的当然是普通用户，此外根据不同产品或者不同功能类型有：商家（电商类）、UP 主（B 站等）、CP（内容提供商）、司机（网约车类）等，甚至同一产品不同功能模块需要考虑的相关用户群体也不同。

需求类别特性：基于不同需求的相关内容而言的，这种变量会更聚焦于某需求的具体内容，但是一个具体需求是可以被拆分成多种维度，比如信息维度、框架维度、设计风格维度；假如你在做一个搜索的需求，分析的变量就是搜索操作类型、搜索推荐方式、搜索结果呈现规则等。假如你在做一个信息流的需求，分析的变量就是信息推荐规则、信息卡片呈现方式等。

结构性思维，无论是在沟通、处理分析问题上，对我们都有很大的帮助；在设计中，我们可以通过这种思考方式，避免让方案过于发散而不聚焦，更好地判断方案对于业务、团队、自身的意义，以达到清楚方案的优劣性的目的。

07 结语

本文介绍了设计师在项目中如何更好的沟通需求的方法，当然除了上述的方法之外，还有更多方法可以帮助我们解决问题，但我认为本质上是学会如何用全局的眼光看待需求，避免局限于具体解决方案。

在实际项目中，我们会遇到多种类型的需求，特别是遇到较大的需求时，运用合适的分析方法特别重要，这能够很有指导性的帮助我们有意识、有节奏的看待需求。

避免为了使用某种方法论而强行使用，需要根据不同的需求场景使用不同的方法。

作为设计师，很关键的一点是判断什么需求是真实需求、什么需求是伪需求，这在需求沟通、需求分析中会形成较大差异。

当然这并非一朝一夕可以提升的，需要通过不断学习对用户行为及体验的理解、对商业的理解才能提升。

以上内容希望可以帮助到各位。

 

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

题图来自Unsplash，基于CC0协议