PRD:Keep需求文档

54 评论 266831 浏览 1586 收藏 14 分钟

编辑导读:Keep作为国内著名的运动健身软件,它的每一次更新迭代都备受瞩目。本文将从三个方面,梳理了Keep的需求文档,希望对你有帮助。

一、前言

1.1 需求背景

通过之前对KEEP v6.43.0版本的竞品分析、需求分析,我们确定了KEEP下一代的迭代版本方向,我们从需求列表中挑出5个需求进行迭代实战。

欢迎大家去查看我们之前发布的竞品分析和需求分析报告。

Keep、咕咚、Peloton竞品分析报告:http://www.woshipm.com/evaluating/4140682.html

Keep需求分析实战报告:http://www.woshipm.com/evaluating/4142713.html

本次迭代将对课程体验进行优化,增加智能数据的实时显示,以提升用户留存和使用时间。

为了完善课程和内容体系,增加了“运动康复”课程分类,增加了“运动康复教练”用户推荐,和不同年龄分层筛选课程,以进一步提高用户量和打造健身闭环。同时在社区方面,增加了活动玩法, 优化了排名榜,以提升用户的活跃度和使用时间。

1.2 项目目标

  1. 通过增加课程分类、增加社区推荐用户分类、增加活动玩法,实现三个月内留存率同比增长10%。
  2. 通过优化排行榜、优化课程体验、增加活动玩法,实现三个月内平均使用时长同比增长10%。
  3. 通过增加活动玩法,实现三个月内活动参与用户量同比增长5%。

二、特性

2.1 需求列表

2.2 课程智能化优化

2.2.1 原型:直播课程页面新增运动数据

2.2.2 原型:录播课程页面新增运动数据

2.2.3  主逻辑

进入课程:

  • 如果已经连接智能设备:实时显示累计时长(KEEP原本就有的功能点),实时心率,累计卡路里(从进入课程到显示的时刻)。
  • 如果课程中途智能设备断联,则如原型所示,显示双杠号。
  • 如果中断连接的智能设备重新连接成功,则接着断联前的数据,继续实时统计连接。
  • 如果未连接智能设备:仅显示累计时长。

2.2.4  功能目标

  • 实现智能设备的数据共享,智能手环/手表用户可以有更好的课程体验。
  • 通过显示卡路里,用户实时了解自己的运动消耗,形成一个正反馈的激励作用,用户更容易坚持下去,
  • 心率控制运动强度是最简单和常见的方法,健身房许多有氧运动器材都有心率监测。通过显示心率,让用户更了解和把握自身的运动强度,实现用户更加关注自身的运动情况,方便及时做调整。
  • 达到增加用户粘性、使用时间以及提高用户留存率的目的。

2.3  课程分类增加

2.3.1  原型

2.3.2  主逻辑

课程分类增加“运动医学指导”课程分类板块。点击可以筛选出“运动医学指导”的相关课程。

增加不同年龄层的差异化课程分类。选择不同的年龄分层,筛选不同年龄适用的课程。

2.3.3  功能目标

  • 增加“运动医学指导”课程分类板块的目的在于:为有不同程度劳损和骨关节疾病的人群提供特殊性差异化的健身指导课程,完善课程体系和提升科学性。例如,像有腰椎间盘突出、膝关节炎的人,上其他课程容易给原本的损伤带来进一步伤害,在“运动医学指导”板块中选择课程“腰椎间盘突出日常轻量运动”,即可以上适合腰突患者的,不会加重损伤又能满足日常运动量的课程。
  • 增加不同年龄层的差异化课程分类的目的在于:使课程人群覆盖面更广,完善课程体系。不同年龄段的人群,身体的薄弱环节和运动目的都有差异,例如,未成年人能选择更适合生长发育或体育中考的课程,中老年人能选择适合他们的轻量健身、舒缓悠闲的运动。

2.4  社区推荐用户分类增加

2.4.1 原型

2.4.2  主逻辑

在【添加好友】页面,推荐用户中增加【运动康复教练】分类Tab菜单 。

第一次上线此功能时,用户进入“添加好友”页面,在【运动康复教练】Tab展示New标签:

当用户已经点击过此【运动康复教练】Tab,之后再次进入【添加好友】页面时,则不再展示New标签;

用户点击【运动康复教练】Tab,则在其下显示加载6个教练的头像、名称和简介以及最新的动态图片或短视频;并预先加载其余12个教练的名字、文案及关注按钮;图片部分统一灰色块展示;

教练列表优先显示与KEEP合作的优质运动康复教练,其次根据用户的关注数量依次往下显示有康复专业认证的教练。直至所有专业认证教练全部展示。

此【运动康复教练】Tab上线初期(0~3个月),放在第三个Tab位置;3个月后,按照用户点击次数以及教练关注数重新安排Tab位置。

2.4.3  功能目标

  • 根据前期做的用户需求调研,KEEP用户存在对运动康复知识和课程的需求,此功能在于让用户迅速地找到优质的运动康复教练。
  • KEEP的战略是要做健身闭环,运动和健身都跟康复关系紧密,完善KEEP社区在康复领域的漏洞,有利于减少有劳损和骨关节疾病的用户流失,提高用户留存率。

2.5  排名榜优化

2.5.1 原型

2.5.2 主逻辑

2.5.2.1  新增【排名榜入口】

2.5.2.2 【好友排行榜】界面改动元素说明

2.5.4 功能目标

  • 【我的】页面中本来有【运动数据】和【健康数据】,新增【排名数据】至此处。数据入口集中展示,更符合常理,用户更容易发现/找到排名榜入口。
  • 提升【排名榜】功能的点击率:,引导用户快速查看不同时间段、不同方式、不同人群的运动排名情况,以促进用户之间良性竞争,提高用户运动积极性。
  • 新增多种运动排名方式,以引导用户分享排名结果:用户可选择最满意的排名结果进行分享。
  • 如果只有【本周】统计时长,每周一清零重排,原本排前列的用户可能并不希望自己的健身前列排名被清零。提供更长时间段的统计排名,有助于用户坚持更长的时间,更好地培养在KEEP健身的行为习惯。
  • 增加排名统计方式,比原本单一的统计方式,能让更多用户获得排名前列的成就感。

2.6  活动挑战增加瓜分保证金玩法

2.6.1 需求功能流程图

2.6.2 原型

2.6.3 界面信息结构说明

2.6.3.1【活动列表页】页面信息结构内容说明

2.6.3.2 【活动介绍页】页面信息结构内容说明

2.6.3.3 【活动支付页】页面信息结构内容说明

2.6.3.4  【活动报名成功页】页面信息结构内容说明

2.6.3.5  活动结束页面信息结构内容说明

2.6.1  主逻辑

2.6.4.1  规则说明

活动挑战增加瓜分保证金玩法。用户缴纳一定保证金后,可加入活动;成功完成活动内容的用户,平分保证金池;未完成活动内容的用户,保证金不予返还。

2.6.4.2  交互逻辑

点击活动展示列表的某个活动,进入活动介绍页面。

在活动介绍页面点击马上报名,唤起支付流程。

支付页面点击确认支付,将跳转到对应的支付渠道进行支付,支付成功后跳转活动报名成功页面。

活动开始后,活动报名成功页面点击开始运动,进入具体运动页面。

活动结束后,活动报名成功页面变为活动结束页面。

2.6.5  功能目标

  1. 提升活动模块的参与人数:通过推出新玩法,吸纳对该玩法有兴趣的用户,以提高整个活动模块的参与人数,提高用户的使用时间;
  2. 增强对用户完成运动的激励:以承诺+金钱奖励的形式作为对用户完成运动的激励,以提升用户参与并按要求完成运动人数。

三、数据统计需求

3.1 数据统计需求

3.2  运营支持需求

 

作者:黎健茵、龙泉、黄悦、符蕾明、李珍珍、宋智、沙轶、刘志勇

本文由 @产品天团 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 需求文档是是什么?结构是怎样的?如何写好需求文档中的功能详细逻辑等产品需求文档问题!在人人都是产品经理社区&起点课堂联合办学的《90天产品经理实战班》里都会讲到哦!如果你对需求文档还存疑,可以搜索手机号(13517514071)添加老师的微信咨询呀!

    来自广东 回复
  2. APP对应的后端逻辑和app本身的异常逻辑都没有写啊,采集心率这些依赖硬件的设备连接,报文回传这些也都要协议给开发说明的,KEEP这么多标签内容也肯定走的是后端配置化,这些也需要规定逻辑的

    来自江苏 回复
    1. 后端逻辑产品也要写吗

      来自北京 回复
  3. 这种静态的没意思, 直接搞可点击的原型, 用户使用流程做成 gif, 然后配上文字,放到 GitHub project 里的 comment 里, 不就行了

    来自福建 回复
    1. 实际上,在写产品文档,很少会去做高保真带交互的,如果那样做就太浪费时间了。

      来自江苏 回复
  4. 狗看了都摇头

    来自广东 回复
  5. 看到一半,感觉身上有蚂蚁在爬

    来自上海 回复
  6. 我作为开发,感觉已经算很详细的啦

    回复
  7. 产品需求文档不是只描述需求就行么

    回复
  8. 标题党 不要出来黑keep了,keep怎么会写出如此差劲的文档

    来自湖北 回复
  9. 开发看了想砍人系列,给还没工作的产品看看还行,不过也不要误人子弟,没写异常情况,没写后台逻辑,纯粹是前端页面倒推逻辑

    来自广东 回复
    1. 后台逻辑怎么写

      来自湖北 回复
  10. 开发看了直摇头

    来自四川 回复
  11. 90天产品经理学员出品的吧!哈哈,看着书写节奏真是面熟

    来自河南 回复
  12. 看完后有两个疑问哈
    1、智能设备看数据已经很方便了,为什么还要放在实际操作中可能只有在最初不熟悉的时候才会关注的课程界面呢?
    2、将“运动康复教练”设置在“加为好友”功能区块,我是不是能理解为可以加这些教练呢?那么,加为好友的后续会怎么发展呢?相当于私教能够更针对性地提出建议和意见吗?如果是这样的话,有什么教练激励机制呢?感觉好像不是很完善

    来自北京 回复
  13. 学习金是一个失败的功能

    回复
  14. 感觉这类文档利于项目归档,实际开发中 阅读和理解成本高,程序员根本不会看的,只会越看越懵 。给老板交作业还差不多

    来自江西 回复
    1. 同感

      回复
    2. 那程序员看啥呀

      回复
    3. 直接在原型里标注就行了,单独写个文档谁有时间看

      来自浙江 回复
  15. 文档描述的很详细,支持。
    这款原型看后感:本次的原型设计,升级迭代重点内容是 活动挑战 模块
    1.可以通过活动挑战来达到分流,扩充用户
    2.增加留存率,使得新用户使用keep有个很好的切入口,老用户就更不用说了
    3.这里面增加的支付保证金,其实就是一个变相的消费内容。一些不在乎的用户或者无法坚持的用户,这笔钱算是交了一个学习金,承诺金。对于一些能坚持,完成的用户,或者是很想去完成,又表现的动力不足的用户来说,这个其实就是变相的消费金钱购买动力。
    4.活动挑战让我想起了最近很火的一类产品,网络兼职。你细品,是不是有那么点味道
    最后小总结以下,本次更新增加了更多的社(zeng)交(liu)元素
    我说的不对的话,不要打我,可以告诉我哪里不对,我向各位大大多多学习

    来自河南 回复
  16. 有点疑问想向您请教:
    1、为什么定的目标是用同比,而不是环比?同比怎么排除掉自然增长因素
    2、数据需求里没看到定目标时要看的数据,上线后怎么做后评估呢
    3、这个需求很大吗,还是说上线很着急,为什么要拆分优先级呢,如果拆分优先级,那项目里的子需求和其他项目需求要不要按优先级排序

    来自北京 回复
  17. 学习了

    来自福建 回复
  18. 什么是运营支持需求

    回复
  19. 我怎么感觉……不太利于阅读啊~

    来自浙江 回复
  20. Keep 的产品经理要是敢这么写文档,怕不是会被合作方打死

    回复
    1. 到底应该怎么写?急急急

      来自湖北 回复
  21. 崽崽

    回复
  22. 想了解下,作者写这篇文章的背景是什么,作者是KEEP内部员工来这里的分享?
    如果不是KEEP员工,是为了练习PRD交作业嘛?

    来自江苏 回复
  23. 写得不错,点赞!

    来自广东 回复
  24. 你好 觉得你们的文档写的很棒 是已经在职产品了吗?

    来自广东 回复
    1. 有部分成员是的。

      来自广东 回复
  25. 献上膝盖

    回复
  26. 不要激动,我更多想表达的是,对后端相关运营类的设计。例如如何设计通用平台活动。因为前台只是表现层,后端的设计需要考虑平台各类活动的兼容与扩展,将活动进行抽象,进行管理,这些都需要产品设计。比如你的设计里有一个用户的活动参与进度的设计,后端如何进行设计与评判,这些都是需要产品设计的。更广义的讲后端的界面也算前台,所以肯定也是产品经理来设计。当然你能定义数据之间的类关系,底层业务框架是最好了,可以和开发一起讨论后续的可扩展可维护性。

    来自浙江 回复
    1. 同意,活动相关信息的存储和管理后台都没有。。。运营怎么把控处理违规活动。。。

      来自湖北 回复
  27. 写得挺好的

    来自广东 回复
  28. 后端不用设计?话说你这个标注方式开发没造反吗

    来自浙江 回复
    1. 一般产品经理是不用想后端怎么实现的。
      标志方式的话,我见过挺多产品经理都是这样子的,不知道你的标注方式是怎样的呢?

      来自广东 回复
    2. 不设计后端与底层业务?那业务闭环怎么走通?

      来自浙江 回复
    3. 我认为,以上需求的后端的实现逻辑,应该是开发去想的。对于这些需求,产品经理去帮开发想实现逻辑,那就有点越俎代庖了吧。在某些专业性较高的B端领域,可能会出现业务在后端的实现逻辑也要产品经理来输出。但对于KEEP这种C端APP,以及我们提出要的需求都是比较简单的,后端的逻辑并不复杂。并且我们这些需求是在KEEP6.43.0版本基础上规划的迭代功能点,是在KEEP的整体架构上做补充,底层业务和业务闭环都是已经存在的,第一个需求智能设备的数据接口都是现成的,第2、3个需求都是可以直接在后台改的,第4个排行榜的需求都可以直接从已存在的数据库获取数据的。第5个需求跟其他业务也没有打通的点。我确实不是很理解你说的点,你可以具体地指出吗?

      来自广东 回复
    4. 首先我觉得KEEP很多点设计确实很好,但是只关注前端体验还是不够的,相对应后台肯定也要有相应模块维护,这些肯定不是简单说交给技术做就行,日后定会出大问题假如真的都给技术来自己定义。但我估计可能也是有后台设计,只是关系刀底层业务逻辑了,所以没展示出来而已,各位不必纠结了,文章还是可以

      来自山东 回复
    5. 谢谢王大发财同学和这位小伙伴,我明白大家说的是什么问题了,是指我们在需求的设计中没有写完整在后端的业务流转的逻辑。我自己的工作最近一直在研究实现逻辑,所以第一反应理解成技术实现逻辑了。这个问题确实有欠缺,不过我们这个是“迭代”的实战,不是“从0到1”的设计,我们不是KEEP的内部人员,对于目前KEEP的业务底层逻辑和后台实际的样子都不清楚,实在是很难去做这个优化设计和业务闭环。我们当时做这个需求的时候,咨询过腾讯的产品前辈,他的原话是“这个需求,不只是需要后台的,前端也是需要独立的模板,且有个人资金相关的功能,所以是一个综合了前后台的功能。”我们当时对于这个需求的评估是,这个大需求的细分功能点基本都是其他”活动挑战“里面有的,也可以看出KEEP的不同”活动挑战“是这些基本功能点的排列组合(只能想到这个表达哈哈哈)。所以我们是觉得这个新的”活动挑战“玩法,我们应该着重于产品层次,即值不值得做,适不适合做,这也是我们整个实战的核心,所以后台的优化设计我们并没有做。文章有诸多不足之处,感谢各位指出,我们小组还是比较嫩哈,还有很多需要学习的地方~

      来自广东 回复
    6. 同问

      来自上海 回复
    7. 后台,底层业务,全部写出来,那后台研发干啥,就做个搬运工?要不要,代码,表结构都设计好

      来自湖北 回复
    8. 我还是偏后端思维

      来自广东 回复
    9. 我觉得后端开发要是看到了估计当场直接爆炸了。。。

      来自湖北 回复
  29. 👍

    回复
  30. 文档描述的很详细,支持。
    这款原型看后感:本次的原型设计,升级迭代重点内容是 活动挑战 模块
    1.可以通过活动挑战来达到分流,扩充用户
    2.增加留存率,使得新用户使用keep有个很好的切入口,老用户就更不用说了
    3.这里面增加的支付保证金,其实就是一个变相的消费内容。一些不在乎的用户或者无法坚持的用户,这笔钱算是交了一个学习金,承诺金。对于一些能坚持,完成的用户,或者是很想去完成,又表现的动力不足的用户来说,这个其实就是变相的消费金钱购买动力。
    4.活动挑战让我想起了最近很火的一类产品,网络兼职。你细品,是不是有那么点味道
    最后小总结以下,本次更新增加了更多的社(zeng)交(liu)元素
    我说的不对的话,不要打我,可以告诉我哪里不对,我向各位大大多多学习

    来自广东 回复
    1. 之前做竞品分析,查到KEEP的用户数据的时候,发现KEEP的用户活跃度挺低的。
      所以我们认为丰富活动挑战玩法,也可以有效提高用户活跃度。

      来自广东 回复