产品经理信贷H5产品需求文档.pdfVIP

编辑导读：通过互联网贷款在如今是一件很常见的事情，各类互联网信贷

产品层出不穷。本文作者根据自身工作经历，整理了一个信贷H5产品的需求

文档，希望对你有帮助。

这个H5产品需求是将近一年以前的需求，当时我们想要在一家银行的

APP中放入一个贷款的链接，引导用户去点击跳转到我们的H5页面去申请贷

款，包括授信、借款等流程。

现在正在找工作，就把这份产品需求文档拿出来用作面试作品，对里面的

内容进行了很多补充，参考了一些产品教程，并把说明进行了细化，将当时后

期才做的埋点需求也一并放了进来，还对一些信息内容作了大量的修改。

在这个过程中，参考了一些PRD文章、《信息架构》、《web界面设

计》、《用户体验与可用性测试》等资料。

在做该产品以前，我们主要对一些银行及消金机构的贷款产品进行了了

解，在使用这些产品的过程中，我们发现这些产品内容庞杂，比如银行APP就

包括存款、债券、证券、保险、期货、股票、消费贷等众多板块，

一来是内容太多，且大部分模块一般人用不上；

二是众多模块交叉分布，很容易让对某一模块功能有需求的用户找不到对

应模块入口。

在后期产品形态过程中，一来是根据使用场景及客群入口情况，选择了H5

为产品形态；二来明确该产品一定是要内容及模块简单，因为我们面对的客群

很明确，就是需要资金支持的用户，所以务必能让他们一进来就很容易找到他

们需要的内容。

进而在产品信息架构组织过程中，遵循【组织结构-标签-导航】的顺序进

行了分析。

组织结构：

在这个产品中，主要的内容就是贷款内容，以及对应的授信借款流程，现

在贷款大多以贷款内容为主要维度进行模块区分，

所以摆在我们面前主要就是两条路，以贷款内容类型做组织维度，或者以

贷款阶段（授信、借款）为组织维度。

但是我们在第一次原型做好进行用户测试（包括卡片测试）时，发现其实

用户自身对这些贷款内容类型的区分以及贷款流程的区分并不特别敏感，他们

更多是对自身一种需求状态的认知：我是要寻找贷款，还是要查看我授信/借款

的状态（看审核有没有通过、授信额度多少、有没有放款）。

所以我们决定以用户状态作为组织维度，分为两种状态的用户：找贷款的

用户、查看已申请贷款状态的用户。

标签：

我们产品中必然有很多文字内容，需要以通俗的文字语言来给用户传达产

品功能。

在调研用户的过程中，发现需要贷款的用户，其实不会只寻求一款贷款产

品，通常都会同时下载或使用多个APP，而且其实很多贷款产品语言描述都比

较相似。

所以在标签内容上，我们决定主要是参考主流贷款产品的文字描述。

导航：

在组织结构明确下来后，导航也相对确定下来，产品先以用户状态进行引

导，即找贷款的用户，查看已申请贷款状态的用户。

考虑到移动设备较为狭小的屏幕面积，以及相对简单的组织结构，我们决

定不用明显的导航模块，在登录以后的落地页中，直接明确一主一次，我们的

产品收益主要来源于用户申贷的返佣，所以落地页定为贷款内容展示页，在较

小位置添加往期申贷情况的入口。

局部导航：在往期申贷的内容版块中，还要分为授信、借款、还款三大

块，但是授信订单与借款订单是一对多的关系，借款订单和还款记录也是一对

多的关系，由于三者相互之间强关联的关系，所以决定在此采用层级结构进行

内容组织和引导。

信息架构明确完毕后，就是原型和设计细节的明确。

版本历史、文档结构、文档说明、需求背景、全局需求说明、页面需求说

明、后台管理系统需求说明、埋点需求说明、其他需求。

本文档是该需求的初版，是在与B公司前期商务沟通的基础上，进行系统

层面的沟通和需求确认，在后期该需求历经多次迭代，所以本需求文档与实际

确认版本出入较大，不代表实际情况，仅供参考。

2.5.1产品信息

产品名：XX信贷平台

产品版本：V1.0

产品形态：移动端H5

2.5.2产品角色

现在已有的流程是，客群流量的申请信息由资产方推送，经C公司决策引

擎初筛后，分流至资金方进行审核后，资金方返回最终审核结果，再由C公司

回送审核结果至资产方通知到客户。

现在需要增加一个流量入口，资产方（A公司）提供H5流量入口，客户由

H5平台采集信息并做简单初筛后，直接推送至B公司进行授信及借款审