15 需求文档：为什么研发总吐槽需求写得不清楚？
你好，我是汤圆。今天给你分享一件B端体验设计师工作职责之外，但又非常重要的事：产品需求文档的对接。
在B端领域实际工作的过程中，设计师的上游通常都是产品经理。还有一些比较特别的情况，比如定制化产品，从0到1的探索性产品，也会直接对接商务、项目经理等不同的角色。
在这个过程中，由于B端的客户难以接触，并且大部分设计师都没有干过客户每天所干的业务，所以在理解需求上很容易出现一些偏差，甚至出现一些误解。这个问题如果不解决，不仅会直接影响到最终体验设计的质量，还会影响到后续开发的过程。
在产品从0到1的过程中，产品的开发成本是最高的。我大致计算过，产品经理的输出物主要是需求文档，是以文字信息呈现的内容，而设计师的输出物是图片和说明文档，开发工程师输出的是最终的代码。这三个环节的工作量基本是成倍上升的。也就是说，如果产品修改了一些需求，只需要花半小时修改一些文字，但研发可能就需要花上一天，甚至好几天去修改以前的内容。
如果产品需求没有描述清晰，那么就会给研发带来非常多的冗余工作，所以研发工程师就会非常严格地要求产品需求书写清楚。
而这与体验设计师又有什么关系呢？在B端产品的开发流程中，通常产品经理前期对接的不会是研发，而是体验设计师，所以，产出的需求文档，第一个关卡，也是过设计师这一关，如果设计师不关注需求文档写得是否清晰，那么就很容易和产品经理一起掉坑里，到了研发阶段都讲不清楚为什么要这么做，只能说“这是产品经理想要的”“这是老板想要的”，最后沦为了一个彻底的工具人。
那么，B端体验设计怎么解决这个问题呢? 这节课，我们就尝试向上游管理需求的清晰度，帮助你解决后续设计总是被动，研发同学也觉得自己干的事情没有价值的种种情况。这个过程，离不开产品的需求文档。
设计师该关注PRD的什么内容
PRD（Product requirements document 产品需求文档）在公司中通常是由产品经理来书写的，是设计师在开始设计工作前必须阅读和熟悉的需求内容。
大部分伙伴在对接PRD的时候，只专注在产品的需求上，很容易忽略这个产品为什么要这么做，想要达到什么目标。这就导致了设计的时候经常没有方向，设计完成后也讲不清这样设计为客户带来的价值有哪些。
我在对接需求文档的时候，通常会分为几个目标，分别是背景信息、需求的最终目标与对应价值、目标受众、以及相关功能的主要流程图（最好有以往的业务流程），如果条件允许，甚至可以请产品经理提供基础的原型和参考的产品功能介绍等信息。
这里给你一个大致的文档示意，可以参考。但你的核心任务还是要理解需要产品经理填写这些需求给我们的原因。
关于某个需求的背景信息
这部分最好需要产品经理提供这个需求产生的原因。比如明厨亮灶中，背景的描述有很多和我们前期3C分析中了解的案例相似，是描述餐饮卫生监管这个业务中以往人工执行的情况以及遇到的一些问题。
虽然我们3C分析中会收集到一些相关信息，但落地到具体某个功能需求上时，最好还是需要产品经理同步下这部分信息，有助于拉通产品、设计、研发三个不同团队对于这个项目的认知
关于需求的目标与价值
这部分是最重要的内容，是应该要求产品需求的提出人必须描述的部分。
一方面，因为企业中的项目大部分都是价值导向的，如果你不了解这个需求的价值，不了解它可以为客户的业务带来什么样的提升，那么在设计过程中，你很难有激情投入进去，更难以获得其他资源的支持，到了年终总结、个人作品集总结的时候，你也找不到自己做的工作价值到底在哪里。
另一方面，前面我分享过，B端有很多利益相关者，他们的需求是完全不同的，有很多客户自己都没有想清楚的需求，也就是常说的伪需求。这种情况下，产品经理或者提出需求的商务、项目经理很多时候也没有搞清楚价值在哪里，只是为了响应客户的诉求就提交了需求过来，但很有可能需求刚开始做了几天，客户又觉得不应该这样，提出修改需求，就很容易导致设计与研发资源浪费的情况。
更何况，一直只听客户要什么就做什么，这种被动响应的合作形式，很难在客户方建立起专业度。
所以， 一定要在需求文档中提出需要对方填写需求目标与价值信息的要求，这就可以在设计对接需求的环节管理上游的需求，让提出方更清晰地想明白自己要做的到底是什么。对于设计师来说，也可以基于这个目标和价值点去做更多的体验创意，而不是只做一个工具人，帮助画图就完事了。
关于功能针对的目标受众
在了解了背景与目标、价值后，接下来，就要了解一些具体的信息了。其中最重要的，是要了解目标受众具体是哪部分群体或者是否涉及客户公司组织的多个群体。
具体要了解到， 目标受众是管理层还是执行层，还是都要覆盖到 ？ 前面在 利益相关者分析 那节课里，我提到过B端的管理层、执行层对信息的偏好是很不同的。所以，如果你不了解这些功能具体是给谁的，那设计出来的产品很可能会被客户骂。
在进入研发环节之后更是这样。因为研发伙伴的工作量很大，所以不管是产品功能需求还是设计需求，有很多事情是希望尽量不做的。这就导致研发伙伴在对接设计需求的时候，就很容易质问你的体验设计内容为什么要这么做。如果你解答得不清晰，说不清楚功能是给什么客户做的，能带来什么价值，很容易就被研发说“设计需求没有讲清楚，先按简单的来做”，最后研发出来的效果就不是很好，甚至最后就不做了的情况也会经常出现。
在了解了目标受众之后，还必须了解目标受众的目的。而目标受众的目的，通常与前面提到的产品目标基本吻合，所以我们接着往下说 了解客户的具体行为 这件事。
这个步骤很关键，设计师要求上游的需求方提供客户行为的相关材料，其实就是在引导需求方与客户沟通，收集到具体业务的一些内部流程文件。这对于设计师与研发同事了解这个业务在使用B端产品之前的原有流程非常有帮助。如果涉及一些外部的资源和信息，都可以直观呈现、分享出来。避免闭门造车，甚至产品没有按客户的业务流程走，而是按研发伙伴的后台逻辑走的情况出现。
场景也是设计师与研发需要了解的重要信息。有些B端产品经常会在室外或光线较强的场景中使用，比如大家经常看到展会、机场的安检系统，这种场景下，如果系统设计成深色背景，客户在使用的时候体验就会非常糟糕，因为环境的强烈光线会导致屏幕根本看不清楚。我以前也掉过这类坑，后续改起来耗费了好几周的时间。
还有一种场景，就是很多客户使用的是Windows的笔记本电脑，有时候会没有鼠标。这种情况下，千万不要设计一些横滑查看更多内容的功能。因为这个功能只有Mac笔记本电脑能操作，设计师也许很熟悉，但Windows的触控板基本用不了横滑的功能，也会带来糟糕的体验。
其实，研发伙伴也需要了解使用场景的情况，因为这涉及客户现场的网络情况，这会对功能的研发性能提出更多的要求，在需求文档中描述清楚场景，有利于专业的设计师、研发伙伴去考虑、排查对应的情况，并且准备对应的解决方案。
最后，是了解媒介。 媒介指的就是客户操作这个功能用的实际物体。是手机，还是电脑？是1920的正常屏幕，还是超级长的大屏？同样一个功能需求，在手机上的体验设计方案、研发实现成本都完全不同。
而不同屏幕宽度也非常影响设计的内容与研发考虑适配的实现方案。例如我们做明厨亮灶的项目，有些政府的设备相对老旧一些，用的是以前的方形显示器，所以只能显示较少的内容，而一些相对先进的一些区域政府，甚至用上了曲面屏。所以媒介的不同，都是在对接需求时就要了解清楚的信息，不然就会给自己挖很多坑。
总结时刻
总结一下，研发吐槽需求提交得不清晰，是由两个大原因导致的，一部分是设计的需求没有提清晰，一部分是产品的需求不清晰。
设计需求的问题，在上节课分享的设计文档中已经解决了。而产品需求不清晰的问题，主要需要去了解需求的背景、需求的目标与价值，以及设计的目标受众，来帮助从设计对接产品需求这个环节去倒推上游，提供一些更清晰的价值和需求内容，让后面的设计与研发过程更加顺利。
特别是在目标受众中，哪些人会来用这个功能，他们各自的目标是什么，以前的业务行为是怎么样的，在什么场景中会使用以及用什么硬件使用，这5个内容都是非常影响体验设计与开发落地的，所以必须在对接需求的时候问清楚。
在课程的最后，我给你提供了一个需求对接的模板，你可以参考着使用，帮助你提前了解体验设计落地环节中与研发伙伴沟通可能遇到的相关挑战，保障好体验落地的效果，让客户真正用上优质体验的产品。
解惑B端体验设计
你认为B端产品从背景、目标与价值、人、目的、行为、场景、媒介这七个方面去呈现需求是否足够清晰呢？如果不够，你认为还应该补充什么？
欢迎你在留言区和我互动。如果觉得有所收获，也可以把课程分享给更多的朋友一起学习。我们下节课见！