在设计师的普遍认知里，
甲方和乙方的关系似乎一直都不大和谐。
对于B端行业设计师来说，
不光有甲方和乙方，还有个丙方。
也就是设计师、客户、用户，
所以他们的关系更加复杂。
寻弥，
我们团队的5年B端行业设计师老大哥。
靠着他的同理心和洞察力，
在这些复杂的人物关系里，
化解其中的障碍和矛盾～
项目中如何区分用户和客户？
用户，就是直接使用最终产品和服务的人或者是组织，这个产品和服务不一定是自己花钱买的，有可能是赠送的，有可能是工作配给必须使用的。
客户，就是掏钱购买产品和服务的人或者是组织，客户不一定是产品或服务的使用者，但是一定是为这项产品或服务支出费用的人。
人员角色似乎并不复杂，困难的是你必须得同时服务好客户和用户，而且用户和客户有可能是同一个人，有可能不是同一个人，有可能是个人，有可能是企业或组织，你的方案要照顾好每一个角色的需求，才是一个好的产品设计。
客户需求与用户需求的差异是什么？
客户和最终使用的用户往往是两类人群，他们的立场，价值认同，角色等方面的不同，导致在同一个项目中给到设计师或者pd等服务人员的信息输入会有很多不同点，甚至有些方面会产生完全相反的两个方向。
举一个很具体的🌰。
在电力抢修中场景中，抢修过程中很容易因为操作不规范导致人员伤亡，因此对抢修人员的安全操作流程要求很严苛，抢修人员在执行操作之前需要填一个安全操作流程表单，例如：第一步拉开哪个闸，第二步拉开哪个闸门，可能多达20多步，填写完成之后还要进行一遍操作流程的预演，并且要全程录制音视频备案。
-抢修人员常见的工作场景（难以空出双手用手机去完成复杂操作）
针对这个场景，客户目标是之后所有的工作流都搬到线上，通过一些智能化、数据化的手段，让业务运转的效率更高，成本更低，尽量减少人工的操作。
于是，针对这一需求，我们对一线业务人员进行了调研，几乎都是警觉和排斥的情绪，他们t提出线上操作对一线抢修人员来说，这非常是不符合他们使用习惯的，业务人员更习惯在线下手工填写表单，在手机一个小的屏幕上去填这个单子，冗长的文字输入，十多步的操作对于正在进行抢修的业务人员来说是明显不适应的！
-中压抢修中的抢修人员需要填写的部分表单
设计师如何平衡客户需求与用户需求之间的矛盾？
一线调研之后我们内部判断这部分工作的线上化，反而增加了用户的使用负担，并且自以为客户之所以想要把这部分工作线上化，可能是需要一个系统可查的数字化单据存档，方便线上随时抽查抢修工作是否合规，实现安全工作流程的线上化监督。
为此，我们为了“平衡客户的需求和用户的使用习惯”，还是想让用户线下填写，通过拍照文字识别转成电子化的工作表单，再上传到系统进行备份。这样既能保证客户在线化管理的需求，又不增加业务人员的使用负担。
但是，当我们给客户拿出这套方案后，客户的反馈是：“你们没有了解到这个需求背后的思考。”
第一点，安全工作流程的智能化推荐。
客户目标是，表单的电子化只是第一步，当这些数据收集多了之后，通过对积累的这些工作表单数据的学习和分析之后，最终实现安全工作流程的智能化推荐，到那时只要知道损坏的设备系统就能自动推荐修复方案和安全的工作流程，不再需要业务人员自行判断和填写相关内容，而为了实现这个长远目标，现在短时间的体验的损耗是必要的。
第二点，线上化实时监督保障抢修人员的安全。
中压抢修过程中的工作流程不合规是导致人员伤亡和损失的主要原因，现有的线下工作表单的模式有监管漏洞，需要线上化的方式进行实时的监督，也方便后期的随时抽验，本身是为了保障抢修人员的安全。
-现有抢修流程中安全操作表单只需要抢修人员线下纸质填写作为抢修工作记录，很难起到安全作业规范监督的作用。
第三点，线上化填写可以通过语音录入来完成。
因为现场工作环境以及戴手套作业的原因，字写的特别草，文件管理障碍很大，技术也很难识别，但是线上化的填写可以通过语音录入来完成。
这是一个非常典型的客户需求与用户需求完全相反的项目。
-抢修人员已养成在抢修过程中使用手机查询抢修相关资料，进行组员沟通的习惯，通过语音进行表单内容填写是可行方案。
那作为设计师，我们是不是就可以不需要考虑用户的诉求了？毕竟付钱的是客户呀～
答案当然是否定的！
在一些宏观目标前，客户的需求难以避免会打破现有用户的某些工作习惯，牺牲掉一些现有用户的使用体验，但是作为设计师，我们还是要尝试去站在一线用户的视角，去通过其他方式尽量减轻这部分改变对他们造成的负面影响。
在上述理解到客户真正用意之后，我们提出了分阶段的推进线上化的方案。
第一个阶段，一线人员在抢修过程中依然沿用传统线下填写表单的方式，电子表单可以抢修完成后补交。然后到第二个第三个阶段，等待用户慢慢适应逐渐优化，逐步过渡到完全线上填写。
-鉴于抢修现场复杂危险的作业环境（高空作业，带电作业，恶劣气象等），对抢修人员的作业流程进行严格的安全流程监管十分必要。
客户给出的需求肯定是对自身业务有价值的，但不一定是真正对那用户是最友好的或最有价值的需求。客户的需求里除了通过业务的专业思考产出的需求外，也可能掺杂着一些自己的主观喜好，需要设计师和产品经理一起去做分析，尽量剥离掉与个人喜好相关的不合理需求。 另外一个客观现实是，客户这边很多制定目标和需求的人员已经脱离一线的工作人员和工作很久了，他们站在专业角度提出的一些需求也需要我们通过一线的调研和访谈工作去验证。
作为设计的思考
理清项目复杂需求的真面目，是设计成功的关键所在
需求分析若处理不好，会导致误解、挫折、障碍以及潜在的项目延期风险。因此，需求分析奠定了产品设计的基础。像上面电力这个案例中客户及用户提出的不同需求像“雾里看花”般模糊很容易令设计师感到困惑。
我们首先要做的就是拨开迷雾，理清需求的具体内容：
业务（客户）需求：反映了组织或客户对系统、产品高层次的目标要求；
用户需求： 用户使用产品必须要完成的任务。通常可以通过对用户的访谈和调研来绘制用户画像以及用户的任务流程，通过分析发掘用户具体诉求；
功能需求：定义了产品必须具备的软件功能，使用户利用产品或系统能够完成他们的任务，从而最终满足业务需求；
非功能性需求： 指产品为满足业务需求所必须具有的除功能需求以外的特性，包括安全性、可靠性、易操作性等。
-可以通过对业务全流程的调研梳理，将参与其中的所有角色的具体工作和遇到的痛点及需求进行收集和梳理，站在业务全景的视角上对所有需求进行划分归类。
业务需求的核心是能否解决问题，能否提高效率，而且这类产品在使用上具有强制性，所以业务需求出发的功能比用户体验更重要。在这种情况下产品是为客户的业务需求服务的，而不是需要产品来引导需求，只有客户需要的和我们提供的几乎是百分之百匹配的时候，客户才会付费，比如我就要一个螺丝钉，你正好能提供，我就愿意花钱购买。因此设计师并不要在这点上太较真体验的细节。
业务需求有多种实现路径，选择对用户最友好的路径
客户业务需求是一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能直接转化为产品的功能需求，还需要用户需求为功能和体验设计提供具体的决策依据和细节。
用户需求，必须从使用产品的用户处收集，他们清楚要使用该产品完成什么任务。因此当业务需求和用户需求产生冲突时，设计师需要通过其他方式尽量减轻这部分改变对他们造成的负面影响。
不要让客户代替用户说话
客户有时试图代替实际用户说话，但通常他们无法客观准确的描述“用户需求”。用户需求必须来自产品的真正使用者，必须通过一线的调研和访谈工作让实际用户参与到收集需求的过程中。客户的需求里除了通过业务的专业思考产出的需求外，也可能掺杂着一些自己的主观喜好和判断，需要设计师和产品经理一起去做分析，尽量剥离掉与业务目标无关的不合理需求。
最后，我想说的是👇
不要质疑你的客户不懂业务，他们都是10年老兵，也不要怀疑你的用户不懂产品，他们才是一线的使用者，只是你们没有站在一个角度看问题。作为设计师我们需要深入一线，洞察他们行为背后的本质，提供真正的设计价值。
About us
不设限，不追随，不为设计为未来
我们是阿里云设计中心
若有收获，就点个赞吧
0 人点赞
