如果用户不使用你的“前置功能”,会怎么样?

大家好,今天分享一个最近工作中的小感悟,希望能对你有点帮助。

最近在设计产品的新功能,处于可行性分析和整体流程设计阶段。这个方案简单来说,分为A、B两类用户,而两者之间也存在业务关系。

大致流程为A做前半部分,B做后半部分。

我们通过一系列的分析,大致设计出一套可行的业务流程,在我思考下一步执行方案时,突然想到了几个异常情况。这几个异常情况归根结底都是一个原因:用户不使用你提供的“前置功能”。

  • 比如A的操作分为1、2、3、4,四个步骤,B的操作分为5、6、7、8四个步骤,正常按照流程设计从1-8没有问题,但如果A不愿意配合呢?B应该怎么办?
  • 或者如果A只想从第三步开始做,如果前面两步的产出数据缺失,第三步如何发起?
  • 再比如,从A到B之间,存在一个业务数据的连接,如果这个数据,A没有按照平台的要求上送怎么办?B能区分清楚吗?

发现这几个问题之后,很多朋友会顺着这个思路寻找解决方案,这没有问题。只不过,我想表达的是,问题的背后还蕴藏着哪些我们值得发掘的信息?(当然也有很多朋友缺少对于这类异常场景的思考,那就要提升自己的结构化分析能力)。

有人可能会问,现在处于可行性分析阶段,有必要考虑这么多异常场景吗?

我的观点是,相对细节的异常可以不考虑,但是这类“阻碍性”的异常一定要思考。因为阻碍性的异常,如果不能妥善解决,容易让整个方案的可行性画上问号。

针对上述的几类问题,我们可以采用数据导入、数据补录之类的方式来解决,也可以为B提供前期的1、2、3、4功能。但这样解决之后,业务的连贯性是否还能得到保障?用户的操作是否会变复杂?B是否有意愿去完成A的缺失操作?这些问题都是我们需要调研和思考的。

顺着这几个问题,我建议再往后思考一步:用户为什么不愿意使用你的“前置功能”?

我们以A没有按照平台要求向B上送数据为例。这个场景正常流程是A向B转一笔账,由B协助A进行处理,而且A转多少钱,B就处理多少钱。

但实际场景中,A转账的金额可能会超过实际需要处理的金额。比如转账1w,但实际仅需要B处理9k,剩下的1k是A给B支付的服务费。按照平台的逻辑,A不应该转账1w,应该按9k进行操作,另外的1k服务费要线下解决。因为系统无法区分这1w的用途,只能视为全额处理。

但A为什么不分两次转账?

因为A这样操作习惯了,他平时就是汇总转账,由B自己来区分。现在平台新功能上线了,需要A按照平台的规范将一笔分为两笔,A不乐意。

用户就是这么脆弱,也许对于我们而言,这个转变似乎很简单,只是多操作了一次罢了。但对于用户而言,这是增加了他的负担,他不愿意改变,我觉得以前的方法挺好的。你的系统要帮我拆开。

最后的结果是,我们增加了这个金额拆分的功能。功能其实不复杂,只是如果没有参与用户调研,这个需求是很难发现的,产品经理不会自然而然的想到这一步。

最后,这个场景背后还涉及到一个问题:系统到底是给用户提效,还是降效?

我举的例子只是个例,但这些个例的背后却反映着现如今数字化转型过程中的困境:数字化转型的口号是为了“降本增效”,但实际上我们的产品、我们的功能真的可以为每类用户提高效率吗?

我们每个人所负责的业务都不相同,面向的用户也千差万别,今天的分享,因为特定场景的原因,我不能说的太具体,采用了比较含糊的举例。但是我希望有幸读到这里的同行可以透过含糊的场景,理解我的用意:

1、不要忘记分析关键的异常场景。每个功能(尤其是核心功能)都要思考用户是否会按照我们的设想来操作。如果答案是否定的,那我们应该怎么做?

2、你设计的功能到底能不能真的解决用户的问题?是否真的让用户方便了?如果不能,下一步应该怎么办?

3、用户的反馈,是否真的通用化?是否真的可以以功能的形式做到产品上?如果不能,如何解决这部分用户的实际诉求?

4、用户远比我们想象的“脆弱”,他们爱上你的产品也许需要很多因素,但离开你的产品,也许只因为一个功能或细节,而往往我们缺少这方面的思考和觉察。

这几个问题没有标准答案,需要我们在日常工作中提升意识,努力探索。

希望,我们很快都能找到一些答案,让自己的方案更合理,产品更有价值。

作者

不想延期,公众号:不想延期。半路转行的B端泛金融产品,坚持“以实践验证理论,以输出倒逼成长”的目标。点滴珍贵,重在积累

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部