一款在线还款记账产品诞生实战

1. 前言

现在我们基本上大多数人每个月都有各种需要还款的账单,要么是房贷,要么是信用卡。对于我自己,信用卡也比较多,每个月要还房贷,还信用卡,为了防止漏还,还专门做了一个Excel进行记录。之前和几个朋友吃饭聊天,发现有朋友也在用Excel记录每个月的还款。

像我这样的用Excel记录每月还款,应该也有不少。使用Excel记录,在PC上操作比较方便,显示屏幕大,信息显示直观,操作比较方便。不过在移动端上操作,就不是很便捷。心里就想,要不要自己也做一个在移动端使用的账单还款助手。可以方便大家在移动端记录每个月账单的还款,防止漏还款逾期造成的逾期风险。市面上有这种功能的产品有很多,都是好几个团队协作完成的。

个人做一个账单还款记账的产品好实现吗?我们可以尝试一下。每个人都可以当一次产品经理,借此实战,和大家分享一下产品实现的一些方法论。

2. BRD之竞品分析

我们都知道,产品经理涉及的三大产品文档,分别是BRD(Business Requirement Document,商业需求文档)、MRD(Market Requirement Document,市场需求文档)和PRD(Product Requirement Document,产品需求文档)。

一般而言,BRD是基于商业目标或价值所描述的产品需求内容文档。类似于我们软件工程中所提到的可行性分析。你计划设计的产品在投入研发之前,为企业高层提供决策评估的依据。如果大家要做创业计划书,BRD也是很重要的一个部分,一般会涉及市场分析,销售策略,盈利预测。BRD通常是供决策层们讨论的演示文档,一般比较短小精炼,没有太多的产品细节。说的直白一点,就是这款产品值不值的做。

产品经理在进行产品设计前,最重要的就是进行竞品分析。通过竞品分析,你可以更清晰的理解自己产品的价值主张,对方的产品优势与劣势有哪些,自己将要做的产品同竞品的差异点有哪些?自己产品的定位与卖点。用户或是消费者,使用我们的产品而不使用竞品的理由是什么?

如果我们分析完成,自己都说服不了自己,那产品也就没有再继续设计下去的必要。俗语说,知己知彼,百战不殆。如果产品经理没有去做产品调研,竞品分析,投入了很多时间和金钱,结果产品投向了市场才发现没用户,那就为时已晚。

我们选取市面上比较主流产品的账单还款产品。分别是银联云闪付中的信用卡功能、支付宝中的信用卡功能和业界主打信用卡账单管理的“51信用卡管家”。

2.1 银联云闪付-信用卡还款

个人如何做一个类似于“51信用卡管家”的产品

银联云闪付中的“信用卡还款”是银联云闪付中比较重要的一个功能。依托银联本身的优势,银行也为银联提供了各种数据API,银联可以把绑定的各家银行信用卡的账单日、最后还款日、账单金额、最小还款金额,实时为用户展示。这是银联信用卡还款产品的一大特点。

还信用卡免手续费,用户在还款时不会有额外支付其他费用的顾虑,由于是实时到账,给用户的还款体验不错。添加信用卡的功能也比较方便,提供了OCR(Optical Character Recognition,光学字符识别)支持,免去了用户添加信用卡输入卡号的繁琐。

另外,还提供了在线申卡的功能,可以很方便申请各家银行的信用卡,为各家银行导流。银行为银联提供API(Application Programming Interface,应用程序接口),银联帮助银行获客,也算是互惠互利,合作共赢。银联信用卡还款产品定位明确,信用卡账单显示与还款整个流程非常流畅,但缺少对非信用卡还款的支持,比如消费贷款、房贷、交房租等账单的记账还款功能。

2.2 支付宝-信用卡还款

个人如何做一个类似于“51信用卡管家”的产品

支付宝也为用户提供了信用卡还款产品。可以将用户绑定在支付宝的信用卡在信用卡还款列表中进行展示。但部分银行不提供账单应还金额的实时查询功能,在信用卡实时查询的范围上,不如银联云闪付所覆盖的银行全面。

对于信用卡的还款,需要自行设置还款时间。而且还信用卡需要支付一定的费用,也没有标明实时到账,只是提示“预计今天到账”,和银联相比在到账时效上,缺少些自信。不知道对于信用卡还款有多少用户愿意为此付费。

支付宝信用卡还款产品提供了“添加还款类型”功能,不仅可以添加信用卡,也可以添加房贷、车贷、房租的还款信息,这点比较人性化。为用户提供了更多的记账类别,便于用户查看自己不同的还款项目,这个很不错。

2.3 51信用卡管家

个人如何做一个类似于“51信用卡管家”的产品

51信用卡算是在互联网行业主打以信用卡还款产品为核心的企业了。支持用户添加信用卡账单和生活账单,统计比较全面。账单汇总功能,可以查看名下各账单的还款情况,并为用户提供了信用卡消费分析。为客户提供了除账单管理的额外增值服务。对于51信用卡而言,其Slogan是“让有信用的人过得更好”,可见信用卡账单管理对用户来说功能是免费的,不是51信用卡营收的直接来源,但通过引流,最终通过发放贷款进行赚钱。

不过,对于用户而言,核心诉求还是想记账,其他功能,例如提供还款功能,是加分项。用户还款,也不是实时到账,产品提示是“预计1h到账,次日入账”,对于还款手续费,当月只有6000元的还款额度,超出额度,要额外支付0.2%的手续费。对于经常还大额的用户来说,可能更倾向于选择免手续费的还款方式。

由于51信用卡缺少同银行API对接,无法为用户提供实时的账单信息查询,只能通过用户提供自己接收账单的邮件账号,51信用卡通过读取用户邮箱中的银行账单,提取信用卡账单还款数据。也算是一种折衷的办法。但对于我自己而言,我是不希望把自己邮件的用户名和密码提供给第三方机构,让其读取我邮件中的内容。感觉有一些安全上的顾虑。

2.4 小结

结合以上分析,我整理了一个功能表格,如下所示。

个人如何做一个类似于“51信用卡管家”的产品

可以看出,虽然仅是账单还款这么一个小功能,各家产品也有各家产品的基因。不同用户可以根据自己需要选择产品。而像我这一类的客户,不愿意提供邮件账号密码给第三方,又希望支持其他账单有还款记录,也不在意对方提供不提供实时还款的功能,就是希望有一个单纯的记账和查看功能。

产品更加轻量简洁一些,只想要记账这个核心功能,相当于要给这些产品做减法。目前上有这样单纯的产品吗?还没有,都是流量入口,大家都希望提供更多的功能来增强用户粘性。而有像我这样就想单纯的记账用户吗?应该也有。

3. MRD之产品设计

MRD可以通俗地理解为准备做某一款产品,市场层面打算想做成什么样的说明,其作用是承上启下。

一方面,对BRD中领导层的的意见和公司战略方向进行整合,提炼核心功能与核心价值,另一下面,对即将编写的PRD,为其明确产品范围、功能定义,防止产品设计与最初的目标不一致的情况出现,可以理解为MRD是一个指导性的框架说明文档。

有些公司前中后台产品经理分工比较细,也可以理解为是我们常遇到的一句话需求。比如业务产品经理直接和技术产品经理说,我要实现一个业绩查看的功能,可以查看、导出某个时间范围内的团队业绩。接下来技术产品经理会根据业务产品的这句话,编写PRD。说的直白一点,就是这款产品打算怎么做。

3.1 产品定位

如果我也想做一款像银联、支付宝、51信用卡功能这么齐全的账单管理产品,即便是技术可行性和经济可行性,都具备,还不具备时间可行性。账单管理产品,在这几家公司都是几个团队配合,至少投入十几个人的人力和资源才开发出来的。

而由于其用户群体的广泛性,需要围绕账单还款这个核心功能扩展出很多衍生功能。而现实中,即便是使用了这些功能的用户,仍然也在使用Excel记录自己的账单还款情况。而我的还款产品的定位,就是希望能为使用Excel记账的用户,提供移动便捷的记账功能。

3.2 产品框架设计

将产品功能做减法后,仅保留几个必要功能。

用户相关模块,用户注册和登录是必不可少的。由于产品设计的初衷是尽量不收集用户信息,因此用户注册中,仅需要输入用户名和密码即可,对于自愿的用户,可以提供电子邮箱地址,认证通过后的用户,可以用来使用密码找回功能。

账单还理模块,用户可以自行新建账单月份,在月份中录入还款项名称,账单日,最后还款日,账单金额 和已还金额,系统会自动计算剩余应还金额。月份列表,会汇总当月所有还款项的账单总金额,已还总金额和剩余应还总金额,方便用户直观查看自己的还款情况。

考虑到用户新增月份后,每个月都要新增还款项比较繁琐,为用户提供了还款项智能模版功能,用户新增月份后,不需要再录入还款项,会自动将上个月的已经录入完成了还款项名称带入,用户只需要填写本月的账单金额即可。

还款趋势分析是一个额外的附加功能,便于用户直观查看每个月总的账单情况和还款情况。

个人如何做一个类似于“51信用卡管家”的产品

3.3 产品流程设计

既然我们的产品是定位一款极简的还款记账产品,我们就要先明确核心流程。对于产品流程设计,我们可以采用自底向上或是自顶向下的设计方法。自底向上,就是我们先明确最基础的功能流程,将一个个基础功能流程整合起来,形成最终总流程,向顶向下的设计方法,则是先明确总流程,然后再将总流程中涉及的每个子流程进行细化。

我们这款产品采用自顶向下的流程设计方法,经过分析,我们这款产品流程设计如下所示。

产品经理,产品经理网站

用户注册登录、用户信息管理、密码修改、邮箱管理这些产品的基础功能太基础了,就不在这里特别介绍了。接下来主要介绍还款记账的核心功能。在准备做这款产品前,我自己觉得非常简单,但在实现的过程中却发现有很多值得考虑的细节。在这里分享给大家。

4. PRD之产品功能设计

PRD就是将产品理念进行落地的文档,主要面向团队开发人员,设计(UI、UE)、测试、运营等,需要更加详细的去阐述所有功能。就产品流程而言,其实PRD也不是产品的最终文档,还可以继续分拆为需求说明书、设计说明书、测试说明说、运营说明书等。PRD中主要会描述详细的功能说明和业务流程。说的直白一点,就是这款产品如何落地推向市场面向用户。

4.1 产品主页面

产品功能设计采用产品MVP(Minimum Viable Product,最小可行性产品)理念,先满足核心功能。用户希望有一辆车解决出行痛点,我们就先造一辆车让用户先开起来,至于里面有没有空调,座椅是不是真皮,暂时不重要。

本次的产品功能设计也是如此,为了方便用户直观体验产品功能,用户不需要注册,就可以先体验。因为好的产品不应该绑架用户。有些产品设计,用户不注册,就不让用户体验产品是不对的。

个人如何做一个类似于“51信用卡管家”的产品

主页中,突出了“开始记账”的按钮,方便用户可以第一时间找到记账入口。如果用户还没有登录,则会先为用户展示登录页面。用户登录完成,进入到每月的还款汇总列表页面。

4.2 还款月汇总页面

还款项都是以每个月份进行承载,所以我们的视图设计,也是基本还款记账月份列表进行展示。用户查看自己的还款账单,一般都是看这个月份总共需要还多少钱,已经还了多少钱,还剩下多少钱未还。

个人如何做一个类似于“51信用卡管家”的产品

按照流程设计,用户从列表页面可以查看月还款项细节,不过首次使用的用户,在新增完成记账月份之后,不能第一时间知道从哪开始新增还款项。因此细节上,在每个月还款的卡片上,将”查看”,改为记账。

4.3 还款项新增与编辑

用户选择记账年和记账月份,点击 “新增记账月份”会为用户新增一条记账月份卡片。

用户点击月份卡片中的“查看”,会为用户显示月份下的还款项明细信息,用户也可以进行还款项的新增、编辑、删除操作。

个人如何做一个类似于“51信用卡管家”的产品

新增完成记账项后,会实时显示新增的还款项卡片。为了用户方便了解还款项数量,在每个还款项名称前进行自动编号。同时,为了便于用户关注自己的还款情况,将剩余还款金大于0的金额标红。考虑到删除是个相对比较谨慎,因此功能放置在编辑的下一级,而没有同编辑平级。

产品经理,产品经理网站

4.4 安全设计

而每次我们修改每一还款项的还款金额时,当月的总还款情况都需要同步更新,这就需要在产品设计的内部,定义一个触发器,以确保各数据都可以实时更新。以确保数据准确。

防注入设计,因为我们在使用ID录入还款项时,要对传入的ID进行认证,对于不合法的ID要进行过滤。否则会有注入风险。后续如果为了保证数据传输安全,还可以通过配置权威机构认证的数字证书,采用https的方式进行数据传输。

5. 总结

最后,我们通过KANO 模型进行我们产品的功能分析,看看我们是否遗漏优先级比较高的功能。KANO 模型原本是用于对用户需求进行分类和优先排序的工具,通过分析用户需求对用户满意的影响,从而了解产品性能和用户满意之间的关系。

产品经理,产品经理网站

很明显,优先级比较高的几个核心功能,都已经实现了。接下来就是我们要考虑如何能给用户提供能令用户“尖叫”的功能了。因为我们这款产品为用户提供的还款记账基础功能,只是解决了用户还款记账的痛点,如果想要用户体验更好,我们还要做一些锦上添花的功能,满足用户的爽点,同时借助于口碑,进一步为其他用户群体提供痒点。但不论怎样,我们都要围绕我们产品的定位,一款极简的还款记账工具。

这样一个基本的账单记账小助手的产品就完成了。当然产品细节还有需要打磨的空间,比如一些操作过程中的异常处理和提示。整个流程是不是还有进一步提升用户体验的空间。既然是谈到实战, 就要看实际的效果。

其实使用MVP理念,可以先用最小成本将产品投入市场,根据用户和市场反应,不断升级迭代。这样用户的学习成本也相对较低。这次的产品采用H5和PC自适应技术,用户通过手机浏览或是PC浏览,会自行适配。接下来,可以进一步开发账单记账小助手的小程序版本和APP版本。

有温度的产品源于有温度的员工和企业文化。做为产品经理,我们首先站在用户的角度去看待问题,规划产品。希望我们彼此,都能做有温度的人,设计有温度的产品。

 

作者:王佳亮,中国计算机学会(CCF)会员。微信公众号:佳佳原创

本文原创@王佳亮 。

版权声明

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

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部