如果用户不使用你的“前置功能”，会产生什么问题呢？本文作者在设计产品的新功能时，想到了几个关于用户不使用“前置功能”时会产生的异常情况，并提出了相对应的解决方法，一起来看一下吧。
大家好，今天分享一个最近工作中的小感悟，希望能对你有点帮助。
最近在设计产品的新功能，处于可行性分析和整体流程设计阶段。这个方案简单来说，分为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端泛金融产品，坚持“以实践验证理论，以输出倒逼成长”的目标。点滴珍贵，重在积累
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。