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

1、前言

在上一篇文章《个人如何做一个类似于“51信用卡管家”的产品》中主要对市面上比较主流的几款还款记账产品进行了竞品分析。俗话说，知己知彼，百战不殆。市面上已经有了产品，你要再做一款类似的产品，如果没有特别的卖点，用户是绝对不会买账的。借助于波特五力模型，供应商的议价能力、购买者的议价能力、新进入者的威胁、替代品的威胁和同业竞争者的竞争程度，这五个维度，我们可以很清晰的我们打算要做的一款产品的价值。如果从分析结论上来看，现在在线还款记账产品基本上头部的互联网企业做的已经非常成熟，有资源、有技术、有实力，个人再做一款记账产品成功几乎无法与这些优秀的互联网企业所做的产品相提并论。而我们所做的一款记账产品的的定位是极简、小众。与大厂产品不同，大厂记账产品功能多而全，我们的记账产品小而精。做为一款记账产品的诞生实战，利用产品思维来解决实际问题，过程价值大于结果价值，我们可以通过记账产品从0至1的实现，来了解产品的各个阶段和注意事项，为今后设计其他产品，提供素材与支持，少走弯路，尽可能避免踩坑。

2、BRD与MRD

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

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

MRD可以通俗地理解为准备做某一款产品，市场层面打算想做成什么样的说明。其作用是承上启下。一方面，对BRD中领导层的的意见和公司战略方向进行整合，提炼核心功能与核心价值，另一下面，对即将编写的PRD，为其明确产品范围、功能定义，防止产品设计与最初的目标不一致的情况出现。可以理解为MRD是一个指导性的框架说明文档。有些公司前中后台产品经理分工比较细，也可以理解为是我们常遇到的一句话需求。比如业务产品经理直接和技术产品经理说，我要实现一个业绩查看的功能，可以查看、导出某个时间范围内的团队业绩。接下来技术产品经理会根据业务产品的这句话，编写PRD。说的直白一点，就是这款产品打算怎么做。

以本文在线还款记账产品诞生实战而言，在上一篇文章《个人如何做一个类似于“51信用卡管家”的产品》，其实更多的类似于BRD和MRD，已经做过讲解。今天的这篇文章，更多的侧重于PRD。

3、PRD

3.1 产品流程设计

PRD就是将产品理念进行落地的文档，主要面向团队开发人员，设计（UI、UE）、测试、运营等，需要更加详细的去阐述所有功能。

就产品流程而言，其实PRD也不是产品的最终文档，还可以继续分拆为需求说明书、设计说明书、测试说明书、运营说明书等。PRD中主要会描述详细的功能说明和业务流程。说的直白一点，就是这款产品如何落地推向市场面向用户。

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

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

3.2  产品功能设计

用户注册登录、用户信息管理、密码修改、邮箱管理这些产品的基础功能太基础了，就不在这里特别介绍了。接下来主要介绍还款记账的核心功能。

在准备做这款产品前，我自己觉得非常简单，但在实现的过程中却发现有很多值得考虑的细节。在这里分享给大家。还款项都是以每个月份进行承载，所以我们的视图设计，也是基本还款记账月份列表进行展示。用户查看自己的还款账单，一般都是看这个月份总共需要还多少钱，已经还了多少钱，还剩下多少钱未还。

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

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

3.3 产品安全设计

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

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

4、结语

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

很明显，优先级比较高的几个核心功能，都已经实现了。

大家有兴趣可以访问我的实战网站体验产品：http://miliao.xyz

接下来就是我们要考虑如何能给用户提供能令用户“尖叫”的功能了。

因为我们这款产品为用户提供的还款记账基础功能，只是解决了用户还款记账的痛点，如果想要用户体验更好，我们还要做一些锦上添花的功能，满足用户的爽点，同时借助于口碑，进一步为其他用户群体提供痒点。但不论怎样，我们都要围绕我们产品的定位一款极简的还款记账工具。

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