老板微微一句的吐槽，我备受打击后的总结反思

编辑导语：两个项目都需要做实名认证这一板块的内容，而这个任务也都交由作者去完成，第二次技术评审时老板的一句吐槽，让作者写下了这篇总结反思，告诉大家作者走过的弯路有哪些，希望大家能够学习到经验！

一、故事背景

是这样，难产中的清结算项目（之前文章有专门介绍过，感兴趣的可查看我上一篇文章）即将上线，但是，半路杀出个活体检测实名认证的需求，也需要我负责。

活体检测需要用户做实名认证、清结算项目对接第三方支付公司亦需要做实名认证，我emo了，这2个实名认证，撞车了？真的撞车了，也是我的翻车经历，走了不少弯路。

第二次技术评审时，领导说了一句“这都第二次了，怎么还设计成这样”，破防了，对自己的自信心备受打击，我把自己的经历总结了一下，特此分享，可当故事看，也可引以为戒。

二、故事经历

接收到活体检测实名认证需求以后，把大厂的云能力以及价格做了个调研，大概了解了一下，开始着手做方案了，开启了自己的弯路旅程：

1. 弯路之一

最初，我参考了不少APP的设计文案与设计思路，最终了解定下我们的业务里面，活体实名认证的需求是对账号维度的身份认证（真人的维度），清结算的实名认证是对钱包账户维度的主体认证（交易主体：个人、企业），本来就是2件事情，那就分流程做，让用户自己触发活体检测的实名认证、自己触发清结算实名认证，于是就分化出来了不同情况的操作流程：

1. 用户已身份认证，要进行主体认证的流程。
2. 用户未身份认证，要进行主体认证的流程。
3. 用户未主体认证，要进行身份认证。
4. 用户已主体认证，要进行身份认证。

我吭哧吭哧把上面的场景需要原型、PRD基本都写完了，内部评审时，产品leader一下给否了，原因是，用户做身份认证时，默认同时进行清结算钱包账户的实名认证。我也把我的顾虑说了出来：

我：个人都可以进行身份认证，但并不是都会开通个人类型钱包账户，有的需要开通企业类型的钱包账户。

产品leader：需要开通企业钱包账户的用户就不用做活体实名认证了，到时候直接对接第三方支付公司，做公司主体认证。

我：emo，还以为所有账号都需要身份验证呢。

产品leader：清结算需要先上实名。

于是我按照产品leader的想法又开始第二稿的设计，开启了我的第二段弯路。

2. 弯路之二

我把活体实名认证和钱包实名认证盘在了一起，为了兼容钱包实名认证的企业类型用户，所以，用户活体实名认证的第一个关键页面，就是选择类型：

个人类型：可继续身份验证。

企业类型：提示文案，请前往PC…（APP端暂不做企业类型钱包账户注册）。

然后的然后，由于时间有限，直接开始了第一次技术评审。

评审会上，开始先讲活体实名认证，老板问企业类型干嘛用的？于是，我把“企业类型”列出来的原因解释了一下；

老板说：“活体实名和钱包开户不能糅杂在一起，需要把活体检测做成比较独立的模块，以后方便统一调用”，听完老板说的，我内心很是佩服，老板是搞技术的，一下就想到了未来技术的统一调用便捷性。

方案后面没法评了，因为方向和老板想法不一致，后面又大致把大厂的能力说了一下…老板也提了一下其他的意见，定下了要对接的大厂。

我以为，我的方向清晰了，就是把身份验证、钱包账户的主体认证分开呗，大致回到了第一版的设计，我承认，是我狂悖了。我回去把第一稿方案，大致改了一下，也自我感觉很清晰，很快又约了第二次技术评审。

第二次技术评审，先讲APP的钱包账户实名认证的功能，老板看到用户需要手工填写相关信息的页面，说道，怎么感觉还是这么复杂？需要用户手工填吗?

我：首先，证件OCR，某厂的对接方案里面，上传证件是必须的一步，但是，用户身边不一定都有证件，所以，就直接让用户手工录入。我翻出来了某厂的官微对接文档，老板看到了一个配置选项，那个选项就是根据业务实际情况后台传相关信息即可。还说道“这不是…这都第二次了，怎么还设计成这样”

其实我是了解过这个选项，舍弃了这个配置方案，因为，我们系统并不一定能拿到后台需要自动传递的用户信息。但是老板认为，活体检测都做了，肯定是可以拿到了。

这里划重点：老板默认钱包账户实实名的前置条件是，用户账号做完了身份验证。而我，对这个前置条件，一无所知，故此，钱包账户实名的流程，虽然清晰，却稍显复杂。

现场我补充道：若是可以通过账号的身份验证，获取到用户信息，那么我们钱包账户认证，若是个人类型，可以做个类似一键激活的方案，无需用户填写个人信息。

我继续讲下面的功能，绑定支付手机号，以及支付手机号的使用用途。

讲完，老板后面说了自己的想法，需要区分第三方支付公司的认证开户和我们业务的“开户”，需要把接口能力包装成体验好的用户流程，后台可以复杂一些…

最终，定下来，业务的钱包账户开户需要包括“钱包账户的认证+支付手机号绑定”。

终于，方向更清晰了，让用户的操作能省就省。

会后，我们部门老大也定了下调子，身份验证、钱包实名认证都要做成强制的。这个大方向，若是早些定更好，因为我前期也有设计，要在哪些业务节点添加验证逻辑，拦住用户。

三、故事结尾：优化方案出炉

基于前置条件用户账号做完了身份验证，且都是强制的。我觉得方案的设计难度降低很多，如下两个流程，相信大家看完也很容易理解：

APP身份认证流程

APP钱包账户开户流程

四、这次需求设计过程的个人所悟

第一，若需求之间看似有重叠的功能时，先确认前置条件，例如，这次活体实名和钱包账户实名的需求，个人活体身份验证是钱包账户实名的前置条件。

第二，当需求需要用户主动触发时，先确认（或再三确认）到底是强制的还是可跳过的？若是可跳过，需要再确认限制的业务逻辑，在哪个环节或操作节点拦住用户？

这两个点，真的特别影响需求的设计方案、设计难度，特此总结，并提醒自己引以为戒。

第三，一定要站在用户角度设计方案：到底怎么设计，用户的操作比较少，且比较顺畅？

例如，如我再专业一点，站在用户角度去设计，应该潜意识就知道“活体实名认证就应该是钱包账户实名的前置条件”，这个前置条件成立，用户的操作会相对便捷，就像流程图设计的那样。

第四，老板的吐槽，作为打工人，不能玻璃心，化吐槽为思考动力。需要洞悉老板吐槽背后的原因，理解老板说的建议，特别是搞技术的老板所提到的建议。

最后的最后，希望我踩过的坑，大家都能成功避开…

本文由 @Tania 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议