工作1年后,我对 B 端产品用户行为的理解

在用户视角下,细微理解用户行为。

最近一直在分模块复盘自己做过的项目,从流程上到了「用户行为」这部分,如下图。

在复盘前,我有查过一些文章,但都是在 C 端产品领域上做的分析,总结来说:

1. 用户行为 = 动机 + 能力 + 触发条件,动机:用户底层的诉求;能力:用户是否能做到,或者愿意做到;触发条件:触发行为的最后一根稻草。

2. 借助数据,通过用户行为事件、页面点击、路径、漏斗、健康指标等等的分析,观测用户的行为。借助观测的结果,做产品迭代上的理论支持。

以上这些分析思维和方式肯定是没问题的,但并不完全适用于 B 端产品。

接下来,我会从宏观和微观两个方面,谈谈自己对 B 端产品用户行为的理解,希望能对你有所启发。

一、业务驱动用户行为

就拿钉钉来说,里面的功能五花八门,可以说公司的很多业务流程都可以在上面完成。但作为个体的我们,真的都会用到吗?

肯定不是的。

除非是公司要求,否则一个人也无法在上面完成流程闭环,举个钉钉的例子。

1. 钉钉打卡

打卡,是钉钉的核心功能之一,管理员设置好打卡时间、地点等信息,员工到公司按时打卡上下班。

到了月底,人事会根据打卡数据,按公司要求判断是否要扣工资。

从 B 端产品的角度,做个简单的分析。

1)公司期望

管理员工上下班情况是否符合公司规章制度,为奖罚提供数据支持。

2)行为流程

管理员设置 → 员工打卡(上下班) → 管理员查看统计记录。

3)涉及角色

管理员(细分下会有统计人和监督人)、普通员工。自上而下来看,是公司需要管理,而钉钉能很好地满足这点,所以要求我们员工使用它。直白点,如果公司不要求员工打卡,谁会主动打卡呢?

如果公司说,我们换企业微信打卡,谁还会坚持用钉钉打卡呢?

回到一开始提到的 C 端产品用户行为模型:用户行为 = 动机 + 能力 + 触发条件,那么到了 B 端在这里,我们该如何理解呢?

套用的话肯定要重新理解这 3 要素。

  • 1. 动机:业务诉求,即公司经营想要解决什么问题。

  • 2. 能力:业务流程能否闭环,能否真正解决公司的问题。

  • 3. 触发条件:公司的规定。

从这 3 点来看,其实 B 端产品执行层的员工是没有话语权的。老板说好,那就是真的好。

2. 数据反馈和指导意义

既然 B 端产品的使用者都有点被“胁迫”的意思,那像是日活、留存、平均使用时长这些数据指标,观测起来意义就不大。

那我们重点应该怎么看数据呢?

既然 B 端产品都是业务流程,那肯定要是「线性」的分析方式。不用多说,用户行为路径分析和漏斗模型分析是最常见的。举个我的例子,之前我做的一个「创建事件」的功能,埋点如下图所示。

以上筛选的是从首页,到「创建事件」功能用户操作路径的埋点。根据埋点,在数据分析平台上做漏斗分析,如下图。

对于 B 端产品来说,每一步的转化率还是很低的,从 ROI(投入产出比)来看,并没有达到当时的预期。为此,后面也做过简单的分析了解。

结论是:并不是功能流程上的问题,而是客户没从内部要求员工使用起来。所以说,单纯的功能好、流程对是没有意义的,最终还是要了解客户真实的业务情况。

以上,就是我对 B 端产品用户行为的宏观理解。

二、用户视角体会用户行为

之前我做产品,满脑子想的是流程该怎么走,逻辑上应该怎么样。

现在回头看看自己设计的功能,真的不堪回首,也拿出来让大家瞅瞅。

1. 设置下的拍照水印开关

1)背景

客户管理要求督导在巡检门店时,要有自己的定位信息,证明他们确实是在目标门店巡检。同时,上传的图片也需要有「时间」和「定位」的信息,便于后期归档留证。

2)问题和目前的解决方案

我们 App 执行任务时虽然可以定位,但上传的图片没有对方要的「时间」和「定位」的信息。因此,他们只能通过水印相机拍好了之后,在通过我们的 App 上传图片。

3)解决方案

在得知这个问题简单分析后,我决定做「拍照水印」的设置,包含「时间」和「定位」。开启对应项后,拍摄的图片可以带时间、定位或二者都带。

4)我的问题

当时我下意识的认为,用户巡检一定是边拍照片边上传。而忽略了他们可能是整个巡检全部完成后,再统一上传图片。

其实简单的换位思考一下,这就跟出去旅游玩完后,再发朋友圈是一个道理。说实话,这就是办公室产品经理典型的“想当然”,归根究底的原因是:对业务场景不熟悉,没有跟着用户去现场实际上手操作。

百闻,百思,都不如实际一见。

2. 门店巡检后的整改行为

有了这段时间的经验之后,我在设计功能时会习惯多想。

  • 1. 谁会到这个页面?

  • 2. 他们来了之后,分别要做什么?

拿我最近在做的业务闭环来说,当督导巡检完门店之后,提交了报告,有谁会看这些报告?

  • 1. 管理者:看的不多,大多是抽着查看,或者直接看统计后的结果。

  • 2. 督导:如果巡检完之后有问题,会继续跟进直到问题解决。

  • 3. 店长:关注自己门店的违规情况,毕竟跟奖罚相关。

紧接着,再看看这 3 类角色针对「整改」,会采取怎样的行动。

  • 1. 管理者:这里怎么能有问题?不行,我得让店长改掉。此时管理者,需要「发起整改」让店长改进。

  • 2. 督导:检查之后,跟店长确认你这些地方都有问题昂,没冤枉你吧,抓紧时间改掉。此时督导,也需要「发起整改」让店长改进。当然,并不是所有的督导都会跟店长确认,也有可能直接对结果「发起整改」,不告知店长。

  • 3. 到了店长,会有两种情况:店我这里明明没问题,为什么让我改?不行我要「发起申诉」;这里我确实做的有问题,那我整改好了就提出「整改审核」吧。

以上,就是在用户视角下,细微理解用户行为得出的结论。

三、写在最后

说实话,B 端产品想要理解用户行为,最好的方式还是跟着用户跑。

比如我之前,有机会跟着客户去门店巡检,几趟下来发现了可多的问题。这可比在办公室光听、只想,效率要高的多。尤其是观察他们怎么用我们的 App ,这当中感受到的问题,更细节也更真实。

所以,也是应了那句话:“与其听用户说,不如看用户做。”

-END-

最近一直在分模块复盘自己做过的项目,从流程上到了「用户行为」这部分,如下图。

在复盘前,我有查过一些文章,但都是在 C 端产品领域上做的分析,总结来说:

1. 用户行为 = 动机 + 能力 + 触发条件,动机:用户底层的诉求;能力:用户是否能做到,或者愿意做到;触发条件:触发行为的最后一根稻草。

2. 借助数据,通过用户行为事件、页面点击、路径、漏斗、健康指标等等的分析,观测用户的行为。借助观测的结果,做产品迭代上的理论支持。

以上这些分析思维和方式肯定是没问题的,但并不完全适用于 B 端产品。

接下来,我会从宏观和微观两个方面,谈谈自己对 B 端产品用户行为的理解,希望能对你有所启发。

一、业务驱动用户行为

就拿钉钉来说,里面的功能五花八门,可以说公司的很多业务流程都可以在上面完成。但作为个体的我们,真的都会用到吗?

肯定不是的。

除非是公司要求,否则一个人也无法在上面完成流程闭环,举个钉钉的例子。

1. 钉钉打卡

打卡,是钉钉的核心功能之一,管理员设置好打卡时间、地点等信息,员工到公司按时打卡上下班。

到了月底,人事会根据打卡数据,按公司要求判断是否要扣工资。

从 B 端产品的角度,做个简单的分析。

1)公司期望

管理员工上下班情况是否符合公司规章制度,为奖罚提供数据支持。

2)行为流程

管理员设置 → 员工打卡(上下班) → 管理员查看统计记录。

3)涉及角色

管理员(细分下会有统计人和监督人)、普通员工。自上而下来看,是公司需要管理,而钉钉能很好地满足这点,所以要求我们员工使用它。直白点,如果公司不要求员工打卡,谁会主动打卡呢?

如果公司说,我们换企业微信打卡,谁还会坚持用钉钉打卡呢?

回到一开始提到的 C 端产品用户行为模型:用户行为 = 动机 + 能力 + 触发条件,那么到了 B 端在这里,我们该如何理解呢?

套用的话肯定要重新理解这 3 要素。

  • 1. 动机:业务诉求,即公司经营想要解决什么问题。

  • 2. 能力:业务流程能否闭环,能否真正解决公司的问题。

  • 3. 触发条件:公司的规定。

从这 3 点来看,其实 B 端产品执行层的员工是没有话语权的。老板说好,那就是真的好。

2. 数据反馈和指导意义

既然 B 端产品的使用者都有点被“胁迫”的意思,那像是日活、留存、平均使用时长这些数据指标,观测起来意义就不大。

那我们重点应该怎么看数据呢?

既然 B 端产品都是业务流程,那肯定要是「线性」的分析方式。不用多说,用户行为路径分析和漏斗模型分析是最常见的。举个我的例子,之前我做的一个「创建事件」的功能,埋点如下图所示。

以上筛选的是从首页,到「创建事件」功能用户操作路径的埋点。根据埋点,在数据分析平台上做漏斗分析,如下图。

对于 B 端产品来说,每一步的转化率还是很低的,从 ROI(投入产出比)来看,并没有达到当时的预期。为此,后面也做过简单的分析了解。

结论是:并不是功能流程上的问题,而是客户没从内部要求员工使用起来。所以说,单纯的功能好、流程对是没有意义的,最终还是要了解客户真实的业务情况。

以上,就是我对 B 端产品用户行为的宏观理解。

二、用户视角体会用户行为

之前我做产品,满脑子想的是流程该怎么走,逻辑上应该怎么样。

现在回头看看自己设计的功能,真的不堪回首,也拿出来让大家瞅瞅。

1. 设置下的拍照水印开关

1)背景

客户管理要求督导在巡检门店时,要有自己的定位信息,证明他们确实是在目标门店巡检。同时,上传的图片也需要有「时间」和「定位」的信息,便于后期归档留证。

2)问题和目前的解决方案

我们 App 执行任务时虽然可以定位,但上传的图片没有对方要的「时间」和「定位」的信息。因此,他们只能通过水印相机拍好了之后,在通过我们的 App 上传图片。

3)解决方案

在得知这个问题简单分析后,我决定做「拍照水印」的设置,包含「时间」和「定位」。开启对应项后,拍摄的图片可以带时间、定位或二者都带。

4)我的问题

当时我下意识的认为,用户巡检一定是边拍照片边上传。而忽略了他们可能是整个巡检全部完成后,再统一上传图片。

其实简单的换位思考一下,这就跟出去旅游玩完后,再发朋友圈是一个道理。说实话,这就是办公室产品经理典型的“想当然”,归根究底的原因是:对业务场景不熟悉,没有跟着用户去现场实际上手操作。

百闻,百思,都不如实际一见。

2. 门店巡检后的整改行为

有了这段时间的经验之后,我在设计功能时会习惯多想。

  • 1. 谁会到这个页面?

  • 2. 他们来了之后,分别要做什么?

拿我最近在做的业务闭环来说,当督导巡检完门店之后,提交了报告,有谁会看这些报告?

  • 1. 管理者:看的不多,大多是抽着查看,或者直接看统计后的结果。

  • 2. 督导:如果巡检完之后有问题,会继续跟进直到问题解决。

  • 3. 店长:关注自己门店的违规情况,毕竟跟奖罚相关。

紧接着,再看看这 3 类角色针对「整改」,会采取怎样的行动。

  • 1. 管理者:这里怎么能有问题?不行,我得让店长改掉。此时管理者,需要「发起整改」让店长改进。

  • 2. 督导:检查之后,跟店长确认你这些地方都有问题昂,没冤枉你吧,抓紧时间改掉。此时督导,也需要「发起整改」让店长改进。当然,并不是所有的督导都会跟店长确认,也有可能直接对结果「发起整改」,不告知店长。

  • 3. 到了店长,会有两种情况:店我这里明明没问题,为什么让我改?不行我要「发起申诉」;这里我确实做的有问题,那我整改好了就提出「整改审核」吧。

以上,就是在用户视角下,细微理解用户行为得出的结论。

三、写在最后

说实话,B 端产品想要理解用户行为,最好的方式还是跟着用户跑。

比如我之前,有机会跟着客户去门店巡检,几趟下来发现了可多的问题。这可比在办公室光听、只想,效率要高的多。尤其是观察他们怎么用我们的 App ,这当中感受到的问题,更细节也更真实。

所以,也是应了那句话:“与其听用户说,不如看用户做。”

-END-

发表评论

相关文章