抖音PRD产品经理参考文档
产品经理PRD软件需求规格说明书模板
{产品名称}软件需求规格说明书XXXX科技有限公司版权所有（内部资料注意保密）版本历史目录1.产品描述 (3)1.1.编写目的 (3)1.2.产品名称 (3)1.3.文档范围 (3)1.4.预期的读者和阅读建议 (3)1.5.参考文档 (3)1.6.缩略语和术语（可选） (3)2.产品需求概述 (3)2.1.用例简介 (3)2.2.运行环境 (3)2.3.条件与限制（可选） (4)3.用例描述 (4)3.1.用例1 (4)3.2.用例N (5)3.3.不支持的用例 (5)4.数据描述 (5)5.系统需求（可选） (5)6.运行需求（可选） (6)6.1.用户界面 (6)6.2.硬件接口 (6)6.3.软件接口 (6)6.4.通信接口 (6)7.其它需求（可选） (7)8.特殊需求（可选） (7)9.不确定的问题（可选） (7)10.编写人员及编写日期 (7)11.附录 (7)11.1.引用文件 (7)11.2.参考资料 (7)1.产品描述1.1.编写目的【说明编写本软件需求规格说明书的目的，指出预期的读者。
】1.2.产品名称【本项目的名称，包括项目的全名、简称、代号、版本号。
】1.3.文档范围【文档范围包括：产品介绍，产品面向的用户群体，产品应当遵守的标准与规范，产品范围，产品中的角色，产品的功能性需求，产品的非功能性需求。
】1.4.预期的读者和阅读建议【各种管理人员及开发人员：项目经理、系统工程师、软件开发人员、硬件开发人员、测试人员、型态管理人员、品质保证人员和软件使用客户】1.5.参考文档【说明编写本软件需求规格说明书涉及参考文档。
】1.6.缩略语和术语（可选）【对重要的或是具有特殊意义的名词（包括词头和缩写）进行定义，以便读者可以正确地解释软件需求说明。
】2.产品需求概述2.1.用例简介【对产品的基本用例做一个简介，包括：1.本产品的开发意图、应用目标及作用范围。
2．概略介绍了产品所具有的主要用例。
产品经理PRD文档范例 值得收藏的写作手册
2015年，我写了一篇梳理PRD的文章《 PRD到底该怎么写？》，获得3.5万次阅读，423次收藏。
至今已过去5年，在这5年里，我一直从事产品产品相关的工作，也经历过一次完整的创业，对PRD又有了一些新的思考。
这篇文章是《PRD怎么写》的升级版，弥补了之前文章的不足，对怎么写PRD，描述得更具体、更全面，是我思考的沉淀，也希望对大家有一定帮助。
01. 你是否遇到过这样的问题如果遇到以上一个或多个问题，那么你可能需要反思，自己写PRD的思路是不是有问题？写PRD是产品经理非常重要的基本功，写好PRD，可以提高团队效率，减少无效的沟通。
02.什么是PRD?PRD是Product Requirement Document的简称，其中文翻译为：产品需求文档。
该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最重要的一个文档。
PRD的主要使用对象有：研发、测试、交互设计师及其他业务人员。
PRD是项目启动之前，必须经过评审达成共识的最重要文档。
产品经理的PRD，就像建筑设计师的设计图纸，是设计和思考的文档化呈现。
《用户体验要素》作者在书中有一句很经典的话：“文档不能解决问题，但定义可以”，PRD就是要定义需求。
03. 动手之前，先思考这几个问题1、解决什么问题？解决用户什么问题？发现问题比解决方案更重要。
给公司能否带来收益？相关干系人的需求是什么？是不是老板说这样做的？是不是“他们”说这样做的？他们是谁？真正的问题是他们说的那样吗？产品经理正确的设计思路如下：这叫RTPA设计框架，是一种逆向思维假设分析，我们要使用这样一种思考技巧：假设初始需求都是错误的，即问题并不存在，你需要重新发现问题。
不要需求方一提需求，就开始着手设计，多问几个为什么并着手调查，以了解真正的问题。
下面是一次完整的设计思路示例：2、怎么衡量？不同的干系人，通过什么指标去衡量问题是否已解决？有没有埋点？有没有业务数据？谁来运营？3、需要多少资源？为了实现这个解决方案，需要多少资源、多少人？能大致评估吗?4、会不会太复杂？这个解决方案会不会太复杂？复杂是产品的坟墓。
产品经理prd需求文档模板
产品经理prd需求文档模板1. 产品概述1.1 目标和背景[在此描述产品的目标和背景，包括该产品的市场需求和竞争背景。
]1.2 产品定位[说明该产品在市场上的定位，以及目标用户群体。
]1.3 产品功能[列出该产品的主要功能和特点。
]2. 用户需求2.1 用户场景[描述用户使用该产品的场景和情境，尽量具体生动。
]2.2 用户需求分析[分析用户的核心需求和痛点，并以用户故事的形式呈现。
]3. 产品需求3.1 功能需求[将用户需求转化为产品的具体功能需求，并分模块排列，每个模块包括功能名称、功能描述、优先级和验收标准。
]3.2 非功能需求[除了功能需求外，列举产品的其他性能、安全、可用性等非功能需求。
]4. 界面设计4.1 交互流程图[画出产品的交互流程图，明确每个界面之间的关系和用户的操作流程。
]4.2 界面原型[提供产品的界面原型图，包括主页、功能页面、输入输出界面等。
]5. 数据需求5.1 数据模型[根据产品的功能需求，设计产品的数据模型，包括数据表、字段和关系等。
]5.2 数据流图[画出产品的数据流图，展示数据在不同模块之间的流动和处理过程。
]6. 技术需求6.1 技术架构[描述产品的技术架构，包括前端、后端、数据库等技术选型和整体架构设计。
]6.2 接口需求[列举产品需要与其他系统或服务集成的接口需求，包括数据传输、认证等。
]6.3 安全需求[说明产品的安全需求，包括用户数据的保护、权限控制、防止信息泄露等。
]7. 项目计划7.1 项目周期[估计整个项目的开发周期，包括需求分析、设计、开发、测试和发布等阶段的时间安排。
]7.2 里程碑[设定项目的重要里程碑，标明每个里程碑的完成时间和关键成果物。
]7.3 资源需求[列出项目所需的人员、设备和软件等资源需求，并明确责任人。
]8. 风险评估8.1 技术风险[分析项目中可能存在的技术风险，并提出相应的应对措施。
]8.2 进度风险[评估项目进度可能出现的风险，提前制定预案以应对可能的问题。
完整word版)PRD产品需求文档经典模板
完整word版)PRD产品需求文档经典模板产品需求文档模板产品需求文档的定义：此文档的目的是收集、分析和定义>的需要和特性。
它包括相关方和目标用户需要的功能和这些需要存在的原因，以及详细地说明所确定的产品的关键外部业务流程、接口和非功能性特性的需求、设计约束。
此文档用来让读者了解产品的外部黑盒概念，并指导《架构设计说明书》和《软件需求说明书》。
一个产品只有一份《产品需求文档》，对于分解的对内项目部分可以以《xxxx产品需求文档—yyyy分册》来撰写。
文档版本号：文档密级：产品名：编写人：文档编号：归属部门/项目：子系统名：编写日期：修订记录：版本号修订人修订日期修订描述PRD文档模板目录一、简介1、目的2、范围简介：本文档旨在收集、分析和定义>的需要和特性。
通过详细说明产品的关键业务流程、接口和非功能性特性的需求，以及设计约束，让读者了解产品的外部黑盒概念，并指导后续的架构设计和软件需求说明书。
目的：本文档的目的是收集、分析和定义>的需要和特性。
范围：本文档包括相关方和目标用户需要的功能和这些需要存在的原因。
同时，详细说明所确定的产品的关键外部业务流程、接口和非功能性特性的需求、设计约束。
二、产品概述本产品是一款基于云计算技术的企业级管理系统，旨在帮助企业实现信息化管理，提高工作效率和管理水平。
该系统具备多种功能模块，包括人事管理、财务管理、项目管理、客户管理等，能够满足企业不同部门的管理需求。
三、流程图1、业务流程图（推荐使用泳道图）本系统的业务流程图主要包括以下泳道：人事管理、财务管理、项目管理、客户管理。
在每个泳道中，都包含了该部门的具体业务流程，如人事管理泳道中包括招聘、培训、考核等流程。
2、状态图（理清状态流转）本系统的状态图主要用于描述不同状态之间的流转关系，如项目状态的变化、人员状态的变化等。
通过状态图，可以清晰地了解系统中各个状态之间的关系，帮助用户更好地管理和控制业务流程。
产品经理文件之App产品需求文档(PRD)
功能：按钮，显示 全部话题； 交互：点击之后 跳转到更多话题 页面
功能：点击后返 回社区频道
功能：显示全部 话题分类； 交互：点击相应 的分类，右边模 块跳转到相应话 题
功能：显示相应 的全部话题； 交互：点击跳转 到话题详情页
功能：点击之后 相应话题添加到 我的话题； 交互：点击之后 提醒话题已关注
功能：清除缓存、 隐私与安全、意 见反馈、使用说 明等其他一些事 项的说明； 交互：点击系统 设置页面
功能：展示给帖 子点赞的人； 交互：点击点赞 人的头像可以跳 转到对应用户的 个人信息页面
功能：展示给帖 子评论的内容和 的人； 交互：点击评论 可以回复，点击 头像可以跳转到 用户个人信息页 面
4、个人详情页
交互：点击之后 跳转到个人信息 页
功能：点击后返 回帖子详情页
功能：展示发帖 人信息，包括头 像、昵称、性别和 等级，可以关注 或者给发帖人发 私信； 交互：点击关注 可以关注发帖 人，关注变为已 关注；点击私信， 跳转到发私信页 面
功能：点击之后 相应话题添加到 我的话题； 交互：点击之后 提醒话题已关注
产品经理基本功之PRD
产品经理基本功之PRDPRD (产品需求文档), 英文全称是：Product Requirement Document。
PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD或BRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
产品经理工作中最重要的产出是独立撰写一份PRD，这是产品经理的基本功之一。
怎么理解PRD产品需求文档，即Product Requirement Document是产品经理能力基础中的基础是从产品规划到产品设计阶段的里程碑式综合产出物“PRD写的好，不一定是好的产品经理，PRD写的不好，一定不是好的产品经理。
”今天我们就来谈谈这个基本功的话题——怎么样写出一份高质量的PRD。
如果你看完一份PRD也有以下感受：•文档通篇是各类名词、页面功能点跳转、点击之类的逻辑；•看完了文档有一肚子的疑问：为什么要有这个功能，为什么要这么做产品设计；•第一遍头晕眼花，必须得看第二遍、第三遍才能明白功能之间的关系。
这确实是一份不友好的PRD。
这种PRD产生，主要由于以下两个问题：1、产品经理以为没写出来的那些内容，研发都已经潜在知晓了、明白了，或者作者打算“PRD评审的时候我会说这些内容的”。
2、产品经理撰写到PRD里面的，只是自己产品设计的结果，就是用例、功能、交互。
第一个问题——“想不如说、说不如写。
想不明白肯定也写不清楚。
”大家可以挑战一下自己，把那些打算放在评审会说的话，都先写在PRD里面。
第二个问题——产品经理把PRD评审当做一次功能宣讲，只关注“让研发需要开发”的功能点（只说结论），忽略了其他也应该同步给项目团队的其他核心内容以便达成共识，导致开发过程的衍生问题，每次多要事无巨细的去讨论、争论。
这两个问题如何解呢？先从PRD的作用说起吧。
PRD的作用作用一：PRD是项目工程人员围绕其进行技术落地的设计图纸。
产品经理prd文档模板
产品经理prd文档模板产品经理PRD文档模板。
一、产品概述。
产品名称，【填写产品名称】。
产品定位，【填写产品定位】。
产品目标，【填写产品目标】。
产品背景，【填写产品背景】。
二、市场分析。
1. 行业发展趋势。
【填写行业发展趋势】。
2. 竞争对手分析。
【填写竞争对手分析】。
3. 目标用户画像。
【填写目标用户画像】。
三、产品需求分析。
1. 产品功能需求。
【填写产品功能需求】。
2. 用户痛点分析。
【填写用户痛点分析】。
3. 用户使用场景。
【填写用户使用场景】。
四、产品设计。
1. 产品架构设计。
【填写产品架构设计】。
2. 交互设计。
【填写交互设计】。
3. UI设计。
【填写UI设计】。
五、产品功能点。
1. 功能点一。
【填写功能点一详细说明】。
2. 功能点二。
【填写功能点二详细说明】。
3. 功能点三。
【填写功能点三详细说明】。
六、产品测试。
1. 测试范围。
【填写测试范围】。
2. 测试方法。
【填写测试方法】。
3. 测试结果。
【填写测试结果】。
七、上线发布。
1. 上线计划。
【填写上线计划】。
2. 上线后运营。
【填写上线后运营方案】。
3. 上线效果分析。
【填写上线效果分析】。
八、风险控制。
1. 风险预警。
【填写风险预警】。
2. 风险应对。
【填写风险应对】。
3. 风险后果。
【填写风险后果】。
以上是产品经理PRD文档模板的内容，希望能够对大家在撰写PRD文档时有所帮助，谢谢！。
产品经理一份让研发同学爽的「PRD文档」,都有哪些内容？
我们都知道一份完整的PRD，面向阅读人群有：设计师、市场、运营、测试、研发、领导…那在实际工作中，真的会有这么多角色来看你的PRD吗？其实，因为互联网快速迭代的原因（我曾经负责的产品每周发版），一方面阅读落到做这件事的研发头上，一方面PM也没有充裕的时间去思考和完善PRD中那些为了某些非核心阅读人员看的内容。
所以，我这里说的主要是：如何写一份看上去清晰，研发容易理解的PRD。
那么研发在看一份PRD的时候到底关注什么？经过这几年我与不同岗位、不同层级的研发同学深入沟通和交流，总结为以下几点：1、为什么做这个？团队中少数研发会很关心这个问题，他们不愿意盲目去写代码。
2、业务关系是什么样的？这个功能涉及到的整体业务流程和系统架构是什么。
3、页面长什么样子？页面很大部分决定前端的工作量，大部分后台同学也习惯于通过前端页面去评估。
4、数据从哪里来？从后台来？从其它事业部来？还是从合作的第三方API拿？亦或是人工上传？当然，研发同学肯定关注的问题不只以上4点，但一开始这4点说清楚了，基本上这个文档就很容易读下去了。
曾经一位研发总监给我一个建议：PRD先画一个整体流程图，不要一上来就说具体功能，不然很容易就产生“这个功能好复杂好难”的潜在心理暗示。
我深表赞同！那么接下来，就实际说一下，满足以上条件的PRD到底怎么落地去写。
先放一个文档结构图：一、需求背景解释一下为什么做这个需求？我们遇到的问题或现状是什么样的，我们做这个需求是为了解决什么具体问题的。
尽量用大白话描述，不用太书面化。
这么几年工作下来，大概感觉是研发团队中其实不到50%的人在意这个需求背景，一大部分研发还是习惯于直接看功能描述，看怎么做，偏向于单纯的写代码。
二、产品目标1、功能目标描述一下这个需求具体要实现什么功能，这里的描述类似于一句话给别人介绍你这个产品。
2、数据目标现在这个时代下，不关注数据的产品迭代行为都是耍流氓。
你可以不完全依靠数据去做决策，但是必须知道你做的产品，核心衡量数据指标是什么吧？即所谓的OMTM（one metric that matters）。
产品经理prd需求文档模板
产品经理prd需求文档模板产品经理PRD需求文档（Product Requirement Document）是产品开发过程中至关重要的一份文档，它全面描绘了产品的功能需求、用户需求、性能指标以及其他相关需求。
以下是一个PRD文档的基本结构：1. 封面* 文档名称：产品需求文档* 版本号：V1.0* 编写日期：XXXX年XX月XX日* 编写人：产品经理姓名2. 目录* 列出文档中的主要章节和页码，以便快速查找所需内容。
3. 概述* 对产品的简要描述，包括目标用户、市场定位、主要功能等。
4. 用户需求* 描述目标用户的基本信息，包括年龄、性别、职业等。
* 列出目标用户的主要需求，以及如何满足这些需求。
5. 功能需求* 详细列出产品的所有功能，每个功能都应包括以下信息：+ 功能名称：简明扼要地说明功能的目的。
+ 功能描述：简要说明功能的用途和实现方式，以及为何需要这个功能。
+ 功能流程：描述功能的操作流程，包括输入、处理和输出。
+ 功能界面：提供功能的UI/UX设计图或描述，展示用户在功能使用时的可视化交互。
6. 非功能需求* 描述产品的性能要求，包括响应时间、数据安全性、可扩展性等。
* 列出产品的其他要求，如兼容性、易用性等，并解释为何这些要求对于产品的成功至关重要。
7. 约束条件* 列出产品开发过程中需要遵守的约束条件，如技术限制、法律法规等，并说明如何克服这些约束。
8. 假设和依赖性* 列出产品开发过程中可能存在的假设和依赖性，以及如何处理这些假设和依赖性，以确保产品在各种情况下都能正常工作。
9. 接口要求* 描述产品与其他系统或设备的接口要求，包括数据格式、通信协议等，以便与其他系统或设备进行无缝集成。
10. 数据管理和报告要求* 描述产品对数据管理和报告的要求，包括数据存储、数据备份、数据安全等，以确保数据的准确性和可靠性。
11. 维护要求* 描述产品的维护要求，包括升级、修复漏洞等，以确保产品在整个生命周期内都能保持稳定运行。
产品经理需求文档(PRD)怎么写
产品经理需求文档（PRD）怎么写作为一个产品经理来说PRD是一个很基础的工作了，也可以说是产品经理用来沟通的重要桥梁。
什么是PRD？PRD是产品经理用来表述产品功能或需求的方式，就像研发人员需要的开发文档一样起到了重要的作用，但是你们产出的PRD是需要交付给公司业务内所有人员的，所以我们撰写的PRD一定需要详细，且可以让他人更好的阅读。
当然，如果你有着明确的需求，可以直观明了的描述出来那么PRD自然而然就形成了。
PRD的好处降低沟通成本：在项目进行时有可能会因为时间推移研发或测试忘记部分需求，然后一遍一遍的过来询问。
这时候就需要有一个文档来向所有成员记录需求信息，从而降低沟通成本。
确定需求：部分公司的产品记录可能会遇到老板经常变更需求的情况，这时候就需要明确PRD，到时候也可以直接拍给老板看看。
也起到了大家约束老板需求的作用。
为新人提供指南：当项目进入新的人员时，可以让新人更快的了解产品需求。
而且也可以供后续产品经理查阅，快速熟悉产品内容。
给予测试验收标准：测试人员可以根据PRD去验收产品质量。
PRD的结构1、产品名称所有给别人看的文档都是得有名称的，不然大家根本无法直观知道自己看的是什么。
要注意的是最好这里直接占满页居中（别问为啥，因为美观）。
2、版本历史写上版本历史的主要用途也就是为了大家在修改或迭代的时候避免出现一些细节性错误，并且可以让研发直观的看出你所修改的地方。
PRD-版本历史如图中的版本历史里面主要包含了修改时间、版本、变更人、描述、修改人；在这里的描述中产品经理需要说明自己修改的需求在目录中的编号，让开发可以直观的查看到本次修改的内容。
3、目录因为PRD文档页面少则几页多则几十页，为了让研发快速定位自己负责的板块，所以目录也是必不可少的。
在Word中直接”引用-插入目录“就可以自动生成目录了。
(具体结构如下)4、项目介绍项目的介绍主要分为3个方向：项目背景：讲述项目/需求产生原因，以及是如何贴合当前公司业务进行的项目。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
【抖音】需求文档V4.0
修订记录
目录
修订记录 (1)
1. 前言 (3)
1.1需求背景 (3)
1.2项目目标 (3)
2 特性 (4)
2.1需求列表 (4)
2.2热度标签页 (5)
2.2.1 增加热度标签页 (5)
2.2.2 热度页交互逻辑 (6)
2.2.3 热度页特殊情况 (7)
2.2.4 热度页功能目标 (8)
2.3短视频打赏 (8)
2.3.1 增加打赏功能 (8)
2.3.1.1 打赏交互原型 (8)
2.3.1.2 打赏主流程 (9)
2.3.1.3 打赏充值 (10)
2.3.1.4 打赏记录—打赏者 (11)
2.3.1.5 打赏记录—受赏者 (12)
2.3.1.6 打赏明细—钱包页 (13)
2.4拍摄字幕 (14)
2.4.1 拍摄增加字幕功能 (14)
2.4.1.1 拍摄字幕交互原型 (14)
2.4.1.2 拍摄字幕主逻辑 (14)
3 数据统计需求 (16)
3.1基础数据 (16)
3.2点击数据 (16)
1.前言
1.1需求背景
通过市场、竞品分析、用户调研等手段，初步确定抖音的发展方向为发展盈利模式。
得出需要通过新增功能，来提高用户粘性、增加活跃度的结论。
主要新增的功能为热度排行榜、短视频打赏、拍摄歌词字幕显示。
通过市场分析、竞品分析、用户调研等手段，确定抖音下一阶段的发展方向为拓展平台台盈利模式、增加视频内容分类、拍摄优化。
1.2项目目标
1、提升排行榜单的视频（Top1~10）的观看数、点赞数、评论数等指标，期望提升20%的
PV；在不破坏用户沉浸式体验的基础上为用户提供相对多元化的视频内容；
2、通过用户打赏，促进平台生态的盈利，提升创作者的营收；
提升抖音平台内的资金流动，拓展平台盈利方式，增加内容创造者营收；
3、增加拍摄字幕功能，增加可玩性，提升用户在拍摄过程中的体验效果，提升10%的拍摄
功能使用率；
2特性2.1需求列表
2.2热度标签页
2.2.1增加热度标签页
在顶部标签栏增加“热度”标签，显示每天点赞、人气、音乐使用排行前十的视频。
每次点击“热度”或下拉热度页刷新后，读取对应榜单的最新数据进行展示：
2.2.2热度页交互逻辑
（1）点赞排行榜：点击进入对应视频播放详情页
（2）人气排行榜：同上（与点赞排行榜一样）（3）热门音乐：点击进入对应音乐使用详情页手指上滑：查看下一名次视频，并显示当前视频排名情况。
若是第10名，则不显示下一名次视频，上滑提示此视频是该榜单第10名
手指下滑：查看上一名次视频，并显示当前视频排名情况。
若是第1名，则无上一名次，下滑提示此视频是该榜单第1名
2.2.3热度页特殊情况
2.2.4热度页功能目标
（1）点赞排行榜：让创作者提供更优质内容，增加优质视频曝光度，增加被打赏几率，从而提升创作动力，促进良性循环。
（2）人气排行榜：激励创作者吸纳更多粉丝，与“直播”模块的粉丝团相辅相成，同样存在良性循环。
（3）热门音乐：鼓励音乐创作者创作更加优质的音乐，有利于丰富平台的音乐库。
2.3短视频打赏
2.3.1增加打赏功能
在首页“推荐”标签页增加打赏功能，点击打赏相应抖币与礼物给创作者。
2.3.1.1打赏交互原型
2.3.1.2打赏主流程
●显示打赏数（显示位置：）
✓首次进入视频页，显示目前收到的打赏人数总数。
✓每5秒刷新一下数值。
✓用户打赏后，打赏人数+1，并显示作者在打赏功能中，所收到的所有抖币总数。
（如图，）同样每5秒刷新。
●打赏交互
✓点击打赏按钮后出现浮层，用户点击打赏礼物后：
❖当抖币充足，扣除相应抖币数值后，浮层收起，视频显示打赏信息（如图，)
❖当抖币不足，见下一章节流程
✓当用户点击打赏数值，呼起数值输入控件，自行输入数值并点击打赏后：❖当数值等于0，小浮层提示：输入数值需要大于0（2秒后消失）
❖当数值大于0，逻辑同上（视频显示打赏信息，如图，)
✓打赏信息显示2秒，随即消失。
显示刚扣除的抖币数值与用户昵称。
✓点击打赏浮层以外的区域收起浮层。
●打赏页面特殊情况
2.3.1.3打赏充值
●充值原型
✓点击礼物或者“打赏”按钮后，当用户抖币不足：
❖弹窗提醒，提醒内容：余额不足
选择：取消，弹窗消失
选择：去充值，跳转到“我的钱包”页面，点击相应金额，如“￥6.00”，就调用App Store（ios系统）或者支付宝（安卓系统）进行充值，充值结束回到视频打赏浮层页❖充值后，抖币余额仍不足支付，小浮层提示：余额不足支付（3秒后消失）。
❖充值后，余额足够支付，自动扣除并显示显示打赏信息。
2.3.1.4打赏记录—打赏者
●打赏记录原型
✓当用户产生打赏行为后，消息页列表增加“我的打赏”：❖显示最近一次打赏的时间，打赏对象与打赏数值
✓“我的打赏”页面列表内容：
✓此列表按时间排序
✓下拉刷新
✓“感激互动”页，点击底部输入框呼出键盘，输入完成后按键盘“发送”键发送
2.3.1.5打赏记录—受赏者
●打赏记录原型
✓当用户收到打赏后，消息页列表增加“收到的打赏”：
❖显示最近一次被打赏的时间，打赏的来源用户与打赏数值
✓“收到的打赏”页面列表内容：
✓此列表按时间排序
✓下拉刷新
✓“感激互动”页，点击底部输入框呼出键盘，输入完成后按键盘“发送”键发送
2.3.1.6打赏明细—钱包页
●打赏明细原型
✓“我的钱包”页面增加“打赏明细”与“打赏收益”栏目
✓“打赏明细”显示的明细按照时间排序（最新的记录在最上方）
✓当用户未产生打赏行为，或者未被打赏，此页面为空，并显示“您还没有打赏记录”✓可提现额度与抖币的换算方式可在后台制定
✓“打赏收益”与抖音原有的“红包收益”功能合并，流程一致。
2.4拍摄字幕
2.4.1拍摄增加字幕功能
在拍摄模块增加歌词字幕功能，当用户选择了音乐之后，根据录像与播放时间，同步显示相对应的歌词字幕。
2.4.1.1拍摄字幕交互原型
2.4.1.2拍摄字幕主逻辑
●字幕显示
✓只有当用户选择音乐后，才显示字幕图标（如图，)。
✓“选择歌词起始点”页面背景依然读取摄像头信息。
✓音乐选段根据“歌词起始点”的选择而调整。
（例如，歌词从2分30秒开始，相对应的音乐也从2分30秒开始）
✓一屏只显示4行字幕，高亮显示音乐乐段所对应的歌词句段，跟随录像时间切换滚动。
（单击拍与长按拍逻辑一样）
✓字幕信息在后台通过人工查找并输入（需运营配合）。
●字幕特殊情况
3数据统计需求
3.1基础数据
统计热度标签页浏览数PV，热度标签页停留时长，热度页面到二级视频播放页的点击率，二级播放页浏览屏数。
（P1）
统计每日打赏总金额，打赏按钮点击数。
（P1）
统计拍摄歌词字幕按钮点击数，打开歌词字幕功能拍摄并成功发布的视频数。
（P2）3.2点击数据
埋点数据详情见excel。