《同学帮帮忙》产品设计文档
什么是“同学帮帮忙”?
同学帮帮忙是一款面向哈工大(威海)的校园问答类APP。主要面向用户为学校全体学生,此外学校教职工、校外人员也可使用。
需求分析
解决了什么需求?
校园内各组织、院系之间存在信息隔离,同学有问题需要解答时,发布的范围又过小,导致一个小问题也常常无人能解决。
同学帮帮忙想要解决的需求,就是同学的问题无法得到及时、有效的回答。
数据收集与分析
我收集了学校最大的BBS社区“观海听涛”和最大的QQ公告平台“哈工大威海墙墙”(发表各种匿名信息)的同学提问数据,选取了学期中、考试月、放假前三个阶段共300余条提问信息,发现将问题按内容分类,主要有以下几个类别:
除了按内容分类,还可以将这些问题按时效性分类,如
- 短时效性问题:
- 某道题怎么做?
- 今天广播台放的第二首歌是什么?
- 早一周返校,食堂有饭吗?
- ……
- 长时效性问题:
- 怎么看待平时不主动找自己聊天的男朋友?
- 毕业设计跟着企业做是什么体验?
- 学校附近有什么好的健身房值得推荐?
- ……
关于短时效性和长时效性问题,他们对比起来,有以下几个特点
问题类型 | 问题有效期 | 提问意图 | 是否需要被关闭 |
---|---|---|---|
短时效性 | 一般在一周以内 | 马上获得准确答案 | 是(避免成为垃圾信息) |
长时效性 | 一个月及以上 | 引起讨论、收集看法 | 否(随时有新观点新回答) |
基于以上分析,可以初步粗略地把用户提问数据按内容、时效性两大维度进行分类,在每个维度又细分为若干细分类别。
田野调查
我深入线下观察用户的提问-解决具体场景,目的在于绘制出体验地图,将流程在线上进行优化。
准备阶段
首先,选取提问人数众多的热门类别进行调查,提问者最好是调查者认识的人,这样调查结果会更普遍化、覆盖人群更多,且降低调查难度,投入产出比更高。经过筛选,选择具体调研问题为:
- 求C语言历年真题(学习类、长时效性)
- 早5天到校食堂有饭吗?什么时候有?(生活类、短时效性)
- 该如何有效劝说男朋友对自己脾气好一点?(情感类、长时效性)
调查阶段
如果发帖者是陌生人,则跟进目标帖子的后续回复,以及目标ID的后续动态,观察该问题的解决方法、解决过程和解决结果。
如果发帖者是认识的人,则除以上观察方式之外,还会通过和发帖者沟通聊天的方式,跟进问题的解决情况。
整理阶段
通过将调查阶段回收的问题进行归纳总结,梳理出了提问者的行为流程,以及在其中受到严重阻碍的地方。这些实际的行为流程和其中的阻碍点就是产品需要在线上主要优化并解决的地方。
“提问-解决”流程梳理
跟踪问题一:求C语言历年真题(学习类、长时效性)
跟踪问题二:早5天到校食堂有饭吗?什么时候有?(生活类、短时效性)
跟踪问题三:该如何有效劝说男朋友对自己脾气好一点?(情感类、长时效性)
从以上流程中可以看出,从用户产生问题开始,到收获答案的过程中,拆分出3个关键节点进行观察和分析,而每一个节点都存在一些体验繁琐或不佳的情况。
比如在观察中,我发现提问者从发表问题时就遇到麻烦,不明确自己问题的所属分类,发表完的问题无法推广给足够多的人或有能力回答的人,导致收获不到有效回答。一旦未及时收到满意答案,问题帖就可能被新内容覆盖,更难得到满意回答。
对于想提同样问题的浏览者来说,难以顺利找到目标话题帖,即使找到了,也不能在短时间内马上定位到最佳回答。浏览体验同样不佳。
而从回答者的角度来看,回答者只能凭偶然来遇到自己有能力回答的问题,而且由于回答后难以得到足够的正反馈,去激励自己继续回答问题,所以解答激情不足。
明确用户分类与行为特征
在本产品中,可以将用户角色从行为上分为三类:提问者、回答者、旁观者。他们之间的关系为
在用户目标的达成过程中,他们会产生以下主要痛点:
浏览者:垃圾信息泛滥
提问者:回答质量低下
回答者:无题可以回答
而解决这些痛点,正是问答产品最基础的目标之一。
用户分层
需求评估
由于团队面临着需求多、任务重、资源少的情况,虽然在产品设计时不应考虑这些束缚,但最终确定的需求是用来进行实际开发的。所以我们应该对需求进行评估,找到当前最重要的功能进行开发。
基础型需求功能
- 有这个功能,用户不会对产品产生多少好感,但没有这个功能,用户的满意度会直线下降。
- 功能列举:提问、回答、点赞、回复、私信
期望型需求功能
- 有这个功能,用户的好感会明显增加,没有这个功能,用户的不满也会增加
- 功能列举:搜索用户/文章/问题,关注、收藏、提醒、夜间模式
兴奋型需求功能
- 有这个功能,用户的好感会明显增加,没有这个功能,用户也不会觉得怎么样。
- 功能列举:学习资料合集、破解软件合集、考研/保研/出国/工作经验介绍、匿名提问、回答
无差异型需求功能
- 有这个功能,用户可能会使用,但不会表现出满意的想法。没有这个功能,用户也不会不满意。
- 功能列举:设置、帮助文档。
反向型需求功能
- 没有这个功能,用户不会不满意,但有这个功能,用户满意度反而会直线下降。但这是针对用户而言的,不代表对产品没有好处(如收费、广告)
- 功能列举:加入部分原生广告,适当提高广告搜索展现权重。
版本规划
周期 | 目标 | 做法 |
---|---|---|
种子期 | 验证用户反馈 | 采取mvp模式,优先实现期望型需求和部分基础型需求功能,用尽可能少的功能实现用户需求 |
成长期 | 完善产品功能 | 做大量基础型功能和期望型需求,以及部分兴奋型需求功能,让产品不仅能安全、稳定地运行起来,还能吸引更多用户 |
成熟期 | 实现商业变现 | 考虑做广告等反向型需求功能 |
衰退期 | 寻找新的增长点 | 做兴奋型需求功能来刺激用户,同时寻找新的期望型需求,满足用户没被满足的需求 |