此外，还提供了在线卡功能，使您能够轻松申请各银行的信用卡，并诱导各银行。银行为银联提供应用程序界面(application programming interface)，银联帮助银行接待客人，被视为互惠互利、合作共赢。银联信用卡还款产品定位明确。信用卡账单显示还款整个过程非常顺畅，但对非信用卡还款的支持(如消费者贷款、房贷、房租支付等账单还款功能)不足。

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

支付宝

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

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

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）会员。微信公众号：佳佳原创

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

题图来自Unsplash，基于CC0协议