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

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

一、故事背景

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

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

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

二、故事▥经历

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

1. 弯路之一

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

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

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

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

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

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

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

….

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

2. 弯路之二

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

个人类型Κ:੝可继续身份验证。

企业类型:提示文案,请前往PC…(APP端暂不做企业类型钱包账户注册)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

APⓖP身份认证流程

APP钱包账户开户流程

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

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

Ξ

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

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

Ζ

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

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

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

§

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

 

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

题图来自 Unsplash,基于CC0协议

Leave a comment

Your email address will not be published.