简介一份51信用卡管家APP的产品需求文档面向产品经理、交互设计师及金融科技从业者用于学习如何从用户、业务、交互等维度撰写完整PRD并理解信用卡管理类App的常见功能设计与业务流程。文档为docx格式共1个文件压缩包大小2.95MB。内容覆盖产品概述、体验环境、核心功能账单管理、还款、借贷、理财、用户画像、产品结构图、全局交互规则以及登录、账单、消息等关键页面的原型交互展示并结合成长值、会员等级、砍账单等特色功能进行说明。目前已有202人学习适合需要参考金融类App需求文档或提升产品分析能力的人群。1. 为什么值得拆 51 信用卡管家倒推式 PRD 能练什么「51 信用卡管家 app 产品需求文档.docx」这份资源是一位产品从业者用 Axure 把 51 信用卡管家从使用、体验、研究三个角度完整倒推出来的一份 PRD 文档。它不是官方产品说明也不是功能清单而是把一款真实运行的金融类 App 拆解成「需求文档」的完整样例。文档覆盖了登录注册、账单导入、消息、财富、借钱、发现、我的等主要模块还补了公积金查询、我的红包这类延伸功能并且单独写了网络异常、交互规则、业务逻辑这些全局说明。适合想转岗产品的人、刚起步的产品助理以及那些想知道一份 PRD 到底该写多细、原型该画到什么程度的从业者。看完你能拿到一套可复用的 PRD 骨架以及具体的原型交互参考。2. 先定骨架五大模块与成长值体系怎么落到文档2.1 五大模块的职责边界账单是核心其余都是业务延伸文档里产品结构图把 App 分成账单、财富、借钱、发现、我的五个模块。拆解一款产品的时候最直接的做法是打开 App 看底部 Tab 栏一个 Tab 对应一个一级业务模块文档目录就出来了。51 信用卡管家这五个 Tab 的边界很清晰我用结构树整理一下51信用卡管家 App ├─ 账单账单导入、信用卡更新、账单详情、还款、砍账单入口 ├─ 财富51产品详情、基金产品详情、投资券使用 ├─ 借钱信用借款、借款券、运营商信息认证 ├─ 发现金融资讯、知识内容、活动入口 └─ 我的个人信息、我的红包、公积金查询、设置这个结构最值得学的地方在于「账单」为什么被放在核心位置。信用卡用户的真实诉求是账单管理——先导入账单才能知道欠了多少钱、什么时候还还款动作完成之后用户对资金的需求才会浮出水面这时借钱和理财才有转化入口。也就是说账单是获客和留存工具借钱和理财是变现工具发现负责增加打开频次我的承载用户资产信息。做 PRD 的时候如果搞不清这个主次关系评审会上会被反复追问「为什么借钱入口放在财富前面」「为什么发现模块要占一个 Tab」。对比一下常见误用很多新手拆 App 会把所有页面平铺列出来账单、财富、借钱、发现、我的各写一页页面之间没有逻辑关联。这份文档的做法是先定业务归属再定页面优先级表格里可以看得更清楚模块核心功能对应原型页业务性质账单账单导入、信用卡更新、账单详情、还款首页、账单详情、砍账单自研核心留存用户财富基金产品展示、投资券51产品详情、基金产品详情第三方合作变现借钱信用借款、认证、借款券借钱列表、借款流程第三方合作变现发现金融资讯、活动内容发现页内容运营提升粘性我的资料、红包、公积金、设置我的页、红包页用户资产管理你倒推其他 App 的时候先把这个表画出来再往下写原型效率会高很多章节结构也不会跑偏。2.2 成长值体系等级阈值、权益映射与发券逻辑文档名词解释部分定义了一套成长值体系这是 51 信用卡管家的用户分层基础。成长值由用户在应用内的行为综合计算出来包括管理账单、绑定信用卡数量、投资、贷款等。等级分为五档新手会员 0150 成长值、普卡会员 150500、银卡会员 5001500、金卡会员 15003500、白金会员 3500 以上。等级成长值区间定位新手会员0150首次使用尚未形成管理习惯普卡会员150500已绑定基础账单开始还款银卡会员5001500多卡管理可能使用借款金卡会员15003500高频使用投资或借款活跃白金会员3500以上高价值用户重点运营对象这套体系单独看就是一组数字但放进业务场景里才有意义。文档同时定义了还款金、投资券、借款券、砍账单四类资产还款金可用于信用卡还款时抵扣投资券用于投资时加息或调整利率借款券是借款时的抵费券砍账单是邀请好友助力随机获取金额可叠加在还款场景使用。从 PRD 写作的角度看这组定义的价值在于「把后端逻辑前置到名词解释里」。成长值怎么计算、各等级有什么权益、券怎么核销这些都是后端逻辑前端只负责展示余额和使用入口。很多新人写 PRD 会把成长值计算规则写在某个原型页下面结果同一套规则在不同页面重复出现口径还不一致。文档这种做法是把规则抽到顶层原型页直接引用评审的时候所有人看的是同一份定义这是值得复用的写法。砍账单是另一个值得展开的运营功能点。它的核心是社交裂变用户发起砍账单分享给好友好友进入后帮砍一个随机金额砍下来的钱可用于还账单。PRD 里如果只写「邀请好友随机获取金额」开发会不知道怎么实现——随机金额的范围是多少、同一个好友能不能重复砍、一个账单能发起几次。文档里定义得还不够细这部分我在第 5 章避坑清单里会专门说。2.3 从结构图到原型页面的顺序先画信息架构再补交互文档的目录顺序是产品概述、名词解释和功能点、产品结构图、全局说明、部分功能原型交互展示。这个顺序本身就是一份合格 PRD 的标准骨架。我见过很多新人拿到 Axure 就开始画页面画到一半发现交互规则不知道放哪儿数据加载方式也不知道怎么写最后把所有注释都堆在原型页顶部评审会上别人根本看不完。正确顺序应该是先写清楚产品目标和用户画像再画信息架构图然后把所有页面共用的交互规则抽到「全局说明」里最后才动手画具体原型页。这样做的原因很实际全局说明就像代码里的公共函数。toast 展示几秒、弹框点外部能不能关、键盘弹数字还是字母、网络异常怎么展示这些规则如果拆到每个页面单独写写十页就累了写到后面还会有遗漏和冲突。抽成公共规则后原型页里只需要写「参照全局说明 3.2」页面干净评审效率也高。这份文档的全局说明写得尤其细下一章单独拆开讲。3. 全局说明才是 PRD 的底子网络异常、交互规则和数据约定3.1 网络异常的三级反馈缓存兜底、浮窗提示、toast一般 PRD 里网络异常就是一句话「断网时给出提示」。这份文档把场景拆成了三种级别网络请求失败 ├─ 页面有本地缓存 → 展示缓存数据 页面底部浮条提示网络异常 ├─ 页面无本地缓存 → 展示插图和提示性文案 └─ 非一级页面请求失败 → toast 提示网络异常2 秒后自动消失第一层「有缓存就展示缓存数据」这是金融类 App 特别在意的取舍。用户打开账单页面最怕白屏账单信息加载不出来用户会焦虑甚至担心自己欠款出了问题。所以账单、财富这类一级页面必须做本地缓存兜底同时因为数据可能是旧的页面底部要常驻一个浮条提示「网络异常」而且这个浮条只有网络恢复正常才消失或者用户手动删除不能用 toast 一闪而过——网络异常不是临时事件toast 展示两秒就没了用户根本没看到。第二层「无缓存就展示插图加文案」适用于首次安装、还没有产生本地数据的场景这时候没有数据可兜底只能给一个友好的空状态引导用户重试。第三层是次级页面比如资讯消息类内容页这类页面数据可以接受短暂加载失败toast 提示一次就够了。PRD 写到这里开发不需要追问「到底什么时候弹什么」直接按层级实现测试用例也有依据。如果你倒推的是工具类、社交类 App这套三级反馈思路同样通用差别只在缓存策略和提示级别的选择上。3.2 交互规则的细节toast、dialog、浮窗、键盘、生物识别、空状态文档的全局说明里列了六类交互规则每一条都可以原样抄进自己的 PRD 模板操作反馈 toast反馈型 toast 展示时间为 2 秒文案按对应交互场景设计iOS 位于屏幕中间Android 位于屏幕偏下。这里的关键参数是 2 秒太短用户看不清太长又挡内容两个平台的位置差异也要写明否则 UI 验收的时候风格不统一。进程型 toast需要带 icon 和文案反馈当前进程比如「正在加载」「正在登录」进程结束后消失。这类反馈适合耗时操作但注意不能和加载动画混用一般页面局部刷新用 toast整页加载用 loading 态。dialog 弹框必须用户点击弹框上的 button 才消失点击页面其他地方弹框不消失。这条最容易踩坑——移动端不少弹框设计是点击遮罩层关闭但支付确认、借款协议这类强确认场景如果也能点外部关闭用户误触一下就完了。所以文档这条规则是在保护用户资产安全写 PRD 时要把「点击外部不消失」作为默认约定除非明确标注某个弹框允许点击遮罩关闭。异常情况浮窗异常消失或者用户手动点击删除才会消失。典型场景就是网络异常时一级界面展示缓存数据用浮窗而不是 toast因为浮窗常驻能让用户持续感知数据不是最新状态。键盘规则用户点击手机号码、验证码、金额、身份证号码、支付密码等输入框时弹起数字键盘点击登录密码等需要输入文本的位置弹起常规键盘。这条看起来基础但很多 App 实际做出来验证码输入弹的是全键盘用户切数字要手动点体验很差。PRD 里明确写明输入框类型和对应键盘类型开发就不用猜。生物识别用户开启手势密码和生物识别后优先使用生物识别生物识别不了才回落到手势密码。这条逻辑在金融 App 里是安全性和便捷性的平衡很多产品把顺序搞反逻辑写得不清不楚。空状态页面正常情况下没有数据时展示插图配提示性文案必要时根据场景增加引导 button 或链接。比如账单列表为空时除了「暂无账单」文案还要给一个「导入账单」的引导按钮这才是合格的空状态设计。六类规则的表格整理如下反馈类型展示时长是否阻断操作典型场景反馈型 toast2 秒自动消失否保存成功、删除成功进程型 toast进程结束消失是登录中、加载中dialog 弹框点击 button 消失是支付确认、协议确认异常浮窗异常恢复或手动删除否网络异常、缓存数据展示键盘随输入状态弹起/收起部分阻断验证码、金额、密码输入空状态数据加载后消失否无账单、无消息3.3 业务逻辑和数据说明借款认证、开户约束与缺失的数据说明文档业务逻辑部分写了两条硬性规则用户借款时需要真实信息和运营商信息认证用户投资时需要开通北京银行个人账户。第一条说明借款流程依赖第三方征信和运营商数据PRD 里要明确前置认证条件——不是用户点击「借款」就能借而是先完成实名认证、运营商认证系统才有依据评估授信额度。写这类需求时字段清单要包括真实姓名、身份证号、手机号服务密码或运营商授权 token认证失败的分支也要写清楚。第二条说明理财业务的资金账户是银行存管模式51 信用卡管家只做导流和产品展示用户的资金账户开立在合作银行。这个业务边界不写清楚开发会默认 App 自己维护资金账户对接起来就出大问题。需要提醒的是文档里第 4 节「数据说明」实际是空白的没有给出具体字段定义。这是这份文档最大的缺口——PRD 写到全局说明阶段至少要把账单、用户、消息这三类核心实体的字段列出来开发才能评估工作量、测试才能设计用例。这一点我在第 5 章会专门展开讲真拿到文档照着画原型的时候这块必须自己补上。4. 登录注册与账单导入验证码规则和短信更新流程怎么拆4.1 登录注册流程三种登录方式与验证码限流规则登录注册是每个 App 逃不开的模块51 信用卡管家同时支持账号密码登录、手机验证码登录和第三方 QQ/微信/微博登录注册流程里还带了邀请码机制。流程拆出来是这样的手机号注册后先通过验证码验证身份验证通过后用户可自主设置账号密码如果用户走第三方授权登录登录后必须绑定手机号完成身份认证。注册时可选填朋友给的邀请码用于后续运营活动追踪。文档里最有价值的是验证码获取规则写得很定量同一手机号只能绑定一个账户2 分钟内不可多次请求验证码同手机号 2 分钟内第二次请求时toast 提醒「请求验证码过于频繁请 1 分钟后再试」一天最多请求 6 次验证码第 7 次请求时 toast 提醒「今天已请求 6 次验证码了请明天再试」。这两条规则本质上是后端限流策略的前端表现2 分钟和 6 次是服务端限制前端只是把限制结果翻译成用户能理解的文案。PRD 里如果只写「验证码 60 秒后可重新获取」而不写明当天的上限次数会被滥发短信攻击短信费用和风控都出问题。我建议照文档的写法把限制参数和 toast 文案放在一张表里评审时后端、前端、测试三方口径完全统一场景触发条件提示文案请求过于频繁同一手机号 2 分钟内第 2 次请求toast请求验证码过于频繁请 1 分钟后再试当日次数耗尽同一手机号当日第 7 次请求toast今天已请求 6 次验证码了请明天再试这里还有一个细节验证码输入错误后的处理、验证码有效期常见是 5 分钟或 10 分钟、重新发送后旧的验证码是否立即失效这些文档里没有展开。实际写 PRD 时建议补上「验证码有效期 10 分钟」和「重新发送后旧码作废」两条后端实现时常见做法是以最后一次下发的验证码为准。提示验证码相关的文案和参数属于「运营配置」而不是「硬编码」PRD 里最好标注这些参数可通过后台配置修改避免以后改个数字还要发版本。4.2 账单导入与信用卡更新验证码弹框交互细节账单模块是整份文档的重点。前置条件很明确用户需要先导入账单才可以在首页查看账单、接收账单通知。也就是说未导入账单的用户进入首页看到的是空状态引导页而不是直接展示一个空列表。页面逻辑拆开看分两种路径普通账单导入时用户利用手机验证码或者登录第三方账户验证身份后获取最新的账单信息信用卡更新账单时交互就更细了用户点击「更新」按钮按钮文案变为「输入验证码」同时服务器下发短信验证码用户点击「输入验证码」弹出验证码输入弹框用户输入验证码判断正确后账单开始更新。文档作者在页面描述后加了一条个人建议「点击更新账单后验证码弹框和数字键盘自动弹起用户即可填入验证码进行验证。」这条建议是一个典型的交互优化点——如果用户点了「输入验证码」之后还要再点一次弹框、再等键盘弹起来多一步操作体验就钝了。PRD 里写功能描述时顺手补这么一句「建议」评审会上的观感会明显不一样说明你已经把交互走查过了。信用卡更新账单这个流程里还有几个隐含状态值得写进 PRD更新中按钮要置灰并显示加载状态验证码输入错误时的 toast 反馈服务器下发验证码失败的异常分支验证码过期后怎么重发。文档只描述了主流程分支状态需要在使用 Axure 画原型时自己补齐评审会上开发最常追问的就是「验证码错了怎么办」。4.3 借钱与理财的原型展示外部业务嵌入的边界财富、借钱这两个模块的原型页包括 51 产品详情、基金产品详情、借钱列表等。这些页面本质上是第三方业务的容器页App 本身不做资金和风控只是把第三方的产品或借款产品接进来展示给用户。写这类页面的 PRD 时业务逻辑不用从零定义但要明确三个边界一是跳转规则——用户在 App 内点击产品卡片是跳到 H5 页面还是原生页面、是否需要登录态透传二是数据来源——产品列表和利率信息由第三方接口提供App 只负责展示接口字段和刷新策略要写清楚三是授权流程——用户借款时需要的真实信息和运营商认证这个动作在 App 内完成还是跳转到第三方 SDK 完成决定了对开发的工作量评估。文档对这两块的描述就是标准的「透传式」写法说明前置条件交代认证要求然后交给第三方。这样处理是合理的——第三方业务的细节不该占用核心精力PRD 写得越重评审时越容易被细节拖住。5. 避坑清单这份 PRD 里最容易被细节坑到的五个地方5.1 「数据说明」是空的评审会上被追问到哑口无言现象文档全局说明的第 4 节标题是「数据说明」但正文里没有给出任何字段定义和数据结构整节是空的。原因原作者大概率是把字段细节留在了 Axure 原型的分页里没有整理进文档。这种「原型里有、文档里没有」的情况非常常见文档一旦脱离原型单独流转数据定义就彻底丢了。解决必须补一张数据字典表至少覆盖三类核心实体——用户用户 ID、手机号、姓名、成长值、会员等级、账单账单 ID、卡类型、账单金额、还款日、账单状态、所属用户、消息消息 ID、类型、标题、内容、发送时间、已读状态。字段要标明类型、长度、是否必填、默认值开发拿着就能建表。5.2 账单详情页没有展开核心页面反而写漏了现象文档目录里有「账单详情」但正文部分账单写完就跳到消息模块账单详情页的原型和交互逻辑没有实际内容。原因账单详情是字段多、状态多、操作多的页面写起来麻烦容易被跳过。这是 PRD 写作的老毛病——首页写得很详细二级页面一笔带过。解决账单详情页单独拆一小节至少列出三类信息账单基础字段账单金额、最低还款额、账单日、还款日、卡种状态分支未出账、已出账、逾期、已结清每个状态的展示内容不同操作按钮还款、分享、砍账单在不同状态下的可点击性。文档在交互规则部分已经定义了「可操作、不可操作、操作后」三种状态这里正好应该引用。5.3 产品目标写得无法验收评审时说不出成功标准现象文档产品目标里有「提高用户体验」「拉取更多用户」「增强用户活性」这类句子没有量化指标。原因目标写成了方向没有写成分解后的指标。方向本身没错但开发、测试、运营无法判断「做到什么程度算达标」。解决改成可衡量的指标。「支持市面上大部分机型」可以写成「兼容 Android 10.0 及以上、iOS 13.0 及以上主流机型覆盖率 ≥ 95%」「极速借款」可以写成「从点击借款到授信结果返回平均时长 ≤ 3 分钟」「拉取更多用户」可以写成「砍账单活动新增用户占比 ≥ 20%」。评审会上这样写每一项都能被验证而不是被一句「需求不清晰」打回。5.4 成长值体系只定义了数值没有落成页面和入口现象名词解释里写了成长值 0150 是新手会员、150500 是普卡会员但原型展示部分没有对应的等级说明页或成长值明细页用户看不到自己的等级和权益。原因成长值体系作为后端逻辑定义了但前端页面没有同步设计。用户在一个产品里感受不到等级的存在整个体系就废了。解决在「我的」模块补上成长值入口点进去展示当前等级、距离下一级还差多少成长值、各等级权益对照表。顺手把等级权益和发券逻辑打通——还款金、投资券、借款券的发放规则应该在等级页里有所体现比如「银卡会员每月可领 1 张还款金」。功能点之间不打通PRD 就还停留在概念层。5.5 砍账单规则不完整开发拿到需求无从下手现象文档定义砍账单是「邀请好友随机获取金额数可用于还账单时使用」但缺少最关键的运营参数随机金额范围、单笔账单可砍次数、同一好友能否重复砍、砍下来的金额有没有提现门槛。原因砍账单是运营活动运营还没给出确定口径产品就把一个不完整的功能写进了 PRD。这在团队里会造成两个后果开发排期不准确测试用例没法设计。解决把砍账单当成一个完整的功能点补全参数活动时间起止日期金额上下限比如单次砍掉 0.55 元每个账单可发起砍价的次数比如 3 次同一好友对同一账单只能助力 1 次好友助力需要关注的验证条件砍下来的金额进入还款金账户还是单独的活动账户。参数不一定全由产品定但 PRD 里要留出明确的运营配置位并在备注里写明「以上参数由运营端配置后端按配置下发」。6. 进阶用法拿这份 PRD 当模板倒推其他金融 App这份文档最好用的场景是当模板去倒推另一款 App。我拿它试过一次记账类 App整个流程走下来大概五步第一步用 Xmind 把目标 App 的底部 Tab 栏拆成一级模块明确哪些是自研业务、哪些是第三方合作业务这一步决定了后续的工作量分配。第二步逐个 Tab 截图记录页面元素把每个页面的字段、按钮、状态写出来参照账单模块的写法标注交互分支。第三步直接复用文档里的全局说明——网络异常三级反馈、toast 2 秒、dialog 点击外部不消失、数字键盘规则、空状态设计这些规则在金融类 App 里几乎全量通用不需要重新定义。第四步抽业务规则重点参考登录注册里验证码限流的写法把成长值、积分、还款金这类运营资产抽象成名词解释加等级表单独成节。第五步选一个核心流程做深度拆解——像 51 信用卡管家的账单导入一样拆到「异常情况都注明」的程度然后对照第 5 章的避坑清单检查数据说明有没有补、账单详情页有没有漏。我第一次独立写 PRD 的时候直接把 Axure 原型的链接丢给开发注释全写在原型页顶部开发审完跟我说看得很痛苦每个页面的边界条件都要追问一遍。后来我强制自己先写结构图再写全局说明最后画原型迭代三版之后评审会基本不用再解释页面逻辑了。从那以后我每次倒推 App 都强制走一遍这套流程先骨架后细节先规则后页面。这份文档的价值就在于此——它提供了一套可以直接照做的 PRD 骨架你唯一要做的就是拿一个真实 App 去练一遍。希望帮到你。本文还有配套的精品资源点击获取 拆解51信用卡管家App：倒推式PRD的完整案例与避坑指南
简介一份51信用卡管家APP的产品需求文档面向产品经理、交互设计师及金融科技从业者用于学习如何从用户、业务、交互等维度撰写完整PRD并理解信用卡管理类App的常见功能设计与业务流程。文档为docx格式共1个文件压缩包大小2.95MB。内容覆盖产品概述、体验环境、核心功能账单管理、还款、借贷、理财、用户画像、产品结构图、全局交互规则以及登录、账单、消息等关键页面的原型交互展示并结合成长值、会员等级、砍账单等特色功能进行说明。目前已有202人学习适合需要参考金融类App需求文档或提升产品分析能力的人群。1. 为什么值得拆 51 信用卡管家倒推式 PRD 能练什么「51 信用卡管家 app 产品需求文档.docx」这份资源是一位产品从业者用 Axure 把 51 信用卡管家从使用、体验、研究三个角度完整倒推出来的一份 PRD 文档。它不是官方产品说明也不是功能清单而是把一款真实运行的金融类 App 拆解成「需求文档」的完整样例。文档覆盖了登录注册、账单导入、消息、财富、借钱、发现、我的等主要模块还补了公积金查询、我的红包这类延伸功能并且单独写了网络异常、交互规则、业务逻辑这些全局说明。适合想转岗产品的人、刚起步的产品助理以及那些想知道一份 PRD 到底该写多细、原型该画到什么程度的从业者。看完你能拿到一套可复用的 PRD 骨架以及具体的原型交互参考。2. 先定骨架五大模块与成长值体系怎么落到文档2.1 五大模块的职责边界账单是核心其余都是业务延伸文档里产品结构图把 App 分成账单、财富、借钱、发现、我的五个模块。拆解一款产品的时候最直接的做法是打开 App 看底部 Tab 栏一个 Tab 对应一个一级业务模块文档目录就出来了。51 信用卡管家这五个 Tab 的边界很清晰我用结构树整理一下51信用卡管家 App ├─ 账单账单导入、信用卡更新、账单详情、还款、砍账单入口 ├─ 财富51产品详情、基金产品详情、投资券使用 ├─ 借钱信用借款、借款券、运营商信息认证 ├─ 发现金融资讯、知识内容、活动入口 └─ 我的个人信息、我的红包、公积金查询、设置这个结构最值得学的地方在于「账单」为什么被放在核心位置。信用卡用户的真实诉求是账单管理——先导入账单才能知道欠了多少钱、什么时候还还款动作完成之后用户对资金的需求才会浮出水面这时借钱和理财才有转化入口。也就是说账单是获客和留存工具借钱和理财是变现工具发现负责增加打开频次我的承载用户资产信息。做 PRD 的时候如果搞不清这个主次关系评审会上会被反复追问「为什么借钱入口放在财富前面」「为什么发现模块要占一个 Tab」。对比一下常见误用很多新手拆 App 会把所有页面平铺列出来账单、财富、借钱、发现、我的各写一页页面之间没有逻辑关联。这份文档的做法是先定业务归属再定页面优先级表格里可以看得更清楚模块核心功能对应原型页业务性质账单账单导入、信用卡更新、账单详情、还款首页、账单详情、砍账单自研核心留存用户财富基金产品展示、投资券51产品详情、基金产品详情第三方合作变现借钱信用借款、认证、借款券借钱列表、借款流程第三方合作变现发现金融资讯、活动内容发现页内容运营提升粘性我的资料、红包、公积金、设置我的页、红包页用户资产管理你倒推其他 App 的时候先把这个表画出来再往下写原型效率会高很多章节结构也不会跑偏。2.2 成长值体系等级阈值、权益映射与发券逻辑文档名词解释部分定义了一套成长值体系这是 51 信用卡管家的用户分层基础。成长值由用户在应用内的行为综合计算出来包括管理账单、绑定信用卡数量、投资、贷款等。等级分为五档新手会员 0150 成长值、普卡会员 150500、银卡会员 5001500、金卡会员 15003500、白金会员 3500 以上。等级成长值区间定位新手会员0150首次使用尚未形成管理习惯普卡会员150500已绑定基础账单开始还款银卡会员5001500多卡管理可能使用借款金卡会员15003500高频使用投资或借款活跃白金会员3500以上高价值用户重点运营对象这套体系单独看就是一组数字但放进业务场景里才有意义。文档同时定义了还款金、投资券、借款券、砍账单四类资产还款金可用于信用卡还款时抵扣投资券用于投资时加息或调整利率借款券是借款时的抵费券砍账单是邀请好友助力随机获取金额可叠加在还款场景使用。从 PRD 写作的角度看这组定义的价值在于「把后端逻辑前置到名词解释里」。成长值怎么计算、各等级有什么权益、券怎么核销这些都是后端逻辑前端只负责展示余额和使用入口。很多新人写 PRD 会把成长值计算规则写在某个原型页下面结果同一套规则在不同页面重复出现口径还不一致。文档这种做法是把规则抽到顶层原型页直接引用评审的时候所有人看的是同一份定义这是值得复用的写法。砍账单是另一个值得展开的运营功能点。它的核心是社交裂变用户发起砍账单分享给好友好友进入后帮砍一个随机金额砍下来的钱可用于还账单。PRD 里如果只写「邀请好友随机获取金额」开发会不知道怎么实现——随机金额的范围是多少、同一个好友能不能重复砍、一个账单能发起几次。文档里定义得还不够细这部分我在第 5 章避坑清单里会专门说。2.3 从结构图到原型页面的顺序先画信息架构再补交互文档的目录顺序是产品概述、名词解释和功能点、产品结构图、全局说明、部分功能原型交互展示。这个顺序本身就是一份合格 PRD 的标准骨架。我见过很多新人拿到 Axure 就开始画页面画到一半发现交互规则不知道放哪儿数据加载方式也不知道怎么写最后把所有注释都堆在原型页顶部评审会上别人根本看不完。正确顺序应该是先写清楚产品目标和用户画像再画信息架构图然后把所有页面共用的交互规则抽到「全局说明」里最后才动手画具体原型页。这样做的原因很实际全局说明就像代码里的公共函数。toast 展示几秒、弹框点外部能不能关、键盘弹数字还是字母、网络异常怎么展示这些规则如果拆到每个页面单独写写十页就累了写到后面还会有遗漏和冲突。抽成公共规则后原型页里只需要写「参照全局说明 3.2」页面干净评审效率也高。这份文档的全局说明写得尤其细下一章单独拆开讲。3. 全局说明才是 PRD 的底子网络异常、交互规则和数据约定3.1 网络异常的三级反馈缓存兜底、浮窗提示、toast一般 PRD 里网络异常就是一句话「断网时给出提示」。这份文档把场景拆成了三种级别网络请求失败 ├─ 页面有本地缓存 → 展示缓存数据 页面底部浮条提示网络异常 ├─ 页面无本地缓存 → 展示插图和提示性文案 └─ 非一级页面请求失败 → toast 提示网络异常2 秒后自动消失第一层「有缓存就展示缓存数据」这是金融类 App 特别在意的取舍。用户打开账单页面最怕白屏账单信息加载不出来用户会焦虑甚至担心自己欠款出了问题。所以账单、财富这类一级页面必须做本地缓存兜底同时因为数据可能是旧的页面底部要常驻一个浮条提示「网络异常」而且这个浮条只有网络恢复正常才消失或者用户手动删除不能用 toast 一闪而过——网络异常不是临时事件toast 展示两秒就没了用户根本没看到。第二层「无缓存就展示插图加文案」适用于首次安装、还没有产生本地数据的场景这时候没有数据可兜底只能给一个友好的空状态引导用户重试。第三层是次级页面比如资讯消息类内容页这类页面数据可以接受短暂加载失败toast 提示一次就够了。PRD 写到这里开发不需要追问「到底什么时候弹什么」直接按层级实现测试用例也有依据。如果你倒推的是工具类、社交类 App这套三级反馈思路同样通用差别只在缓存策略和提示级别的选择上。3.2 交互规则的细节toast、dialog、浮窗、键盘、生物识别、空状态文档的全局说明里列了六类交互规则每一条都可以原样抄进自己的 PRD 模板操作反馈 toast反馈型 toast 展示时间为 2 秒文案按对应交互场景设计iOS 位于屏幕中间Android 位于屏幕偏下。这里的关键参数是 2 秒太短用户看不清太长又挡内容两个平台的位置差异也要写明否则 UI 验收的时候风格不统一。进程型 toast需要带 icon 和文案反馈当前进程比如「正在加载」「正在登录」进程结束后消失。这类反馈适合耗时操作但注意不能和加载动画混用一般页面局部刷新用 toast整页加载用 loading 态。dialog 弹框必须用户点击弹框上的 button 才消失点击页面其他地方弹框不消失。这条最容易踩坑——移动端不少弹框设计是点击遮罩层关闭但支付确认、借款协议这类强确认场景如果也能点外部关闭用户误触一下就完了。所以文档这条规则是在保护用户资产安全写 PRD 时要把「点击外部不消失」作为默认约定除非明确标注某个弹框允许点击遮罩关闭。异常情况浮窗异常消失或者用户手动点击删除才会消失。典型场景就是网络异常时一级界面展示缓存数据用浮窗而不是 toast因为浮窗常驻能让用户持续感知数据不是最新状态。键盘规则用户点击手机号码、验证码、金额、身份证号码、支付密码等输入框时弹起数字键盘点击登录密码等需要输入文本的位置弹起常规键盘。这条看起来基础但很多 App 实际做出来验证码输入弹的是全键盘用户切数字要手动点体验很差。PRD 里明确写明输入框类型和对应键盘类型开发就不用猜。生物识别用户开启手势密码和生物识别后优先使用生物识别生物识别不了才回落到手势密码。这条逻辑在金融 App 里是安全性和便捷性的平衡很多产品把顺序搞反逻辑写得不清不楚。空状态页面正常情况下没有数据时展示插图配提示性文案必要时根据场景增加引导 button 或链接。比如账单列表为空时除了「暂无账单」文案还要给一个「导入账单」的引导按钮这才是合格的空状态设计。六类规则的表格整理如下反馈类型展示时长是否阻断操作典型场景反馈型 toast2 秒自动消失否保存成功、删除成功进程型 toast进程结束消失是登录中、加载中dialog 弹框点击 button 消失是支付确认、协议确认异常浮窗异常恢复或手动删除否网络异常、缓存数据展示键盘随输入状态弹起/收起部分阻断验证码、金额、密码输入空状态数据加载后消失否无账单、无消息3.3 业务逻辑和数据说明借款认证、开户约束与缺失的数据说明文档业务逻辑部分写了两条硬性规则用户借款时需要真实信息和运营商信息认证用户投资时需要开通北京银行个人账户。第一条说明借款流程依赖第三方征信和运营商数据PRD 里要明确前置认证条件——不是用户点击「借款」就能借而是先完成实名认证、运营商认证系统才有依据评估授信额度。写这类需求时字段清单要包括真实姓名、身份证号、手机号服务密码或运营商授权 token认证失败的分支也要写清楚。第二条说明理财业务的资金账户是银行存管模式51 信用卡管家只做导流和产品展示用户的资金账户开立在合作银行。这个业务边界不写清楚开发会默认 App 自己维护资金账户对接起来就出大问题。需要提醒的是文档里第 4 节「数据说明」实际是空白的没有给出具体字段定义。这是这份文档最大的缺口——PRD 写到全局说明阶段至少要把账单、用户、消息这三类核心实体的字段列出来开发才能评估工作量、测试才能设计用例。这一点我在第 5 章会专门展开讲真拿到文档照着画原型的时候这块必须自己补上。4. 登录注册与账单导入验证码规则和短信更新流程怎么拆4.1 登录注册流程三种登录方式与验证码限流规则登录注册是每个 App 逃不开的模块51 信用卡管家同时支持账号密码登录、手机验证码登录和第三方 QQ/微信/微博登录注册流程里还带了邀请码机制。流程拆出来是这样的手机号注册后先通过验证码验证身份验证通过后用户可自主设置账号密码如果用户走第三方授权登录登录后必须绑定手机号完成身份认证。注册时可选填朋友给的邀请码用于后续运营活动追踪。文档里最有价值的是验证码获取规则写得很定量同一手机号只能绑定一个账户2 分钟内不可多次请求验证码同手机号 2 分钟内第二次请求时toast 提醒「请求验证码过于频繁请 1 分钟后再试」一天最多请求 6 次验证码第 7 次请求时 toast 提醒「今天已请求 6 次验证码了请明天再试」。这两条规则本质上是后端限流策略的前端表现2 分钟和 6 次是服务端限制前端只是把限制结果翻译成用户能理解的文案。PRD 里如果只写「验证码 60 秒后可重新获取」而不写明当天的上限次数会被滥发短信攻击短信费用和风控都出问题。我建议照文档的写法把限制参数和 toast 文案放在一张表里评审时后端、前端、测试三方口径完全统一场景触发条件提示文案请求过于频繁同一手机号 2 分钟内第 2 次请求toast请求验证码过于频繁请 1 分钟后再试当日次数耗尽同一手机号当日第 7 次请求toast今天已请求 6 次验证码了请明天再试这里还有一个细节验证码输入错误后的处理、验证码有效期常见是 5 分钟或 10 分钟、重新发送后旧的验证码是否立即失效这些文档里没有展开。实际写 PRD 时建议补上「验证码有效期 10 分钟」和「重新发送后旧码作废」两条后端实现时常见做法是以最后一次下发的验证码为准。提示验证码相关的文案和参数属于「运营配置」而不是「硬编码」PRD 里最好标注这些参数可通过后台配置修改避免以后改个数字还要发版本。4.2 账单导入与信用卡更新验证码弹框交互细节账单模块是整份文档的重点。前置条件很明确用户需要先导入账单才可以在首页查看账单、接收账单通知。也就是说未导入账单的用户进入首页看到的是空状态引导页而不是直接展示一个空列表。页面逻辑拆开看分两种路径普通账单导入时用户利用手机验证码或者登录第三方账户验证身份后获取最新的账单信息信用卡更新账单时交互就更细了用户点击「更新」按钮按钮文案变为「输入验证码」同时服务器下发短信验证码用户点击「输入验证码」弹出验证码输入弹框用户输入验证码判断正确后账单开始更新。文档作者在页面描述后加了一条个人建议「点击更新账单后验证码弹框和数字键盘自动弹起用户即可填入验证码进行验证。」这条建议是一个典型的交互优化点——如果用户点了「输入验证码」之后还要再点一次弹框、再等键盘弹起来多一步操作体验就钝了。PRD 里写功能描述时顺手补这么一句「建议」评审会上的观感会明显不一样说明你已经把交互走查过了。信用卡更新账单这个流程里还有几个隐含状态值得写进 PRD更新中按钮要置灰并显示加载状态验证码输入错误时的 toast 反馈服务器下发验证码失败的异常分支验证码过期后怎么重发。文档只描述了主流程分支状态需要在使用 Axure 画原型时自己补齐评审会上开发最常追问的就是「验证码错了怎么办」。4.3 借钱与理财的原型展示外部业务嵌入的边界财富、借钱这两个模块的原型页包括 51 产品详情、基金产品详情、借钱列表等。这些页面本质上是第三方业务的容器页App 本身不做资金和风控只是把第三方的产品或借款产品接进来展示给用户。写这类页面的 PRD 时业务逻辑不用从零定义但要明确三个边界一是跳转规则——用户在 App 内点击产品卡片是跳到 H5 页面还是原生页面、是否需要登录态透传二是数据来源——产品列表和利率信息由第三方接口提供App 只负责展示接口字段和刷新策略要写清楚三是授权流程——用户借款时需要的真实信息和运营商认证这个动作在 App 内完成还是跳转到第三方 SDK 完成决定了对开发的工作量评估。文档对这两块的描述就是标准的「透传式」写法说明前置条件交代认证要求然后交给第三方。这样处理是合理的——第三方业务的细节不该占用核心精力PRD 写得越重评审时越容易被细节拖住。5. 避坑清单这份 PRD 里最容易被细节坑到的五个地方5.1 「数据说明」是空的评审会上被追问到哑口无言现象文档全局说明的第 4 节标题是「数据说明」但正文里没有给出任何字段定义和数据结构整节是空的。原因原作者大概率是把字段细节留在了 Axure 原型的分页里没有整理进文档。这种「原型里有、文档里没有」的情况非常常见文档一旦脱离原型单独流转数据定义就彻底丢了。解决必须补一张数据字典表至少覆盖三类核心实体——用户用户 ID、手机号、姓名、成长值、会员等级、账单账单 ID、卡类型、账单金额、还款日、账单状态、所属用户、消息消息 ID、类型、标题、内容、发送时间、已读状态。字段要标明类型、长度、是否必填、默认值开发拿着就能建表。5.2 账单详情页没有展开核心页面反而写漏了现象文档目录里有「账单详情」但正文部分账单写完就跳到消息模块账单详情页的原型和交互逻辑没有实际内容。原因账单详情是字段多、状态多、操作多的页面写起来麻烦容易被跳过。这是 PRD 写作的老毛病——首页写得很详细二级页面一笔带过。解决账单详情页单独拆一小节至少列出三类信息账单基础字段账单金额、最低还款额、账单日、还款日、卡种状态分支未出账、已出账、逾期、已结清每个状态的展示内容不同操作按钮还款、分享、砍账单在不同状态下的可点击性。文档在交互规则部分已经定义了「可操作、不可操作、操作后」三种状态这里正好应该引用。5.3 产品目标写得无法验收评审时说不出成功标准现象文档产品目标里有「提高用户体验」「拉取更多用户」「增强用户活性」这类句子没有量化指标。原因目标写成了方向没有写成分解后的指标。方向本身没错但开发、测试、运营无法判断「做到什么程度算达标」。解决改成可衡量的指标。「支持市面上大部分机型」可以写成「兼容 Android 10.0 及以上、iOS 13.0 及以上主流机型覆盖率 ≥ 95%」「极速借款」可以写成「从点击借款到授信结果返回平均时长 ≤ 3 分钟」「拉取更多用户」可以写成「砍账单活动新增用户占比 ≥ 20%」。评审会上这样写每一项都能被验证而不是被一句「需求不清晰」打回。5.4 成长值体系只定义了数值没有落成页面和入口现象名词解释里写了成长值 0150 是新手会员、150500 是普卡会员但原型展示部分没有对应的等级说明页或成长值明细页用户看不到自己的等级和权益。原因成长值体系作为后端逻辑定义了但前端页面没有同步设计。用户在一个产品里感受不到等级的存在整个体系就废了。解决在「我的」模块补上成长值入口点进去展示当前等级、距离下一级还差多少成长值、各等级权益对照表。顺手把等级权益和发券逻辑打通——还款金、投资券、借款券的发放规则应该在等级页里有所体现比如「银卡会员每月可领 1 张还款金」。功能点之间不打通PRD 就还停留在概念层。5.5 砍账单规则不完整开发拿到需求无从下手现象文档定义砍账单是「邀请好友随机获取金额数可用于还账单时使用」但缺少最关键的运营参数随机金额范围、单笔账单可砍次数、同一好友能否重复砍、砍下来的金额有没有提现门槛。原因砍账单是运营活动运营还没给出确定口径产品就把一个不完整的功能写进了 PRD。这在团队里会造成两个后果开发排期不准确测试用例没法设计。解决把砍账单当成一个完整的功能点补全参数活动时间起止日期金额上下限比如单次砍掉 0.55 元每个账单可发起砍价的次数比如 3 次同一好友对同一账单只能助力 1 次好友助力需要关注的验证条件砍下来的金额进入还款金账户还是单独的活动账户。参数不一定全由产品定但 PRD 里要留出明确的运营配置位并在备注里写明「以上参数由运营端配置后端按配置下发」。6. 进阶用法拿这份 PRD 当模板倒推其他金融 App这份文档最好用的场景是当模板去倒推另一款 App。我拿它试过一次记账类 App整个流程走下来大概五步第一步用 Xmind 把目标 App 的底部 Tab 栏拆成一级模块明确哪些是自研业务、哪些是第三方合作业务这一步决定了后续的工作量分配。第二步逐个 Tab 截图记录页面元素把每个页面的字段、按钮、状态写出来参照账单模块的写法标注交互分支。第三步直接复用文档里的全局说明——网络异常三级反馈、toast 2 秒、dialog 点击外部不消失、数字键盘规则、空状态设计这些规则在金融类 App 里几乎全量通用不需要重新定义。第四步抽业务规则重点参考登录注册里验证码限流的写法把成长值、积分、还款金这类运营资产抽象成名词解释加等级表单独成节。第五步选一个核心流程做深度拆解——像 51 信用卡管家的账单导入一样拆到「异常情况都注明」的程度然后对照第 5 章的避坑清单检查数据说明有没有补、账单详情页有没有漏。我第一次独立写 PRD 的时候直接把 Axure 原型的链接丢给开发注释全写在原型页顶部开发审完跟我说看得很痛苦每个页面的边界条件都要追问一遍。后来我强制自己先写结构图再写全局说明最后画原型迭代三版之后评审会基本不用再解释页面逻辑了。从那以后我每次倒推 App 都强制走一遍这套流程先骨架后细节先规则后页面。这份文档的价值就在于此——它提供了一套可以直接照做的 PRD 骨架你唯一要做的就是拿一个真实 App 去练一遍。希望帮到你。本文还有配套的精品资源点击获取