设计 / 产品

B端用研的一些现实

. 6 min read . Written by seki

不止一次听过关于“用研”的这套观点:“五个用户足以发现80%的可用性问题,所以我们找一个下午,请五个人去喝杯咖啡,就可以把用研这件事做成。”

表达过上述观点的人,包括曾经的我自己在内,有一个共同的特点:那就是他们几乎没有在实际工作中做成过“可用性测试”这件事(workshop、学校项目不算)。以我自己为例,迄今为止只成功组织过两次可用性测试,包括一次学校实践,即便勉强跑成,也难以被复用至其他工作中。

可用性测试的问题在哪里——别说招募五个用户,现实场景里,你想找到一个人来用用原型都十分困难,一杯咖啡就占用一个几乎陌生的社会人半小时时间,哪有这么好的事情?用研为啥会成为一个独立的岗位,因为这件事难做啊…

尤其是B端,关于B端产品设计的书基本都对“用户需求”这件事一笔带过,更不会提“用户研究”的实际案例,而是去描述“业务背景”、“设计模式”这些虚无缥缈的宏大叙事(B端体验设计的好书实在太少了)。这也从侧面反映了B端用研有多难以着手。

所以,坑还是得自己踩——

启发式评估、脑暴

“启发式评估(Heuristic Evaluation)”这个词翻译得非常晦涩,其实这件事很简单:让不直接涉及项目的设计师、产品、测试来评估一下自己的设计稿,用大白话说就是“请别人检查作业”。

这种“自省”式的方法在C端产品中或许很有效,但B端产品中是一件ROI很低的事情,因为设计师往往要花费大量时间理解业务…所以最后大部分时间都用在了“解释业务”这件事上面。

尝试过一次,当时我在评估前也通过“自查表”做了次自我检查,发现了一些问题,最后对比两个方法收集到的缺陷,两者几乎一致,所以我认为良好的自查流程已经足够完成“启发式评估”的工作。

头脑风暴同理。

体验量表

用问卷的形式让用户打分,这是一种定量分析的方式。

首先是用户数量的问题,B端用户数量太太太太少了,其次,回收率70%以上的问卷才能算合格,较大的用户数量和70%以上的回收率才能保证量表的可信度,有多少B端产品能解决这两个问题?前不久做了次腾讯云控制台的问卷,填完后返还代金券,腾讯云的用户量+足够有吸引力的收益或许能成功回收问卷。

另外,阿里云设计中心重做了一份量表,号称十几个样本就可以保真信度,我选择相信,但我投放的问卷至今没能成功回收过一份…

用户访谈

首先,这是最常用的用研方法(对于设计师),其次,这件事在B端能做成,洞察出一些结果。

不过用户访谈经常会出现这种情况——

用户:“这里我觉得需要一个xx功能。”

我:“你们在这里会做什么事,能说下过程吗?”

用户:“我觉得有xx功能就会很好,旧版就有这个功能,不能加么?”

我:“额,可以加,但我们想看看有没有更好的方案”

用户:“这就是最好的方案!”

上述用户显然是一位很主观很有想法的人,这样的用户实际上不适合作为用研对象。但依然有这么一些人,他们会乐意分享自己看法,又不会带入太多主观意见,他们就是B端用研的关键点——要做好B端用研,就要发现并培养这些种子用户。

当有了一批忠实的种子用户(在B端太难了)后,可用性测试也就可以顺理成章的进行了。

前端埋点/数据分析

先说结论:这也是一件较容易做成,并洞察出结论的事。

B端的数据分析和C有些不一样,因此你在网上看到的“数分方法论”往往派不上用场,B端没有太多“洞察行业”、“预测趋势”这样宏大的诉求,用户数量也不够大,so…

不用去考虑太多“漏斗模型”、“7日留存”。B端用研更像早期的“服务器日志分析”方法,埋好每个页面、每个控件的使用情况,确定用户信息,就足够洞察出一些结果了。

这个方法的难点在于怎么说服业务方去做,毕竟有一定开发成本,数据能不能到你手上也是个问题。

被动反馈(Feedback工具)

这里有很多现成的APP,比如hotjar、腾讯兔小巢。

不论你做或者不做,用户总是要提issue,但是有个集中的地方,可以更好管理这些反馈。

被动反馈很容易做,但是参考价值十分有限——专家型用户更乐意提反馈,最后变成一个“专家型需求收集中心”,所以应该思考怎么降低Feedback的门槛,理想情况是让所有类型的用户都能很容易的提上一嘴意见。

文献调查

调研恐怕才是最重要的事情,而且也是“一定会做”的事,用研反而只是个可选项——文献调查就是竞品分析&理解业务本身嘛。

总结:

  • 培养种子用户最为重要
  • 数据埋点有用
  • 理解业务为先

对于那些“难以做成”的方法,我还会继续尝试。