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

如果用户不使用你的“前置功能”，会产生什么问题呢？本文作者在设计产品的新功能时，想到了几个关于用户不使用“前置功能”时会产生的异常情况，并提出了相对应的解决方法，一起来看一下吧。

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

最近在设计产品的新功能，处于可行性分析和整体流程设计阶段。这个方案简单来说，分为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、用户远比我们想象的“脆弱”，他们爱上你的产品也许需要很多因素，但离开你的产品，也许只因为一个功能或细节，而往往我们缺少这方面的思考和觉察。

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

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