hello 大家好，欢迎来到小岛《UX基础》专题的通全第一章 。需求沟通是攻略高效沟通设计师日常工作对接的第一环 ，好的掌握需求沟通过程能够为设计过程进行提效 ，也能提前规避风险与了解各方预期 。核心接下来为大家介绍需求沟通过程前中后都可以用到的步骤沟通与评估方法 ，以及过程中的设计师需注意事项 。
一些重大的项目设计师需要前置地介入到需求初期 ，在需求正式提过来之前就与各方探讨需求的攻略高效沟通方向，这也是掌握设计师价值的重要体现之一。在需求的核心前置沟通阶段 ，我们可以准备以下几件事情：
1. 提前介入需求 ，步骤给出设计侧建议 ：提前介入到需求中和各相关方开会 ，设计师需可以给出基于设计侧的一些建议 ，在需求初期对体验效果进行把控。除此之外 ，提前介入还可以大大减少收到需求后的信息差 ，因为我们从很早便已介入 ，主动倾听和观察各方沟通记录。
2. 提前对该需求进行设计侧的着手准备 ：重大项目设计侧可以提前介入并完成前期的竞品分析/用户调研等过程 ，这样正式收到需求后 ，就可以基于现有的调研直接进入到产出阶段 ，更为高效 。
3. 了解上级的期望 ：大型的需求初期我们要提前了解上级的期望 、方向建议 。切记不要"闷声憋大招" ！尤其是当任务是直接分配给我们的 、过程中我们并没有参会 ，要在开始前多询问一下上级的目标和期待 ，时刻对焦对方的期待 。
上游产品团队在给设计侧提需后（由于各公司均有自己提需格式/流程 ，以及对提需邮件的格式要求 ，这里不对此展开说明），在收到 prd 后 ，我们要全面仔细地查阅 prd ，与产品进行线下沟通 ，大家可以在需求沟通的过程中明确以下内容 ，在下述内容都明确后再正式开始设计工作 。
1. 了解需求背景
在了解需求背景时 ，大家需要搞清楚：
为什么发起这次需求 ？
为什么做这个需求？是什么触发了本次的需求 。是因为用户数据下降 ？有不好的反馈 ？通过询问上述情况 ，大致了解发起需求的原因。同时还要搞清楚需求的源头 ，有时需求的源头是业务侧 ，产品侧在其中进行了需求转化 ，此时就要更深一步思考业务侧为什么做这件事 。
挖掘需求/问题的本质
要思考需求或者问题的本质 ，有些需求提过来时只是需求的表象，并不是真正的需求。
为了挖掘到问题的本质 ，我们需要不断地追问"why"，从一个初始问题不断追问下去 。
例如 ："为什么要做填写页提交强提示 alert ？——因为用户对其中一项投诉很多 ——为什么投诉很多 ——因为用户不知道怎么填写第五项就随便进行选择 ，最终导致所选内容与实际诉求不符——为什么用户不知道怎么填写——填写时的引导信息匮乏" 。那么最终问题就被转化成了表单设计项本身 。
不断追问 why ，有助于我们找到最本质的问题，找到了正确的问题 ，也就找到了那个相对正确的解决方案 。一个正确的问题往往比无数个解决方案来的重要 。
将抽象需求描述转化成具像描述
有时我们收到需求时 ，对方的描述很抽象，此时就要不断引导其将抽象转化为具象。举个例子 ，如果有人说 "我觉得展示的标签数量有点少"。此时就要和对方明确"少"的定义是什么 ，多少算少 ？具体个数要求期望是多少 ？
再比如 ，对方说"我觉得整体页面的线索有点乱 。" ，此时就要进一步明确他认为哪里乱 ，"乱"具体指的是什么 。
对于可能会出现双方理解偏差的问题 ，可以用自己的语言组织后再次确认"你的意思是指 xxxx 吗 ？"；
我们要一步步挖掘对方对所期望目标的具象表达 ，以帮助设计师明确优化方向 。
需求是在什么场景下 、满足哪部分用户的什么目标和诉求？
1. 什么场景？：用户需求通常是在特定场景下产生的，通过了解需求场景 ，能更好地带入用户角色中 。场景不仅包括用户所在环境 ，还包括了时间，我们能根据需求产生的时间分析持续时间和频率 ，来判断需求优先程度 。
2. 用户是谁 ？ ：用户的国家年龄 、身份 、性别等等
3. 要满足用户什么目标与诉求 ？ ：检查需求是为了满足用户什么诉求 ，帮助用户解决了什么问题/痛点，优化改版后对他们而言有什么价值？此外还要从商业的角度 ，判断这个需求如果做了 ，获益的用户是谁 ？如果不做 ，用户是否会弃用，弃用用户占比多大 ？
2. 需求的目标/价值
需求的目标主要分为以下几个方面：
1. 商业目标：需求期望带来多少收益 ，预判收入规模 ，和查看 ROI 计算结果 ，评判开发出来后是否真的会有用户使用，用户是否会为这个新产品/功能买单 。审查商业目标有助于评估需求的优先级进行排期 。
2. 验证指标 ：需求上线之后，将采用什么过程指标和结果指标（如交易平台的 GMV 等） ，来验证衡量项目是成功的 。过程指标便于在结果指标出现异常时 ，作为归因方法之一 。
3. 短期和长期目标 ：避免需求只是短时间的缝缝补补 ，而没有站在长远的角度看待解决问题的策略 ，此时我们就要审视需求长期目标是什么 ，和从长远的角度看待需求的必要性 。
3. 需求的范围
渠道范围 ：包括 online、h5 、app 、后台等等 。
页面范围 ：涉及哪些应用的哪些页面。
4. 预期效果
了解需求的预期效果可以从以下方面入手 ：
1. 明确在产品团队内部知晓需求的基础上 ，产品团队期望达成的效果是什么样子 ？对产出有什么具体的期望 ？是希望大改（且项目时间也允许）还是只是微调 ？
2. 明确自己 leader 期望达到的效果 。
3. 明确团队成员中每个人的期待，提炼总结团队成员的想法 。
5. 与需求"相关方"的沟通
1. 明确需求是否已经和相关方沟通过 ：例如一个需求是另一个项目的配合需求 ，要明确这个需求是否和项目负责人同步过并获得认可 。又例如 ，一个需求涉及复杂的研发技术改造，就要明确是否已和开发沟通项目难度 ，以避免设计师一顿操作猛如虎最终发现无法实现 ，造成工作量浪费 。如果项目对现状改动很大 ，牵涉相关方很多，我们就需要和相关方确认这个页面支持改动到什么程度 。
2. 产品团队内部的沟通结果 ：明确需求是否是产品内部讨论的结果 ，明确执行产品和其上级对需求的确定性 。以避免未达成产品团队期望 。
3. 不盲目跟风其他相似设计 ，及时了解背景 ：有时需求里会提到"希望和谁谁谁保持一致 ，和谁谁谁对齐" 。对于这种需求 ，要先去了解下对方做这件事原因背景 ，再试想下基于对方的出发点是否适合于当前需求 。不要盲目和别人对齐，要有自己的判断 。毕竟对于"他们也是这样做的"这种理由是站不住脚的 ，并不是有别人在做 ，就代表这件事是"好的"和"适合我们的" 。
6. 风险预判
风险预判是区分设计师能力的重要差异之一 ，优秀的设计师能够在短暂的沟通中预判需求的风险 ，并给出恰当的 、基于设计侧的建议 。切记再小的需求也不能缺失需求的风险评估。
1. 可以套用线上数据进行模拟评估 ：套用现状数据来评估风险 ，这才会比较贴合业务的实际情况 ，避免主观自我表达和毫无依据地说服别人 。此外 ，当我们收集完现状数据评估风险后 ，上级和其他人才能够依据你提供的信息作出决策 。
2. 切换到用户视角还原使用过程 ：对于产品方案 ，设计师要还原用户的真实使用过程 ，试想实际使用过程中可能发生的问题 ，与团队成员沟通解决掉这些问题 。
7. 解决方案，和推导出解决方案的严谨度
除了要了解 prd 中所提出的解决方案 ，还要了解从需求到推导出解决方案的整个过程 ，是否合乎逻辑 ，推导是否足够严谨 ：
严谨的推导过程可以解释——为何在无数种可能的解决方案中 ，最终选择了这个解决方案？在双钻模型中往往需要发散解决方案和收拢解决方案来找到最合适的解法 ，因此对需求解决方案推导也是同理，在了解发散/收敛解决方案的思维过程中才能评判出 ，对比其他解决方案，当前解决方案是最合适的 。
此外我们还要判断解决方案是否可以真的解决问题 ，例如可以寻找线上数据进行模拟来验证是否可以解决问题。
8. 功能清单与信息需求
功能清单 ：需求包括的功能有哪些 ？
功能对应的流程图 ：可视化的呈现一个功能的流程图 ，例如新增一个商品需要经过"信息填写——提交校验——新增成功"等步骤 ，每一个步骤可能会有成功和失败状态 。
信息需求 ：详细到每个功能对应需要的每个字段。
产品整体流程图 ：产品整体流程图可以和上下游同事解释在完成一个业务时 ，其中的场景 、参与角色、彼此的关联、核心的主流程 。产品流程图中要表明完成哪些任务 、核心节点等 。
9. 时间规划
1. 需求上线时间计划 ：包括评审 、测试 、验收 、发布上线时间节点等 。
2. 如是较大项目需要拆分阶段 ：按迭代周期将功能需求细分为多个开发阶段 ，每个阶段的上线时间分别是何时？检查每个阶段的目标完成时间和重要里程碑事件 。
3. 明确实验成功 or 失败之后的规划。
10. 调研资料
查看需求中是否附带了前期的调研资料 ，包括：
用户数据 ：例如人群特征 、偏好 、历史使用数据等；
业务数据 ：商业数据 ，例如 xxx 优惠券的覆盖率等；
历史文档 ：历史的相关项目文档 ，例如 prd 和复盘等 ，站在别人的经验上才可以看得更远 。
11. 数据需求
埋点需求 ：查看埋点方案 ，如设计师需要增加一些验证指标但缺少埋点 ，也可在埋点需求中新增埋点 。
AB 实验方案 ：AB 实验的方案、周期。
12. 懂得拒绝与上升
当发现需求内容不合理时 ，应立刻联系上级一起审核该需求，如团队内均认为需求不合理需要及时拒绝和提出意见给相关方 。
在对需求进行排期时 ，需要注意以下内容
1. 确定交付物形式/时间：和需求方确认 ，约定交付物的形式 、最终的交付时间 。如果需求较大要拆成几期交付 ，明确什么时间要交付哪些具体内容 。
2. 在风险解决后开始设计 ：在识别出的风险都被解决的情况下 ，才可以正式开始设计 ，并且要将沟通过程中的风险同步给上级和相关方 。
3. 聚焦可行的设计方向 ：如果需求方案在沟通前可能朝着 10 个方向发散 ，我们要在需求沟通后从十个方向中选出一个/多个方向聚焦，再评估出对应的排期 ，不要一股沿着 10 个方向发散。
4. 评判需求的优先级 ：如果有多个需求 ，如何评判需求的优先级呢 ？可以依据，该需求是否是今年核心策略和方向之一 ，依据投入产出比 ROI ，以及需求的紧急程度。
当我们后续在自己的团队内部同步这个需求时 ，要注意 ，尽管我们在需求调研阶段沟通了大量的内容 ，但我们并不需要把其中每个细节都事无巨细的同步到自己团队 ，尽可能简短的概述需求和自己做的重点事项 。
1. 描述问题时，简单直接 ："为了解决____场景的____用户的____问题" 。
2. 讲清楚需求要达到的目标 ，我通过何种推导过程 ，收集了什么资料 ，依据哪些分析结论 ，推导产出了怎样的方案 ，方案如何去达到这个目标 。
3. 同步预判出来的风险和风险的解决结果 。
以上就是需求沟通时可以考虑到的内容 ，当然并不是所有的需求都需要包括以上内容 ，可以根据需求的大小 、需求的影响面酌情进行选取。愿大家都能拥有高效的需求沟通过程 。
作者 ：飞向设计小岛
关注微信
