工作1年后，我对B端产品用户行为有了新的理解
最近一直在分模块复盘自己做过的项目，从流程上到了「用户行为」这部分，如下图。
在复盘前，我有查过一些文章，但都是在 C 端产品领域上做的分析，总结来说：
- 用户行为 = 动机 + 能力 + 触发条件，动机：用户底层的诉求；能力：用户是否能做到，或者愿意做到；触发条件：触发行为的最后一根稻草。
- 借助数据，通过用户行为事件、页面点击、路径、漏斗、健康指标等等的分析，观测用户的行为。借助观测的结果，做产品迭代上的理论支持。
以上这些分析思维和方式肯定是没问题的，但并不完全适用于 B 端产品。
接下来，我会从宏观和微观两个方面，谈谈自己对 B 端产品用户行为的理解，希望能对你有所启发。
一、业务驱动用户行为
就拿钉钉来说，里面的功能五花八门，可以说公司的很多业务流程都可以在上面完成。但作为个体的我们，真的都会用到吗？
肯定不是的。
除非是公司要求，否则一个人也无法在上面完成流程闭环，举个钉钉的例子。
1. 钉钉打卡
打卡，是钉钉的核心功能之一，管理员设置好打卡时间、地点等信息，员工到公司按时打卡上下班。
到了月底，人事会根据打卡数据，按公司要求判断是否要扣工资。
从 B 端产品的角度，做个简单的分析。
1）公司期望
管理员工上下班情况是否符合公司规章制度，为奖罚提供数据支持。
2）行为流程
管理员设置 → 员工打卡（上下班） → 管理员查看统计记录。
3）涉及角色
管理员（细分下会有统计人和监督人）、普通员工。自上而下来看，是公司需要管理，而钉钉能很好地满足这点，所以要求我们员工使用它。直白点，如果公司不要求员工打卡，谁会主动打卡呢？
如果公司说，我们换企业微信打卡，谁还会坚持用钉钉打卡呢？
回到一开始提到的 C 端产品用户行为模型：用户行为 = 动机 + 能力 + 触发条件，那么到了 B 端在这里，我们该如何理解呢？
套用的话肯定要重新理解这 3 要素。
- 动机：业务诉求，即公司经营想要解决什么问题。
- 能力：业务流程能否闭环，能否真正解决公司的问题。
- 触发条件：公司的规定。
从这 3 点来看，其实 B 端产品执行层的员工是没有话语权的。老板说好，那就是真的好。
2. 数据反馈和指导意义
既然 B 端产品的使用者都有点被“胁迫”的意思，那像是日活、留存、平均使用时长这些数据指标，观测起来意义就不大。
那我们重点应该怎么看数据呢？
既然 B 端产品都是业务流程，那肯定要是「线性」的分析方式。不用多说，用户行为路径分析和漏斗模型分析是最常见的。举个我的例子，之前我做的一个「创建事件」的功能，埋点如下图所示。
以上筛选的是从首页，到「创建事件」功能用户操作路径的埋点。根据埋点，在数据分析平台上做漏斗分析，如下图。
对于 B 端产品来说，每一步的转化率还是很低的，从 ROI（投入产出比）来看，并没有达到当时的预期。为此，后面也做过简单的分析了解。
结论是：并不是功能流程上的问题，而是客户没从内部要求员工使用起来。所以说，单纯的功能好、流程对是没有意义的，最终还是要了解客户真实的业务情况。
以上，就是我对 B 端产品用户行为的宏观理解。
二、用户视角体会用户行为
之前我做产品，满脑子想的是流程该怎么走，逻辑上应该怎么样。
现在回头看看自己设计的功能，真的不堪回首，也拿出来让大家瞅瞅。
1. 设置下的拍照水印开关
1）背景
客户管理要求督导在巡检门店时，要有自己的定位信息，证明他们确实是在目标门店巡检。同时，上传的图片也需要有「时间」和「定位」的信息，便于后期归档留证。
2）问题和目前的解决方案
我们 App 执行任务时虽然可以定位，但上传的图片没有对方要的「时间」和「定位」的信息。因此，他们只能通过水印相机拍好了之后，在通过我们的 App 上传图片。
3）解决方案
在得知这个问题简单分析后，我决定做「拍照水印」的设置，包含「时间」和「定位」。开启对应项后，拍摄的图片可以带时间、定位或二者都带。
4）我的问题
当时我下意识的认为，用户巡检一定是边拍照片边上传。而忽略了他们可能是整个巡检全部完成后，再统一上传图片。
其实简单的换位思考一下，这就跟出去旅游玩完后，再发朋友圈是一个道理。说实话，这就是办公室产品经理典型的“想当然”，归根究底的原因是：对业务场景不熟悉，没有跟着用户去现场实际上手操作。
百闻，百思，都不如实际一见。
2. 门店巡检后的整改行为
有了这段时间的经验之后，我在设计功能时会习惯多想。
- 谁会到这个页面？
- 他们来了之后，分别要做什么？
拿我最近在做的业务闭环来说，当督导巡检完门店之后，提交了报告，有谁会看这些报告？
- 管理者：看的不多，大多是抽着查看，或者直接看统计后的结果。
- 督导：如果巡检完之后有问题，会继续跟进直到问题解决。
- 店长：关注自己门店的违规情况，毕竟跟奖罚相关。
紧接着，再看看这 3 类角色针对「整改」，会采取怎样的行动。
- 管理者：这里怎么能有问题？不行，我得让店长改掉。此时管理者，需要「发起整改」让店长改进。
- 督导：检查之后，跟店长确认你这些地方都有问题昂，没冤枉你吧，抓紧时间改掉。此时督导，也需要「发起整改」让店长改进。当然，并不是所有的督导都会跟店长确认，也有可能直接对结果「发起整改」，不告知店长。
- 到了店长，会有两种情况：店我这里明明没问题，为什么让我改？不行我要「发起申诉」；这里我确实做的有问题，那我整改好了就提出「整改审核」吧。
以上，就是在用户视角下，细微理解用户行为得出的结论。
三、写在最后
说实话，B 端产品想要理解用户行为，最好的方式还是跟着用户跑。
比如我之前，有机会跟着客户去门店巡检，几趟下来发现了可多的问题。这可比在办公室光听、只想，效率要高的多。尤其是观察他们怎么用我们的 App ，这当中感受到的问题，更细节也更真实。
所以，也是应了那句话：“与其听用户说，不如看用户做。”
作者：空；公众号：小木盒产品记
本文作者 @空
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
