B端设计中，没有真实用户该怎么办？

在 B 端产品研发过程中，有真实用户可以与我们交互，是非常重要的。虽说有些 B 端产品我们自己也是用户之一，或者因为我们对此领域颇为了解，我们也可以猜测产品是如何运作的，但只有真实的用户对产品的帮助才会更大。

新人如何做好用户研究？我总结了4个关键知识点！

作为一名 B 端用户体验设计师，你是否经历如下困境：客户与公司的商务售前进行沟通，客户的痛点和建议会传达给产品经理，产品需求明确后，做出原型图给到设计师。

不幸的是，对于 B 端产品来说，要获取用户非常难。当一个系统有多角色时，要获取用户就更难上加难了。因此，很多时候，产品团队只能通过碎片化的竞品参考与自我经验拓展的方式，来捕获用户需求，进而转化为产品需求，来完成系统设计与研发。

还有一种情况，不知道你身上有没有发生过，在我身上发生过，模拟案例如下：

一上班就被钉钉，一聊说是客户管理层提过来的需求，要快速解决。

那是个啥问题呢？

据说管理层中有一名老板，年龄比较大了，看不清目前系统上的字体，希望系统字体能变大一些。

那我就问同事了：

为什么会看不清字体？会不会是电脑设置问题，还是其他。

希望字体变大？是希望字体多大？

页面这么多，哪些页面是领导用的，是否可以对这些页面字体先变大？

“字体变大”背后隐藏了一堆需要挖掘的问题，现在没办法开做。

……

同事说：“这我就不知道了，我也是一层层反馈过来的，现在需要你们改字体大小，给出解决方案。”

我：“……？？”

看到这里，我想你也知道，这种情况是很难接触到用户的，特别是管理层用户。那要怎么办呢？需求不清晰，就没法分解为任务去执行，这活就干不下去了。于是我通过设定「用户代理」，来完成对问题的挖掘。

那什么是「用户代理」呢？

原来我也没给这种方式取这么个名字，而且感觉这种方式其实是不推崇的。直到我看到了《敏捷软件开发》一书中有描述到「用户代理」一词，我才发现，其实我们很多时刻，已经用到了「用户代理」的方式在获取用户需求。

在《敏捷软件开发》中提到：“我们期望和尽可能多的用户沟通，这些用户代表了产品的不同视角，当我们无法直接和他们接触时，我们需要求助于用户代理，他们本身可能不是用户，但是在项目里他们能够代表用户。”

你看了这些话，是不是觉得打开了自己做产品时找不到用户的困境，感觉终于有方法可以离用户真实需求更进一步了。

是的，我看到此番话时，也是这么感觉得，简直是救命稻草呀。接着书中又说：“选择合适的用户代理对项目的成功至关重要。必须考虑用户代理的背景和可能的动机。具有营销背景的用户代理和领域专家的用户代理处理用户需求的方式会存在差异，而了解这些差异很重要。”

看来，用户代理并不是随意选择的，尽量要合适中再筛选合适的。例如，你要构建一个项目管理系统，你找使用项目管理系统用户的主管比找购买项目管理系统的 IT 主管就来的合适。但要是你为基金公司研发一款投资交易类系统，你找 IT 主管作为对接人帮你去获取用户需求，就比你问一个 C 端用户是怎么做投资交易的，就会来的合适些。

可见，虽然「用户代理」可以帮助我们解决无法直接接触用户的难题，但如何选取合适的「用户代理」，也是需要方法的。书中讲了一些用户代理，但不全部适用于 B 端，我对照此总结了一些合适 B 端的用户代理类型（当然，不同的产品又会生产差异）。

用户的主管

定义：使用软件的用户的直接主管。

优点：虽然主管不是软件的高频使用用户（且使用模式与用户也不相同），或者压根不使用软件，但他们是距离用户最近的人，让其成为用户代理，可以帮助我们高效收集用户需求。并且通过日常观察，也可以对用户使用软件的情况进行总结与分析。

缺点：但因为主管日常比较忙，或者是由于在使用软件上，主管目标与实际用户目标不相同，可他又认为自己是了解用户需求的，甚至比用户本身了解的更清新，因此会导致对实际用户需求表述不准确，经常出现在用户原始需求基础上进行增删改的情况，这就需要我们去甄别。

研发工程师

定义：研发目标软件的工程师。

优点：由于研发工程师在目标软件上有了较为深的研发经验，因此他们对业务的了解是非常清晰的，基于此，他们要是有机会和用户沟通，那么不太存在沟通障碍，至少知晓对方在说什么。

缺点：但由于研发工程师的岗位属性关系，导致他们更关注技术层面的问题，不一定能对用户所述进行很好的转译，这就需要我们对自己选定的研发工程师先进行沟通，让他们知道我们要什么，如何去获取。

售前与销售

定义：售前和销售实际上是不太相同的，但由于他们跑在一线都能接触到客户方，且在一些公司销售与售前不分家，因此我就放一起了。

优点：他们通常有机会接触到客户，那么为了将产品做好，也可以进一步试试是否可以接触到用户。通常他们对产品较为了解，至少对这个行业这类型产品是了如指掌的，那么就可以与用户进行深入沟通。

缺点：售前与销售都有自己的 KPI 考核指标，因此就怕他们会加入对他们友好的销售性功能，从而偏离了初心。

相仿用户

定义：相仿用户是指同样使用该类型产品的用户，例如使用云效与 teambition 的用户是类似的，使用 ONES 和 jira 的用户是类似的。若 X 软件是我们生产的，但我们无法接触到自己的用户，可是能接触到 Y 软件用户（假设 X 与 Y 是同赛道软件），那么我们可以找 Y 用户进行调研。

优点：撇去用户的喜好、经验、经历等要素，相对来说，与其没有用户，不如有相仿用户。我们可以对相仿用户进行调研，从而获取一些有效信息（至少不是自己臆想出来的信息）。

缺点：相仿用户的喜好、经验、经历若我们完全无视，也不可能，毕竟一个人的曾经会影响他今后的思考与判断。那么，若他是 Y 用户，他给出的需求其实是来自对 Y 的体验的，因此，我们需要在这些需求中，甄别出对自身产品有效的需求。

业务分析师

定义：钻研软件业务，对软件业务极其精通的人。

优点：业务分析师通常比产品经理还懂业务，因此，若他们可以成为用户代理，为用户发声，来表达用户在使用该软件时的所需，也是很不错的。我之前和其他部门一位业务分析师交流过（现在是资深业务专家了），由于其曾经一直和用户打交道，因此相对比较了解用户，他们的软件需求有部分都是直接来自于他。

缺点：懂业务即是优点也是缺点，由于其认为团队中没有比他更懂业务和用户了，导致在某些需求决策上，他会非常相信自己的判断，认为无需和用户沟通，但这是大忌。

领域专家

定义：领域专家是指在某软件领域很有发言权的人，对此软件领域他很了解。他可以是高级用户、也可以是资深领域研发专家、业务专家、设计专家等。

优点：专家长期在该领域内研究和工作，对软件的一些需求会比较懂，能提出自己的意见。

缺点：但因为他们实在太资深了，他们给出的用户需求通常会非常专业，但这往往是用户不需要的。

最后的话

除了以上用户代理类型，你也可以进行补充。

我们可以发现，不同的用户代理类型，各有优劣。

虽然我们可以使用用户代理来帮助我们走出无用户的困境。

但拥有真实的用户一定比用户代理来的更合适。

用户代理是退而求其次的方式。