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

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 银联云闪付-信用卡还款

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

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

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

2.2 支付宝-信用卡还款

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

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

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

2.3 51信用卡管家

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

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

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

2.4 小结

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

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

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

3. MRD之产品设计

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

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

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

3.1 产品定位

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

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

3.2 产品框架设计

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

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

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

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

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

3.3 产品流程设计

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

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

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

4. PRD之产品功能设计

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

4.1 产品主页面

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

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

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

4.2 还款月汇总页面

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

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

4.3 还款项新增与编辑

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

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

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

4.4 安全设计

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

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

5. 总结

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

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

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

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

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

作者：王佳亮，中国计算机学会（CCF）会员。微信公众号：佳佳原创

本文原创@王佳亮 。

版权声明

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